MCP Aggregator vs Gateway vs Registry

Separate The Three Jobs

A registry is a discovery surface. It answers questions such as which MCP servers exist, who publishes them, what package or remote configuration they advertise, and how a client might install or connect to them. The official registry exposes server entries, versions, remote transport configuration and package metadata; that is useful before connection, but it is not the thing receiving each tools/call.

A gateway is a runtime control point. It sits on the request path and can make decisions while the agent is trying to list or call tools. In MCP terms, that means it can inspect requests such as tools/list and tools/call, apply authorization, route to an upstream server, log the call, bound timeouts, and return a failure that the client can understand. The sibling guide on when to use a gateway goes deeper on that runtime shape.

An aggregator is a fan-in layer. It makes several upstream systems look like one MCP server from the client's point of view. It may federate existing MCP servers, generate tools for systems that do not speak MCP, or both. In practice, many products called gateways also aggregate, and many aggregators add gateway controls. That is fine as an implementation choice. The architectural mistake is forgetting which responsibility you are relying on.

What MCP Actually Sees

The protocol boundary is simple: clients discover tools and call tools. A server that supports tools responds to tools/list with the current set of available tools for the request, including names, descriptions and input schemas. The client later invokes one by sending tools/call with a tool name and arguments. That means a registry entry can tell you that a server exists, but only the runtime server can decide what tools this caller is allowed to see right now.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {}
}

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "github/search_issues",
    "arguments": { "query": "repo:acme/api label:incident" }
  }
}

Those two messages are where an aggregator's design becomes visible. If it simply concatenates every upstream tool into one long list, it has solved client configuration but may have created context bloat. If it namespaces tools by source, it reduces collisions and makes logs easier to read. If it also checks caller grants before returning tools or proxying calls, it is acting as a gateway, not just a fan-in adapter.

The 2026 stateless MCP core makes this split cleaner for HTTP deployments. Requests are self-describing, and method and tool names can travel in HTTP headers for routing and policy. That is a gateway-friendly change: infrastructure can meter, authorize or route a tools/call without depending on a hidden transport session.

Decision Table

Use the table as a design review checklist. If you are choosing a server from a public or internal catalog, you are talking about registry work. If you are deciding whether billing/refund_customer should be callable by a read-only agent key, you are talking about gateway work. If you are trying to replace ten Claude Code, Cursor or VS Code MCP entries with one workspace endpoint, you are talking about aggregation.

The layers also fail differently. A stale registry gives developers bad install instructions. A weak gateway lets the wrong caller reach a sensitive action. A naive aggregator overwhelms the agent with too many tools or lets two upstreams publish ambiguous names like search. The article on namespacing MCP tools covers that last problem in detail.

Concrete Client Shape

The client configuration should reveal whether you are solving discovery or runtime consolidation. With Claude Code, a remote HTTP MCP server can be added with one command. If the team has a single runtime endpoint, the client does not need separate entries for GitHub, Linear, Postgres and Drive:

claude mcp add --transport http workspace-tools https://api.example.com/mcp \
  --header "Authorization: Bearer $WORKSPACE_MCP_KEY"

That command is not a registry. It is the client choosing one runtime MCP server. A registry might have helped the developer find https://api.example.com/mcp, inspect metadata, or install a package. After the command is added, the important behavior happens at request time: what tools/list returns for this key, whether write tools are withheld, how upstream failures are surfaced, and what appears in the audit trail.

A useful aggregator should preserve source identity inside that one endpoint. For example, a GitHub issue search might be exposed as github/search_issues, while a customer lookup generated from a read-only REST endpoint might be crm/get_customer. A gateway policy can then say that a support agent may call crm/get_customer but not stripe/create_refund. For the permission model itself, the sibling article on scoped API keys for agents is the closer read.

Failure Cases To Watch

The first failure is treating registry approval as runtime approval. A server can be legitimate and still expose tools your agent should not call. Registry metadata helps developers choose software; it does not replace per-request authorization, user confirmation or audit logging.

The second failure is deploying an aggregator that has no policy boundary. A fan-in proxy that forwards every upstream tool to every key creates a bigger blast radius than direct client configuration. At least separate read-only and write grants, log the selected source and tool, and reject unauthorized calls before contacting the upstream system. The sibling article on audit logging for tool calls explains what to record once the call path is centralized.

The third failure is using a gateway as a hidden translation layer with unclear errors. If an upstream MCP server is down, the client should learn that the source exists but is unreachable. If a caller lacks permission, the response should say the tool is withheld or forbidden. If a registry URL is wrong, that is a setup problem. Mixing those states into one generic failure makes agents retry the wrong thing and makes humans debug in the wrong layer.

How SPYN3 draws the line

SPYN3 is an aggregator with a gateway's controls. It holds the connections and serves one endpoint, which is the aggregation. It also enforces per-key grants, limits keys to chosen sources and logs every call, which is the gateway part. It is not a registry: its gallery is a curated list of 44 remote MCP servers it knows how to connect, not a public index of servers.