Toolport

Every tool. One port. One local gateway for all your MCP servers, shared by every AI client, with far fewer tokens.

Toolport is a local MCP (Model Context Protocol) gateway. You set up and authenticate each server once, and every AI client (Claude, Cursor, Codex, VS Code, and the rest) points at Toolport and shares them, so you stop configuring the same servers separately in each app.

It also fixes what those servers cost your agent. Every MCP server you connect dumps all of its tools into context on every single request, and it adds up fast: just 3 servers (63 tools) cost ~19,000 tokens of definitions before you've asked anything. Toolport advertises a handful of compact meta-tools the agent searches on demand instead, so it pays ~450 tokens (98% less, measured).

Measured on a frontier model: up to 91% fewer total tokens at the same task success (graded for correct answers, not just completion), plus 98% less tool-definition overhead on every request, rising to 99.5% on a real 415-tool catalog (see BENCHMARK.md). That holds whether you run one AI tool or five, on cloud models (where tokens are your bill) or local ones (where tool defs eat your context window).

Fewer tokens - lazy discovery keeps context flat no matter how many servers you connect	One config, every client - set up a server once, every AI tool shares it	Supply-chain security - rug-pull and tool-poisoning detection on the path

Get started in two minutes

1. Download the installer for Windows, macOS, or Linux (details in Install).
2. Add a server from the built-in catalog, or paste a config snippet from any server's docs, and authenticate once.
3. Open Clients and click Connect to Toolport on each AI client you use.

That's the whole setup. Every client now shares the same servers, and new servers you add propagate to all of them. There's a 60-second demo on the website if you want to watch it first.

Why

Every MCP server you connect dumps its full tool list into your agent's context on every request, and most AI clients also want their own separate configuration. So you pay a token tax on every call and reconfigure the same servers in every app. Toolport fixes both.

Fewer tokens

• ~90% fewer tokens. In lazy-discovery mode the gateway advertises four compact meta-tools (toolport_status, toolport_search_tools, toolport_call_tool, toolport_fetch_result) instead of the full catalog, and the agent searches and calls on demand, so context stays flat no matter how many servers you connect. (A few more appear only when you turn the matching feature on: toolport_confirm with approvals, enable/disable with agent control, toolport_run_script with code mode, and your saved routines.) Benchmarked, graded for correct answers: up to 91% fewer total tokens at the same task success, 98% less tool-definition overhead per request, 99.5% at a real 415-tool catalog (BENCHMARK.md). Ask toolport_status for what it has saved you so far.
• Search by intent, not just keywords. toolport_search_tools ranks by relevance across every server, and no tool is ever hidden, any server's full set is one call away. Optional semantic re-ranking (a local or hosted embeddings endpoint) surfaces paraphrased needs like "charge a card"; off by default, pure lexical otherwise.

One setup, every client

• Set up once, use everywhere. Each client points at one gateway. Add and authenticate a server a single time and it appears in every client.
• Paste from any client's docs. Copy a server config snippet straight from an MCP server's installation instructions (Cursor JSON, Codex TOML, VS Code, Zed, Claude Code CLI, or any other supported client) and paste it into the Add Server dialog. Toolport auto-detects the format and pre-fills the fields, including environment variable values.
• Per-agent scoping. Give each client only the servers it should see. A coding agent literally cannot call a billing tool that isn't in its profile.
• One set of agent rules. Write your instructions once and Toolport applies them to every client's own global rules location (AGENTS.md, GEMINI.md, .goosehints, and a toolport-rules.md in the rules directory of clients that read one) instead of you editing each by hand. Keep several named sets and switch between them. Your own content is never overwritten: Toolport either owns its own file or owns a marked block and leaves every other byte alone, and turning a client off removes what it wrote. Each client is off until you turn it on, and a preview shows the exact bytes first. See docs/agent-rules.md.
• Rules Claude Code enforces itself. Write a permission policy once - never rm -rf, never force-push, ask before any push, never read .env - in Claude Code's own rule syntax, and Toolport writes it into every Claude Code profile's settings.json, where Claude Code refuses or asks before a matching native tool call on every call, whatever any hook says. Off and empty by default; only what Toolport added is ever removed. See docs/agent-permissions.md.
• Obvious auth. OAuth or API key, stored once in the OS keychain, a single click per server. Newly-authed servers propagate to connected clients without a restart.
• No secrets in client configs. Clients only ever say "talk to Toolport." Keys live in the OS keychain and are injected at runtime.
• A catalog to grow. Add popular servers from a curated list of 50, or search the official MCP Registry, then authenticate through the same flow.

Security, because the gateway is on the path

• Tool integrity (rug-pull + poisoning detection). Toolport fingerprints each tool when you connect a server and flags it if the definition later changes or a server quietly adds one (a "rug pull"), or if a description or schema carries injection-like content ("tool poisoning"). Detection only, on by default, entirely local.
• Content defense (anti-agentjacking). When a tool returns untrusted content (a Sentry error, a web page, an issue body) with injection-like instructions, Toolport flags it and marks it as external data, not instructions, the separation that blunts indirect prompt injection. Never blocks, on by default.
• Human-in-the-loop approvals. Turn on approval mode and destructive tool calls pause until you approve or deny them in the app, with an OS notification when a call is waiting. Deny actually blocks the call; the agent just sees a declined tool call. Your agent asks before it drops the table.
• Governance and audit. Toggle any tool on or off, or hide every destructive tool from every client with one switch. Every call is recorded with per-server latency and error rates.

Control and extras

• Routines: keep the orchestration that worked. When a multi-step Code Mode run proves itself, promote it to a saved, parameterized routine that survives the session and works from any client. Promotion is the only way in, and every save raises a one-shot desktop approval card showing the summary, the calls, the dependencies, the risk class and the content hash, with no always-allow shortcut. Saved routines are advertised as ordinary tools and check their arguments against the stored schema, and a passive Suggested routines queue in Settings collects repeated same-shape calls instead of nagging the agent mid-task. Routine writes are off until you turn them on.
• Agent control, on your terms. Optionally let an agent enable or disable servers through the gateway (toolport_enable_server / toolport_disable_server), reflected in the app live. Off by default, and the destructive-tool switch always stays yours.
• Full MCP, not just tools. Tools, resources, and prompts are all proxied.
• Test before you wire it up. A built-in playground invokes any tool with a form generated from its schema, so you can confirm a server works without configuring a cli