Why we made AllMCP

AI agents are only agents because they have tools. This is the story of what happened when we gave ours all of them.

We didn't set out to build an MCP hub. We were building OpenMetrix, and OpenMetrix had users, and those users wanted their agents connected to the software they already lived in: their CRM, their spreadsheets, their call tracking.

Early on we made a call that seemed harmless at the time: full API coverage. If we support a provider, we support all of it, not the ten endpoints everyone demos with. Take that seriously and a real CRM connector comes out at 60 or 90 tools. Our amoCRM connector has 91.

The token problem

For a while everything was fine. One provider, two providers. Then users started connecting a third and a fourth, and our agents got slower and more expensive, and it took us longer than I'd like to admit to work out why.

The mechanics are simple once you see them. Every connected provider injects its tools into the agent's toolset, every tool carries a docstring, and the model reads all of it on every single call. It doesn't matter whether the user is asking about deals in the CRM or just saying thanks. Ten providers at forty tools each puts somewhere between 30 and 50 thousand tokens of definitions on every request. You pay for those tokens every time, and the model spends its attention on them instead of on the conversation.

The first fix we reached for is the one everyone reaches for: put the provider names in a system-prompt block and load tools on demand. We almost shipped it. It does stop the bleeding. But the bloat turned out to be a symptom of a bigger gap: an agent holding 400 tool definitions knows a lot of signatures and still has no idea how to do a job.

Skills

That gap became our skills system. A docstring tells the model how to call one tool and what parameters it takes. It should stay short, because everyone pays for it forever. A skill describes how to get from "pause my underperforming campaigns" to actually done, however many connect and discover and call steps that takes. We write skills per category rather than per provider. There is a playbook for CRM work; there isn't one per CRM vendor.

The tenancy wall

Multi-tenancy was the other wall, and honestly the one that pushed us into building this ourselves. When your software runs agents for users, the accounts being connected are theirs, not yours. We gave the existing platforms a fair look. On Composio, user identity was a flat string tag. No hierarchy, no self-service. We would have ended up managing our users' connections for them, by hand, from a dashboard. What we actually needed sounds boring: client, then organization, then user. Three levels, every user holding their own credentials, nobody able to see anyone else's tokens. Us included.

Nobody offered the whole list at once. Real coverage, token efficiency that comes from the architecture instead of prompt tricks, skills, tenancy. So we built it, and it was a genuinely hard architecture problem. The token efficiency was the hardest part by a wide margin.

AllMCP is what came out the other side. When I look at an agent running on it now, I check one thing first: how much of its context window is still conversation. That was the whole point.