MCP gateways & registries

A single MCP server (a program that offers tools an AI agent can call) wired into one client is simple. Now scale it: an organization with dozens of servers (GitHub, databases, internal APIs) and many clients (the apps that talk to those servers: 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 (a middleman that forwards requests) 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 (a server hiding malicious instructions in a tool description), rate limiting (capping how many calls per minute), and audit logging (a permanent record of who called what) 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. 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 parsing the JSON at all (a WAF is a web application firewall, a filter that blocks bad requests). 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 (a stored copy) for ttlMs (how many milliseconds the copy stays valid) instead of fanning out to twelve servers every time a client connects. Honour cacheScope: public results may be shared across users. private results must not be shared — 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 the following in one place:
  • aggregation
  • auth + secrets + access control
  • security (filtering, rate limits, audit)
  • observability
  • routing
• 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;
  • 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.