Toolport
Fix the tool-list bloat slowing your AI agent
333 followers
Fix the tool-list bloat slowing your AI agent
333 followers
Your agent got slower the more MCP servers you added, and it's not the model. Every server dumps its whole tool list into context on every request: 3 servers cost ~24k tokens before you even say hi. Toolport puts them behind one local gateway that exposes 4 meta-tools the agent searches on demand. Measured: 97% less tool overhead per request, ~90% fewer tokens, same task success. Cloud or local, one tool or five. Keys in your OS keychain. Free and open source. Windows, macOS, and Linux.
This is the 3rd launch from Toolport. View more
Toolport
Launched this week
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.
Free
Launch Team / Built With
Toolport
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?
Toolport
@abdullah_javaid3 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.
@tsouth2 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.