Toolport: An MCP Server Gateway for Too Many Tools

Connect three or four MCP servers to an agent and the problem shows up fast: every tool definition from every server gets loaded into context on every single request, whether the task needs it or not. This is the mcp server gateway too many tools problem, and it is why agents start ignoring instructions or picking the wrong tool once the list gets long enough. Toolport, a free and open-source project, sits between the agent and every MCP server it is connected to and replaces that flood of definitions with four meta-tools the agent searches on demand.

The product launched on Product Hunt under the name Conduit in June 2026, then relaunched as Toolport in August. Older configuration files that still reference conduit are read as aliases, so existing installs keep working under the new name. As of today, the Toolport launch sits at 149 upvotes on Product Hunt, its third launch on the platform after the original Conduit listing and a smaller Toolport for Teams launch in July.

What the Four Meta-Tools Actually Do

Toolport runs as a local process, MIT-licensed, with builds for Windows, macOS, and Linux. You point your MCP servers at it once, and every AI client that speaks MCP, Claude, Cursor, Codex, and others, connects through the single gateway instead of loading each server directly.

Instead of exposing every underlying tool from every connected server, Toolport's default lazy-discovery mode exposes four tools to the agent:

• toolport_status: reports which servers are enabled, how many tools each one has, and the token savings from running in lazy mode
• toolport_search_tools: takes a natural-language query and returns matching tool schemas from across all connected servers, optionally scoped to one server
• toolport_call_tool: invokes a specific tool by name once the agent has found it via search
• toolport_fetch_result: retrieves results for calls that do not return immediately

A few more tools appear if you turn on optional features, an approval step for destructive actions and manual server enable and disable controls. The core idea is straightforward: the agent no longer needs the full schema for every tool on every server just to decide what to call. It searches for what it needs, gets back only the matching definitions, and calls them. This is the mechanism behind reduce mcp context overhead as a practical strategy rather than a settings toggle, and it is the same lazy tool discovery mcp approach other gateway projects in this space have started converging on.

The Token Numbers, and Why They Should Be Read as Self-Reported

The headline claims are large: up to 91 percent fewer total tokens at equivalent task success, and as much as 99.5 percent less tool-definition overhead on a 415-tool catalog. Those numbers are real outputs of a benchmark the project publishes in its own repository, but they come from the project's own testing, not an independent evaluation, and the scale of that testing is modest.

The published methodology tested one frontier model, run through the Vercel AI Gateway, against two catalog sizes: three servers with 63 tools, and six servers with 183 tools. Each configuration ran five iterations of three read-only tasks, listing items from Stripe, Neon, and Vercel accounts, with success defined strictly as the final answer containing the real account data rather than just completing without error. Both flat mode and lazy-discovery mode succeeded on all 30 runs, and lazy mode used 74 percent fewer tokens at the 3-server size and 91 percent fewer at the 6-server size. The 99.5 percent figure comes from a separate real-world measurement on a 14-server, 415-tool setup and covers definition overhead specifically, not total token usage.

None of that is disqualifying. The benchmark code is public and reproducible, and the tasks are simple enough to grade cleanly. But it is a small sample on one model family, run by the people who built the tool, and it measures a best case: read-only lookups where the agent's search query happens to find the right tool quickly. Overhead reduction on more ambiguous, multi-step tasks, where the agent might need several search rounds to find the right tool, is not covered. Treat the specific percentages as a plausible upper bound from the vendor's own test, not an independently verified number for every workload.

How This Differs From the MCP Spec Going Stateless

It is worth separating this from a different piece of MCP news covered here recently: the protocol specification itself moving toward removing mandatory session state. That is a change to how the MCP protocol works at the transport level, decided by the spec maintainers, and it affects how servers and clients hold state across a connection. Toolport is not a protocol change. It is a practical tool that sits in the space between your agent and the servers you have already connected, solving a different problem: too many tool definitions competing for context on every request. You can be running the newest stateless-capable MCP servers and still hit the tool-list bloat problem Toolport is built for, since the two issues are unrelated.

Setup and What to Check Before Adding It

Installation follows the pattern of most local MCP gateways: install the binary for your platform, point your existing MCP server configs at Toolport instead of directly at your client, and lazy discovery is on by default. Secrets are kept in the OS keychain rather than in plain config files, and the project describes rug-pull detection and injection flagging as part of its security layer, worth verifying directly in the documentation rather than taking as a given, since the detail on how those checks work is thinner than the token-savings write-up.

The honest case for trying Toolport is narrow but real: if an agent is already connected to more than two or three MCP servers and starts missing or mis-selecting tools, this is a low-cost, free, reversible thing to test. It will not fix a badly designed tool schema, and the token savings will vary by how well your queries match toolport_search_tools. But the underlying idea, don't load everything, load what's asked for, is sound engineering regardless of the exact benchmark percentages.