MCP server proliferation has created sprawl: dozens of servers, hundreds of overlapping tools, no shared naming, and no map for agents to navigate. Centralizing everything into one server is the wrong fix because it creates a bottleneck and forces one party to speak for capabilities it doesn't own. The right answer is federation — a discovery layer above the servers that indexes, describes, and routes to capabilities without absorbing them, similar to how APIs.io works as a federated catalog for APIs. This federated layer is also where governance questions (which tools touch sensitive data, which servers are trustworthy) finally become answerable, because it's the first vantage point that sees the whole estate without owning it. Machine-readable descriptions of MCP servers (an OpenAPI-like format) are what make this kind of large-scale federation possible.
Questions this post answers
Why shouldn't we build one central MCP server that combines all the tools from different vendors?
Centralizing MCP tools into one server creates a bottleneck because the central server owner ends up speaking for capabilities they don't control and can't keep current. It doesn't scale against an ecosystem shipping new MCP servers every week. The better approach is federation: a discovery layer that indexes and routes to servers while each provider keeps ownership of their own capabilities. Developers weighing MCP architecture tradeoffs can follow federation and governance debates on daily.dev.