Agent tools, from your server.

The problem

Adding a tool means running a server.

Claude connects to any MCP server, and that server is yours to run: hosting, auth in front of it, limits on what it can reach.

The solution

A secure framework for adding your own.

Run tools from your server, inside a framework built for exactly that. Use what's included here, or add more. Each gated as tightly or loosely as you decide.

The arsenal

What's included.

browser

browser.<domain>

A cloud browser, watched live

headed Chromium · noVNC takeover · any web UI

The full Playwright surface driving a cloud Chromium session. Anything with a web UI, navigated for you, with a live noVNC page to watch or grab the wheel. It keeps you logged in and reaches the open web.

Built on: microsoft/playwright-mcp ↗

workspace

workspace.<domain>

Your Google account, as tools

Gmail · Drive · Calendar · Docs · Sheets · Slides · Tasks · Apps Script

121 tools across your entire Google account. It reads and sends the mail, manages files and sharing in Drive, books the calendar, works Docs and Sheets, and runs Apps Script: real code, as you.

Built on: taylorwilsdon/google_workspace_mcp ↗

telegram.<domain>

Your Telegram account as tools

read + write · DMs · groups · channels

The full Telegram surface, acting as you. It reads chats, groups, and channels, searches your history, manages contacts, and sends messages from your number.

Built on: chigwell/telegram-mcp ↗

gatekeeper

gatekeeper.<domain>

The control plane

per-tool permissions · in-chat panel · approvals

Server-side moderation of every tool's access. Each tool runs in one of three modes (always_allow / needs_approval / blocked). All managed from a chat with Claude, no redeploy.

Built on: native

The incubator

Experiments live in a separate overlay repo and run on the same stack.

xmcp

The full X API: reads, plus OAuth1 writes acting as your account.

xdevplatform/xmcp ↗

data

Crypto market data pulled into a local parquet lake, exportable to the backtester.

OpenBB ↗

lean

Self-hosted backtests of agent-written algorithms over the lake's data.

QuantConnect/Lean ↗

The list grows. The pattern holds.

New tools are stamped from a template that arrives already wired into the substrate. Add your own: a built-in Claude Code skill guides each new tool into the framework.

.claude/skills/new-tool

Arm it

Clone it. Tell Claude Code to deploy it.

git clone https://github.com/wnkinc/claude-custom-connector-server.git mcp-tools && cd mcp-tools && claude

then say: "deploy this" — local or cloud, Claude walks the setup.

Best-effort guarding

You are the last guardrail.

These tools act with your accounts, and the model driving them can be misled by what it reads. Three things can go wrong: hostile content can turn the agent against you, the agent can make a mistake all on its own, and the server itself can be attacked. Below, each concern with the controls that answer it.

Prompt injection: the agent, turned against you.

Hostile content — a web page, an email, a message — can carry instructions the model follows. This is model behavior, so nothing here is proof: these are best-effort screens that filter what the agent reads, cut what a hijacked call can reach, and put a human before anything irreversible.

guardrail in code

A guardrail that proves itself

fails closed

A sidecar screens tool output for prompt injection before it reaches the agent. GUARDRAIL_PROVIDER picks the engine (llamafirewall locally, Bedrock Guardrails on AWS) behind a fixed contract. At startup a canonical injection must block, or the container refuses to report healthy.

egress in code

Default-deny egress

the strongest single control

Each tool sits on an internal Docker network whose only route off-box is a squid sidecar enforcing a per-tool domain allowlist. A tool reaches the handful of hosts it needs; everything else returns TCP_DENIED/403, logged to a central audit. Verified behavior: allowlisted hosts succeed, the rest are denied, and a proxy-bypass attempt is dropped.

approval yours

Human approval

written by humans only

Gated actions raise an Approve/Deny card right in the chat, with the option to route it to a channel you own instead: Slack, Discord, or Telegram. Either way your decision travels straight to the approval sidecar, never through the model, so a compromised tool can't approve itself.

operator yours

Watch it work first

your part of the job

Every workflow you hand the agent carries a risk you should be able to name. Watch the early runs live, where a wrong file, a page that steers the agent, or a write you would rather hold shows up, and let it run on its own once it has earned your confidence.

Plain misuse: no attacker required.

The model can simply get it wrong: a wrong recipient, an overbroad action, a scheduled run compounding a mistake. Model behavior again — it can't be patched, only contained. These controls narrow what each task can touch and hold writes for review, so a wrong call stays small.

modes in code

Per-tool modes

enforced server side

Every tool runs as always_allow, needs_approval, or blocked: set from chat, enforced by the gatekeeper sidecar. A task gets the tools it needs and nothing else, and a blocked tool disappears from the agent's list.

operator yours

Scope every automation

your part of the job

A task set to run on its own runs while you are away. Hand it only the connectors that task needs: a booking flow wants the browser, a digest wants read-only mail. A narrow set is a small blast radius.

The server itself.

An endpoint on the public internet and a tree of vendored dependencies are an attack surface before any agent is involved. This is the one classical problem here, and it has known answers: tunnels, auth, lockfiles — deterministic controls that hold on their own, with no model in the loop and nothing for you to watch.

oauth in code

Auth in the server, fail-closed

travels with the image

Each MCP server runs its own Google OAuth with a verified-email allowlist, and starts only once an allowlist and credentials are present. Because auth lives in the image, the same container authenticates the same way on a laptop or a cloud VM, across Claude desktop, web, and mobile.

no-ports in code

Zero inbound ports

the tunnel dials out

A Cloudflare Tunnel sidecar dials outbound to serve each tool's subdomain: TLS at the edge, home IP hidden, the box listening on nothing. The tunnel is transport only; auth stays in the server, so there's a single identity layer.

isolation in code

One tool per container

a bug stays one box

Every tool is its own image with its own secrets and its own subdomain, on a sealed network. When two must cooperate they exchange artifacts through a shared volume, with exactly one writer and the format as the contract, so no tool ever holds another's credentials or network access.

supply-chain in code

Supply chain, locked

CI holds the line

Every tool's dependencies are hash-locked, and CI installs in require-hashes mode, so an unlocked or tampered dependency stays out of main. Dependabot watches each tool's directory, and test_stack.py fails any PR that skips a wiring step, naming the missing piece.

Field notes

Notes from the workbench.

Engineering notes from building and running hardened tools — the patterns that hold up, the ones that quietly fail, and how to tell them apart.