MCP's Topology Is Changing Under Your Feet

Most developers think about MCP as a flat topology. One host application in the center, MCP servers radiating outward like spokes on a wheel. Claude Desktop talks to a filesystem server, a database server, a GitHub server. Clean and simple.

That model was roughly accurate in 2024. It's already wrong.

The Flat Model Breaks

The hub-and-spoke model assumes the host application handles everything: authentication, authorization, audit logging, rate limiting, credential management. For a developer running three MCP servers on their laptop, that works fine. The host is Claude Desktop or Cursor, and the blast radius of a misconfiguration is one person's machine.

Scale that to a team of fifty engineers, each connecting to shared MCP servers that access production databases, internal APIs, and cloud infrastructure. Now every host application is independently managing credentials. There's no centralized audit trail. No unified access policy. No way to revoke a compromised server's access across all clients simultaneously.

This is the same problem that drove the API gateway evolution in the early 2010s. Individual services talking directly to clients created an unmanageable security surface. The solution was inserting a gateway layer that centralized cross-cutting concerns.

MCP is following the same path.

The Gateway Tier

In enterprise deployments, a gateway tier has inserted itself between host applications and MCP servers. The topology is no longer flat. It's two-tier: host to gateway to servers.

Three products illustrate this pattern:

Stacklok separates identity, policy, and observability into discrete layers. Their architecture treats the gateway as the security boundary rather than the individual server. Authentication happens once at the gateway. Policy enforcement is centralized. Every tool invocation is logged with full context: who called what, when, with what parameters, and what the response contained.

MintMCP Gateway provides unified authentication across multiple MCP servers. Instead of each server managing its own credentials, the gateway handles OAuth flows, API key rotation, and session management centrally. The MCP servers behind it become stateless translation layers.

Traefik Hub implements what they call a "Triple Gate" pattern: defense-in-depth where traffic passes through authentication, authorization, and content inspection before reaching the MCP server. Each gate operates independently, so a failure in one doesn't compromise the others.

The pattern across all three is the same. Move cross-cutting concerns up a layer. Let MCP servers focus on protocol translation. Let the gateway handle trust.

What This Looks Like Architecturally

In the flat model:

Host App → MCP Server A (with creds for Service A)
         → MCP Server B (with creds for Service B)
         → MCP Server C (with creds for Service C)

Each server manages its own credentials. Each server is its own security boundary. The host trusts all of them equally.

In the gateway model:

Host App → Gateway (auth, audit, rate limiting, policy)
              → MCP Server A (stateless, no creds)
              → MCP Server B (stateless, no creds)
              → MCP Server C (stateless, no creds)

Credentials live in the gateway. Servers are stateless translators. The gateway enforces isolation between servers. A compromised server can't access another server's resources because it never had the credentials in the first place.

This also changes how you handle the cross-server exfiltration problem. In the flat model, if a malicious MCP server instructs the model to pass data from a trusted server through its own tools, there's nothing stopping it. Both servers are equally trusted by the host. In the gateway model, the gateway can enforce that data from Server A never flows through Server B's tools. The trust boundary is at the gateway, not at the host's goodwill.

Why This Mirrors API Gateway History

If you were building APIs in 2012, you went through this exact transition. Services exposed endpoints directly. Clients called them. Authentication was per-service. Logging was per-service. Rate limiting was per-service.

Then Kong, Apigee, and AWS API Gateway appeared. Cross-cutting concerns moved to a centralized layer. Services got simpler. Security got more manageable. Observability became possible at a system level instead of requiring instrumentation in every individual service.

MCP is replaying this cycle in compressed time. The flat model worked when MCP was a developer tool. As it becomes infrastructure, the gateway tier isn't optional. It's the natural architectural response to the same pressures that created API gateways a decade ago.

What Changes for You

If you're building MCP integrations today, the practical implications are:

Design your MCP servers to be stateless. Don't bake credentials into the server. Accept them from the environment or a gateway. This makes your server portable across deployment topologies.

Separate protocol translation from business logic. Your MCP server should translate between the MCP protocol and your existing service APIs. Business logic stays in the services. The thinner the MCP layer, the easier it is to slot a gateway in front of it.

Anticipate centralized auth. If you're building auth into individual MCP servers right now, you'll probably rip it out later when a gateway takes over that responsibility. Build for it, but build it as a pluggable layer.

Instrument observability now, not later. Gateway-level logging captures every tool invocation across all servers. If you're not logging at the MCP layer today, you have no visibility into what your agents are actually doing with the tools you gave them.

The MCP specification's 2026 roadmap includes middleware standardization, which will formalize how gateways interact with the protocol. The ad-hoc gateway tier is becoming a first-class architectural pattern.

The Bigger Picture

MCP's topology evolution tells you something about where AI infrastructure is heading. The initial wave of any protocol is flat and simple. The production wave adds layers. The mature wave standardizes those layers.

We're at the transition between wave one and wave two. The teams building MCP servers as thin, stateless translators with gateway-ready architecture will have an easier time in wave three. The teams baking everything into monolithic servers are building for a topology that's already changing under them.

The protocol won the standardization battle. The architecture battle is just starting.

---

I'm building with MCP daily as part of Mega-OS (39-agent operating system). This post is part of a series on MCP's actual architecture vs. its perceived architecture. The full analysis, including security model gaps and the context window problem, is on The Alignment Layer.