MCP gateways & registries

A single MCP server wired into one client is simple. Now scale it: an organization with dozens of servers (GitHub, databases, internal APIs, search) and many clients (IDEs, chat apps, agents). Connect everything directly and you get a tangle — every client configures every server, each server handles its own authentication, and nobody has a central place for security, rate limits, or logging. An MCP gateway untangles it: a proxy that sits between clients and servers, aggregates them behind one endpoint, and centralizes the cross-cutting concerns. It is exactly the AI-gateway pattern, applied to the MCP ecosystem.

One endpoint instead of a mesh

The first win is structural. Without a gateway, M clients each connect to N servers — an M × N mesh of connections and credentials. A gateway collapses that to M + N:

clients, servers = 20, 12
direct    = clients * servers     # every client wires up every server
gatewayed = clients + servers     # clients -> gateway -> servers

print(f"direct mesh: {direct} connections")
print(f"via gateway: {gatewayed} connections")
print(f"reduction:   {direct / gatewayed:.1f}x")

direct mesh: 240 connections
via gateway: 32 connections
reduction:   7.5x

Twenty clients and twelve servers go from 240 point-to-point connections to 32. But the connection count is the least of it — the real value is that the gateway becomes the one place to enforce everything that should be uniform:

What the gateway centralizes

• Aggregation. Many servers appear as one MCP endpoint; a client connects once and gets the union of all tools.
• Auth and secrets. Authentication, per-user/team tool access control, and secret management live in the gateway — individual servers don’t each juggle credentials.
• Security. Input/output filtering, defense against tool poisoning, rate limiting, and audit logging in one chokepoint. MCP servers are a real attack surface, so a central enforcement point matters a lot (MCP security).
• Observability. All MCP traffic flows through one place, so logging and tracing are uniform rather than per-server.
• Routing. The gateway dispatches each tool call to the correct backend server.

What the stateless spec changed here

The 2026-07-28 revision was written partly for this layer, and three of its changes land straight on a gateway:

• No session to pin. The initialize handshake and the Mcp-Session-Id header are gone; every request carries its protocol version, client identity, and capabilities in _meta. The gateway no longer needs sticky routing or a shared session store — plain round-robin across replicas is correct, and a backend can be restarted or scaled out mid-conversation without dropping anyone.
• Routing without parsing the body. Streamable HTTP requests carry Mcp-Method and Mcp-Name headers naming the operation and its target. The gateway — or a rate limiter or WAF in front of it — can treat a tools/call on refund_order differently from a tools/list without deserializing the JSON at all. That is faster, and safer: no routing decision depends on trusting the payload.
• Cacheable listings. tools/list, prompts/list, resources/list, resources/templates/list, and resources/read now return ttlMs and cacheScope. The gateway can serve its aggregated tool list from cache for ttlMs instead of fanning out to twelve servers every time a client connects. Honour cacheScope: public results may be shared across users, private ones must not — a shared cache that ignores that flag leaks one user’s tool list to another, the same mistake as a CDN caching a logged-in page.

Registries: discovery

A registry is the other half: a catalog of available MCP servers — name, description, capabilities, endpoint — so clients and gateways can discover servers instead of hard-coding them, much like a package index. There’s an official MCP registry for public servers, and organizations run private registries for internal ones. A gateway typically pulls its server list from a registry; a client browses the registry to find what’s available.

In one breath

• A fleet of MCP servers + many clients is an M × N mesh of connections and credentials; an MCP gateway proxies it down to M + N (240 → 32 in the demo) behind one endpoint.
• The connection count is minor; the point is centralizing aggregation, auth + secrets + access control, security (filtering, rate limits, audit), observability, and routing in one place.
• Since 2026-07-28 the protocol is stateless: no session to pin (round-robin is fine), Mcp-Method / Mcp-Name headers let you route without parsing the body, and ttlMs + cacheScope make list results cacheable — respect private.
• Registries provide discovery — a catalog of MCP servers (official + private) so clients/gateways find servers instead of hard-coding them.
• It’s the AI-gateway pattern one layer down (in front of tool servers, not model providers) — and, like any gateway, a critical dependency to run for high availability.

Quick check

Next

Gateways are the enforcement point for MCP security, and mirror the AI gateway for model providers. For the advanced server-side capabilities a gateway proxies, see advanced MCP primitives.