MetaMCP and the rise of MCP routing layers

MCP solved the agent-to-tool plumbing problem. By mid-2025 most of the major AI surfaces have first-class MCP support, the open tools space of MCP servers covers the common tool surfaces, and the protocol has settled enough that vendors aren't fighting over the basics. That's the good story.

The problem the good story exposed: when an agent has access to twenty MCP servers, and a team has a dozen agents, and an org has hundreds of users with different access, the raw-MCP layer doesn't have answers to "which agent can use which server with which scope," "what's actually happening across all this," and "how do we route requests across servers that overlap in capability." The next layer up (MCP routing, governance, observability) is where MetaMCP and a small cluster of similar tools have started showing up.

MCP routing, one agent, many tool serversAgentasks for toolsMCP Routerpolicy · rate limit · credentialsFilesystemDatabaseSlackGitHubThe router is where governance lives. The agent doesn't hold credentials.The router is where governance lives.

mcp-routing-layer

Let me lay out why this layer exists, what it does, and where the open questions are.

What the routing layer actually does

The basic shape of an MCP routing layer:

• A registry of available MCP servers with their capabilities, owner, and policies.
• A request router that takes an agent's tool-use intent and figures out which actual MCP server should handle it.
• A scope-and-access layer that enforces which agents can use which servers with which capabilities.
• An observability layer that captures what's flowing through, which agent called which tool with which arguments, what came back, how long it took, what it cost.
• A configuration surface that lets ops change routing, scopes, and policies without changing agent code.

That's the shape. MetaMCP is one specific instance; several other tools are doing variants of the same pattern. The category is forming the way Kubernetes formed in 2015, multiple competing builds of a foundation that the prior generation needed but didn't have.

Why the layer is necessary

A few specific problems the raw-MCP architecture doesn't solve cleanly.

Capability overlap across servers. Multiple MCP servers can expose the same kind of tool, three different "search the web" servers, two different "query the database" servers, four different "send email" servers. The agent needs help picking the right one for the context. Routing layers handle this; raw MCP doesn't.

Per-agent scoping. A single MCP server may expose tools that some agents should be able to use and others shouldn't. The HR-bot can read employee records; the support-bot can't. Without a routing layer, the access decisions are baked into either the agent code or the MCP server config; neither place is the right one.

Observability across many servers. When an agent action fails, the failure could be in the agent, the routing, the specific MCP server, or the underlying tool the server wraps. Observability that spans the boundary lets you debug; per-server logging in isolation doesn't.

Rate limiting and cost attribution. A single MCP server hit by many agents needs rate limiting per agent, and the costs the server incurs (downstream API calls, compute, storage) need attribution back to the calling agent. The routing layer is the natural place for both.

Policy enforcement above the per-server level. The OPA-and-AI-agent pattern needs a place to live. The routing layer is the natural insertion point: it sees the structured request, it can call OPA, it can apply the decision, it can log the audit trail. Without a routing layer, the policy enforcement either lives in every server (fragmented, hard to maintain) or in every agent (scattered, easy to bypass).

These problems compound as the agent and server population grows. Small deployments don't need the routing layer; meaningful production deployments do.

What MetaMCP specifically does

MetaMCP is the most-developed of the routing-layer projects in the open-source space as of mid-2025. The shape:

• Combines multiple downstream MCP servers into a single MCP-compatible upstream interface that agents connect to.
• Routes requests based on configured rules, capability match, agent identity, request shape.
• Provides a UI for managing the registered servers and their associated configurations.
• Surfaces observability, request logs, latency metrics, error rates per server.
• Supports authentication and access control at the routing layer rather than per server.

It's not a complete answer to all the routing-layer problems (the policy-as-code integration is still maturing, the rate-limiting features are basic, the cost-attribution layer is shallow). It's a meaningful step up from raw MCP for production deployments that need more than the protocol itself provides.

How this compares to other patterns

A few other projects in the same neighborhood:

Cloud-vendor MCP gateways. AWS, Azure, and Google have started shipping their own MCP-compatible gateways as part of their broader AI-platform offerings. These offer tighter platform integration; they offer less neutrality on the multi-vendor case.

Claude Code's MCP-config layer. Not a standalone routing layer, but the Claude Code project has accumulated meaningful patterns for managing MCP servers at the developer level. Different shape (per-developer workstation, not per-org production); informative for the design space.

The MCP-Bridge pattern. A simpler approach that wraps many MCP servers in a single one, presenting a flat namespace to the agent. Less capable than MetaMCP's routing-and-policy approach; simpler to set up.

Custom-built routing layers. Many of the production AI deployments visible in public reporting have built their own routing layer because none of the off-the-shelf options fit. The pattern of "we use OpenSource X plus a thin wrapper that does the routing we need" shows up repeatedly.

The category is in the early-consolidation phase. Several viable approaches; no clear winner; the shape that emerges over the next year matters because the routing layer becomes load-bearing for production AI agent platforms.

Where this fits in the broader stack

The routing layer sits between agents and MCP servers. Above it, the agent runtime (which orchestrates the agent's reasoning and tool-use). Below it, the MCP servers (which wrap the actual tools). The pattern fits naturally with the agent design patterns, the planner-executor split benefits from a routing layer that can handle different routing for different stages, the tool-scoped subagents pattern benefits from a routing layer that can express the per-subagent scope.

The layer also connects naturally to the middleware-layer story, the routing layer is part of the middleware that makes a production AI deployment reliable. It's not a model-layer concern; it's the operational layer that determines whether the model-layer work scales.

What's still missing

Three categories of work the routing layer hasn't fully addressed yet.

Cross-vendor agent portability. An agent built against MetaMCP-as-routing should ideally port to a different routing layer with minimal change. The standards for "what an agent's view of its tool layer looks like" aren't fully settled. The vendor-specific routing-layer features create lock-in below the agent-runtime level.

Schema and capability negotiation. When the agent asks "what tools are available," the answer comes from the routing layer. The schema for that answer isn't fully standardized; different routing layers expose capabilities in different shapes. Agents written against one shape don't automatically work with another.

Mature policy authoring. The OPA pattern works at the routing layer, but the policy authoring story for typical platform engineers is still rough. Better tooling and standardized policy templates would meaningfully expand adoption.

These gaps will close. The question is which routing-layer project closes them best, and whether the open-source side or the cloud-vendor gateways win the consolidation. My bet is the open-source side wins for shops with serious multi-vendor needs; the cloud-vendor side wins for shops that are committed to a single platform.

What I'd recommend

For platform teams thinking about MCP at production scale:

• Don't run agents directly against raw MCP servers in production. A routing layer is increasingly table stakes for any deployment beyond the prototype scale.
• MetaMCP is a credible starting point for shops that want open-source and multi-vendor neutrality.
• The cloud-vendor gateways are credible starts for shops committed to a single cloud and willing to trade neutrality for platform integration.
• Custom routing layers are still common and not necessarily wrong; the build-vs-buy calculation favors buying once the off-the-shelf options match your specific shape.
• Plan for the routing layer to handle policy enforcement even if you're starting without OPA. The integration point matters; designing for it from day one beats retrofitting it later.

The MCP layer made the agent-to-tool integration tractable. The MCP-routing layer makes the agent-to-tools-at-scale story tractable. We're partway through the maturation of this layer; the next year settles what the production patterns look like. Worth tracking closely if you're shipping serious AI infrastructure.