Toolport
Fix the tool-list bloat slowing your AI agent
Start new thread

Toolport - Every tool, one port. One MCP setup for all your AI agents

by•
A free, open source, local MCP gateway. Set up each server once and every AI agent shares it (Claude, Cursor, VS Code, Codex, and 29 more). Instead of dumping every tool definition into context, it exposes a few meta-tools your agent searches on demand. Benchmarked and graded for correct answers, that's up to 91% fewer tokens at the same task success. Secrets live in your OS keychain, not client configs. Rug-pulls and tool poisoning get flagged, and destructive calls can wait for your approval.

Add a comment

Replies

Best
Maker
📌
Hey everyone, Tyler here. I built Toolport because I was configuring the same MCP servers over and over. Claude Desktop, Claude Code, Cursor, Codex, VS Code, each one wanted its own JSON file with the same API keys pasted in as plain text. The second problem showed up after the servers were connected. Every MCP server dumps its full tool list into context on every request. Three servers cost me about 24,000 tokens of definitions before I'd asked anything. Toolport sits between your agents and your servers and advertises a handful of small meta-tools instead, so the agent searches for tools when it actually needs them. Benchmarked on a frontier model and graded for correct answers, that works out to up to 91% fewer total tokens at the same task success. On a real 415-tool catalog the definition overhead drops 99.5%. Since a gateway is on the path anyway, I used that position for security. Toolport fingerprints every tool and flags rug-pulls and tool poisoning, marks injection-looking tool output as data rather than instructions, and can pause destructive calls until you approve them from the app. Your agent asks before it drops the table. If you saw the Teams launch back in July, the free app has moved a lot since then. Toolport now speaks the latest MCP spec (2026-07-28) on both sides, while older clients and servers keep working untouched. Code mode lets an agent run a whole tool sequence as one sandboxed server-side script instead of round-tripping every call through the model. Approvals are bound to the exact arguments you saw when you approved them. Client support is up to 33 apps, and there's a headless Docker gateway if you don't want the desktop app at all. It's MIT licensed and fully local, nothing routes through my servers. If you try it, tell me which client or server you'd want supported next. That list drives the roadmap.

This is the exact problem I'm working around right now in Claude Code, dozens of MCP servers deferred so schemas only load into context when a tool actually gets called instead of all upfront. The tradeoff I haven't seen anyone measure: does the search call itself become a tax on turns that end up needing 8 or 9 different tools, or does the savings hold even then?

Maker

 Honest answer: haven't measured the 9-tool turn specifically. But I doubt it flips, because the search tax scales with tools used while flat scales with tools installed × model calls in the turn. A turn deep enough to need 9 tools has 10+ round trips, and flat re-sends the whole catalog on every one.

Concretely: on a 14-server / 415-tool setup that's ~165k tokens per request vs. 886. Nine searches pulling nine schemas is ~3.6k. And when we swept catalog size, lazy's total went down (47k → 40k) as flat's doubled - the overhead is flat no matter what you connect.

 That framing clears it up, the tax scaling with usage instead of catalog size is the part I was missing. Appreciate you running the actual numbers instead of just asserting it.