When a useful tool no longer needs to exist
In January 2026 my AI coding assistant was handed instructions for every connected tool when most tasks needed one or two, so I made a go-between that let it look up only the tool it needed. I measured it on one setup and stopped maintaining it once the apps running the assistant added their own tool search.
In short
In January 2026 my AI coding assistant received instructions for every connected tool when most tasks needed one or two, so I made tool-hub-mcp to let it look up only the tool it needed. In one tested setup it cut reported input by 38.48%. I explain what that number does and does not show, and why I stopped once Claude Code and Codex added their own tool search.
Picture a small repair at a workbench where, before you can pick up the screwdriver you came for, someone has laid out the instructions for every tool in the workshop. The job is simple, but the bench is already covered with pages you will never read.
In January 2026 my coding-agent setup had a version of that problem. A coding agent is an AI assistant that can read and change code, and mine reached outside tools through several MCP servers, which are connections that let the agent work with things like Jira or a browser. Each server described its tools to the agent before any useful work began. Most tasks needed only one or two of those tools, yet every definition still took up part of the agent's working context, the material it can keep in view while it answers, which left less room for the task in front of it.
The idea was to give the agent a smaller doorway. Instead of receiving every tool description up front, the client, meaning the app that runs the agent, would connect to a single gateway, search it for the tool the current task needed, and call that tool through the gateway. I made tool-hub-mcp to try it. Coding agents produced most of the implementation, while I identified the repeated cost, proposed the gateway, defined how discovery and execution should behave, reviewed the changes and tested the result.
When the agent goes looking for a tool
Using the gateway is a bit like asking at a front desk instead of reading the whole catalogue, and the conversation at that desk settled into two operations. The agent first calls hub_search, which finds matching tools and returns their contracts, the description of how each one is called. Once it has picked a tool, it calls hub_execute, and the gateway passes the request to that tool on its original server. Behind the desk, the gateway kept an index of the available tools and started their server processes when they were needed.
Because search and execution were separate steps, the agent could read how a tool worked before it supplied any arguments. That arrangement had a price, though: every lookup was one more call, starting a server process could add a wait, and everything depended on search returning the right capability in the first place. A smaller starting context would only be worth it if the agent could still finish the work that came after.
When I measured one setup
The repository records a test with Claude Code v2.1.6 and six MCP servers: Jira, Playwright, Outline, shadcn, Chrome DevTools and Figma. With those servers connected directly, the client reported 48,371 input tokens, and through the gateway it reported 29,758, a difference of 18,613 tokens, or 38.48%, in that configuration.
Those numbers answer a narrow question about the input the client reported. A different mix of tools could produce a different result, and over a complete task the agent could spend some of the saved context on the discovery calls themselves. That is why I keep the client version and the server mix beside the numbers, since they explain what was actually measured.
Another test followed the discovery path far enough for Claude Code to find a Figma capability and send the expected request, but the remote API returned an authentication error. So that test showed the routing and the argument flow working, while a successful remote operation stayed outside what it proved.
When the clients caught up
Newer versions of clients such as Claude Code and Codex then added tool search or deferred loading on their own. In my setup, that removed much of the reason to keep a separate gateway between the client and its integrations, because the client could now do that narrowing itself.
Keeping the gateway meant keeping its overhead as well. It still needed configuration, brought its own failure points and could add latency, and I had no external adoption or production use that would justify maintaining that extra layer once the original problem had faded from my work. So I stopped treating tool-hub-mcp as an active project. The repository still includes a local export command for searching the tool index with shell tools, but in my current setup I have no reason to run the main gateway.
What I took from it
Looking back, what I keep from the experiment is the way it made a decision possible. A repeated inconvenience turned into a specific interface and a measurement, and when the software around it changed, the same focus on the original problem made it easier to stop.
The source and benchmark notes are still available if you want a closer look at the setup and its results.