tool-hub-mcp: a prototype the clients caught up with
A candid tool-hub-mcp retrospective on its tool-discovery idea, Claude Code token benchmark, AI-assisted implementation, and eventual obsolescence.
In January 2026, I had several MCP servers connected to my coding agent. Their tool definitions occupied context before the agent had done any useful work. Most tasks needed one or two of those tools, yet the client loaded the schemas for all of them.
I made tool-hub-mcp to test a smaller interface. The client would connect to one MCP server, search for a relevant tool when it needed one, and execute the selected tool through the same gateway.
The project is no longer something I actively maintain. Newer versions of clients such as Claude Code and Codex learned to search or defer tools themselves, which removed much of the reason for a separate gateway. I still think the experiment is worth documenting because it started from a real problem and produced a measurable result.
My role in the project
Coding agents produced most of the implementation. I identified the context-cost problem, proposed the gateway, defined how discovery and execution should work, reviewed the generated changes, tested the behavior, and asked for revisions when the result did not match the requirement.
I did not personally write the Go search, process-pool, or storage code. The repository is evidence of an idea I directed and tested. It does not demonstrate experience as a Go, retrieval, or LLM infrastructure engineer.
The hypothesis
The first version exposed a small set of meta-tools instead of forwarding every child server's schema to the model. The interface later centered on two operations:
hub_searchsearched the registered servers and returned matching tools with their schemas.hub_executecalled the chosen tool on its original server.
The implementation indexed the child tools and started their MCP processes when needed. Search and execution stayed separate so the agent could inspect a contract before supplying arguments.
The tradeoff was easy to state. A smaller initial schema should save context, but each task might need an extra search call and a child-process startup. Search quality also became part of the tool's reliability. A cheap gateway that returned the wrong tool would not help.
What the benchmark showed
The repository records a Claude Code v2.1.6 test using six MCP servers: Jira, Playwright, Outline, shadcn, Chrome DevTools, and Figma. Claude Code's JSON output reported these input-token counts:
| Configuration | Input tokens |
|---|---|
| Six MCP servers connected directly | 48,371 |
| tool-hub-mcp as the gateway | 29,758 |
| Difference | 18,613, or 38.48% |
That result supported the narrow claim I cared about: in that configuration, replacing the direct tool schemas with a gateway reduced the input tokens reported by the client.
It did not establish a general saving for every client or task. The server mix mattered, tool definitions varied in size, and an end-to-end task could spend some of the saved context on discovery calls. The repository also contains estimates and larger test results, but I would not combine them into a universal percentage. The six-server measurement is a useful snapshot with its environment stated.
The prototype also completed an end-to-end discovery path in which Claude Code found a Figma capability through the hub and sent the expected request. The remote API returned an authentication error. The test therefore covered routing and argument flow, but stopped before a successful Figma operation.
Why I stopped
tool-hub-mcp addressed a gap in the clients available at the time. Once clients added their own tool search and deferred loading, they could solve the problem closer to the model and runtime. Keeping another server between the client and every integration added setup, failure modes, and latency without enough benefit for my own work.
I did not have external adoption or production usage that justified competing with native support. Continuing would have meant maintaining a compatibility layer for a problem I no longer experienced.
There is still a local export command in the repository for searching a tool index with standard shell tools. It is an interesting fallback. I still have no reason to run the main gateway in my current setup.
What I learned
The most useful part of this project happened before implementation. I noticed a repeated cost in my own workflow, reduced it to a testable interface, and chose a metric the client could report. That made the prototype easier to judge.
The benchmark also taught me to keep measurements attached to their setup. "38.48% in this six-server Claude Code test" is defensible. "MCP context falls by 97%" would need broader and more independent evidence.
Platform tools can have a short useful life. A prototype may confirm the right product direction and still become unnecessary when the platform absorbs the idea. Stopping in that situation is a reasonable maintenance decision.
This project also helped me describe my AI-assisted work more accurately. My contribution was problem selection, product direction, requirements, testing, and feedback. The agents did most of the coding. I can discuss the decisions and the evidence without turning the prototype into experience I do not have.
The source and benchmark notes remain available for anyone who wants to inspect the experiment.