A roundup of MCP infrastructure patterns—aggregating gateways, tool routing, auth layers—that intercept and transform MCP server interfaces before agents ever see them.
Adapted from @JoshARosen# MCP Infra Roundup: The MCP Server Is No Longer Calling the Shots If you are building an MCP interface for your product, there is a good chance your users will not consume it the way you are testing. You might expose an MCP endpoint with twenty tools and assume an agent will connect to it, receive those twenty schemas, and call them directly. But a growing layer of MCP infrastructure, built for scale and production use, can change almost every part of that interaction. Your server can sit behind another endpoint. Its tools can be mixed with tools from other servers. Only a few tool definitions may ever reach the model. In some architectures, the model gets search or a programming interface instead. The same thing is happening on the execution side. Authentication can happen before the request reaches your server. Another layer can decide which tools a user is allowed to see, and a tool call can be intercepted for policy checks or human approval before it executes. The result is that the MCP server itself is starting to become an implementation detail. The interface an MCP server publishes is separating from the interface an agent consumes. Infrastructure in the middle can reshape discovery, tool selection, authentication, and execution before your server ever enters the picture. That makes MCP interfaces harder to test and harder to control. You can no longer assume what context the agent will have around your tools, or even that it will see your tools in the form you published them. Here are the architectures driving that shift. ## Many Servers Become One Endpoint One of the clearest signs that the MCP server is becoming an implementation detail is that an agent no longer needs a separate MCP connection for every server it can use. Cloudflare MCP server portals can put multiple remote MCP servers behind one portal endpoint, while the portal maintains the upstream connections and presents their allowed tools through one MCP surface. (https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/) When an agent invokes a tool, the portal determines which upstream server owns it and proxies the request there. It can also namespace tools to prevent collisions between servers that expose capabilities with the same name. Even your tool names may change before they reach the agent, which is confusing when you also have MCP resources that refer to them by name. Docker’s MCP Gateway follows the same general pattern, as do virtual MCP server implementations such as TrueFoundry’s MCP Gateway. The client connects to one logical endpoint while infrastructure tracks the physical servers underneath it. (https://docs.docker.com/ai/mcp-catalog-and-toolkit/mcp-gateway/) (https://www.truefoundry.com/docs/ai-gateway/mcp-gateway) For an MCP provider, your endpoint may be consumed and modified by another piece of infrastructure rather than consumed directly by the agent. ## Tools Separate From the Servers That Implement Them Putting several servers behind one endpoint still leaves tools grouped according to the servers that implement them. Another set of architectures is breaking that relationship too. Microsoft’s open-source MCP Gateway is the best example. Its control plane manages MCP servers and tools, while its Tool Gateway Router can expose one client-facing MCP endpoint and route each invocation to the backend that implements it. (https://github.com/microsoft/mcp-gateway) The agent needs to understand the capability, but it does not need to understand the server topology underneath it. A server can contribute several tools to a larger catalog, while tools from different servers can appear together. You should now assume that a subset of your tools may appear alongside tools from other vendors in an agent’s context. AWS AgentCore Gateway has another version of this separation. Remote MCP servers can be registered as gateway targets, and their capabilities can either be synchronized into the gateway or discovered dynamically. (https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-target-MCPservers.html) It's easy to see how this could shape agent behavior. Agents make decisions based on the set of actions available to them, and increasingly it may be the gateway shaping that action set. Ultimately, it will come down to the configurable rules and policies that shape which tools are exposed when. ## A New Discovery Pipeline As more of the agent-facing interface gets assembled outside the server itself, discovery starts earlier too. MCP gives clients a straightforward way to discover tools after connecting to a server. At larger scale, several discovery decisions are now happening before that point. The official MCP Registry strives to answer the question of which MCP servers exist in the first place. Publishers register metadata about public servers, while clients and aggregators can search the catalog without already knowing where every server lives. (https://modelcontextprotocol.io/registry/about) Finding a server does not mean an agent should immediately connect to it. An organization may first decide whether the server is trusted, and a particular environment can then decide whether it should be available to an agent. Docker's experimental Dynamic MCP goes even further. An agent does not need to begin with every server already configured. It can search the available MCP catalog and attach a server during the session when the task requires it. (If this sounds a lot like A2A discovery, I agree.) (https://docs.docker.com/ai/mcp-catalog-and-toolkit/dynamic-mcp/) Tool discovery can happen after that, and even then the model may not need every tool from every attached server. Server discovery, server attachment, and tool discovery are becoming separate stages. An MCP server can therefore exist in an organization’s catalog without being attached to the agent, and it can be attached without all of its tools entering model context. ## Tool Definitions As Retrieved Context Aggregating hundreds of tools behind one MCP endpoint solves the connection problem, but it creates another one if every tool definition gets loaded into model context. PayPal has described an internal system that indexes more than 2,000 tools across a large MCP server estate. Instead of giving the model every tool definition, it exposes tool_search and execute_tool. The model searches for the capability it needs, then receives the relevant definitions from the larger catalog. PayPal reported reducing tool-schema context from 140,200 tokens to 1,300 tokens. (https://arxiv.org/abs/2608.23992) This search and execute pattern is starting to show up everywhere now. Solo.io’s agentgateway implements a similar architecture through Search Mode. The gateway gives the model get_tool and invoke_tool instead of presenting every upstream tool. (https://docs.solo.io/agentgateway/standalone/latest/documentation/mcp/tool-mode/) Cloudflare MCP portals can do something similar by exposing search and execution tools over the larger catalog. (https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/) Importantly, a tool description may first need to help a search system distinguish that tool from thousands of alternatives, then help the model use it correctly after retrieval. Your tool may not sit beside the other twenty tools from your product. It may sit in an index containing capabilities from hundreds of products and only enter context when retrieval decides it is relevant. ## Tools As a Programming Interface By now, you've probably heard about Code Mode and MCP, as it's another fundamental way that your tool definitions are changed before the agent sees them. It also changes the interaction patterns for how your tools are used. Solo.io’s Code Mode, and similar Code Mode implementations in other MCP stacks, can replace upstream MCP tools with a single run_code tool. Agentgateway generates typed JavaScript APIs from the MCP capabilities available to the caller, and the model writes a program against those APIs. (https://docs.solo.io/agentgateway/kubernetes/latest/documentation/mcp/tool-mode/code-mode/) With normal tool calling, the model may call one tool, inspect the result, and then call another. In Code Mode, it can write one program that performs several calls and transforms the intermediate results before returning anything to the model. Cloudflare has added Code Mode to MCP portals as well. The model gets search and code execution tools while the portal provides typed access to upstream MCP capabilities. (https://developers.cloudflare.com/changelog/post/2026-03-26-mcp-portal-code-mode/) The MCP server still publishes tools, but the model sees a programming library generated from them instead. It certainly improves token usage and model round trips, but at the expense of slightly altering the semantics of how your tools are used. ## Identity vs. Credentials A direct MCP connection has a fairly simple authentication model. The client authenticates with the server, and the server receives a credential representing the caller. Shared MCP infrastructure can split that into multiple authentication relationships. Cloudflare portals separate authentication to the portal from authentication to the upstream servers, while the portal manages the credentials needed for those downstream calls. AWS AgentCore supports OAuth on-behalf-of token exchange for a more explicit version of this architecture. A client presents a token intended for the AgentCore Gateway, and AgentCore Identity exchanges it for another token intended for the downstream resource. (https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/on-behalf-of-token-exchange.html) The two sides of the gateway can therefore use different credentials while preserving the identity of the original caller. Each downstream service can receive the audience and scopes it expects without handing reusable credentials to the agent. For products publishing MCP, this means your OAuth boundary can become one hop inside a larger identity system. And it also means you cannot assume your OAuth interaction is directly with the client that initiated the work. If you are trying to tie OAuth flows to specific product behavior, that line is now fuzzy. ## Intent Separates From Execution Even if the model decides that it wants to invoke a tool, infrastructure can now prevent that invocation from immediately (or ever) reaching the MCP server. Infrastructure in the middle can make additional decisions first. Cloudflare can route MCP portal traffic through Cloudflare Gateway, where HTTP policies and DLP controls can inspect data headed toward upstream MCP servers. A request containing sensitive information can be blocked before the server receives it. (https://developers.cloudflare.com/changelog/post/2026-03-20-mcp-portal-gateway-routing/) Human approval can sit on the same path. TrueFoundry’s MCP Tool Approvals can intercept selected tools/call requests at the gateway, create a pending approval, and only forward the invocation after it has been approved. (https://www.truefoundry.com/blog/mcp-tool-approval-human-gate-call-path) That creates several places where an attempted action can stop. A tool can be hidden from the user, an invocation can fail authorization, or a valid request can be held for approval. The agent decides what it wants to do, while infrastructure decides whether that action is allowed to execute. By the time a tools/call reaches your server, the request may already have passed through many layers of checks and approvals. ## How To Survive The Infra Transform If the interface an agent sees can be assembled by infrastructure, MCP tools should be designed to survive that transformation. Tool names and descriptions need to make sense outside the context of your own server. Schemas should be explicit enough to support retrieval and code generation. Tool boundaries should reflect unique capabilities rather than assumptions about how a particular client will present them. You likely also need to change how you test your tools. Testing a direct connection from Claude or Codex to your MCP server is no longer enough. Test what happens when your server is aggregated with others, when only a subset of tools is retrieved, when names are namespaced, and when calls pass through external authorization or approval. If your tools only work well when the model sees the complete catalog and your original descriptions exactly as written, they may be brittle in the architectures now forming around MCP. The practical implication is to treat your MCP surface more like a capability contract than a finished user interface. Make each tool independently understandable and self-standing, keep authentication assumptions narrow, and avoid relying on client-specific presentation or ordering. The interface you publish may increasingly become source material for a different interface assembled around the needs of a particular agent, user, or task.
