What is an MCP gateway? Gateway vs registry, server and managed catalog
Understand how an MCP gateway differs from a registry, a direct MCP server and a managed tool catalog, and when each model is useful.
By Scrollport
In brief
An MCP gateway is a control layer between AI clients and one or more MCP servers. It can centralise routing, policy, authentication and observability. A registry helps clients discover server metadata, a direct server exposes its own tools, and a managed tool catalog packages discovery, execution, access and billing into a product. The right choice depends on whether you need infrastructure control or a ready-to-use tool surface.
An MCP gateway is a control layer between AI clients and one or more MCP servers. It can centralise routing, authentication, policy and observability. A registry publishes metadata so clients can discover servers, a direct MCP server exposes its own tools, and a managed tool catalog packages discovery, execution, access and billing into a product. Use a gateway when you need to govern several servers as infrastructure, not merely because you want an agent to use more tools.
An MCP gateway is a control layer
A gateway sits in the call path. Depending on the implementation, it can present one endpoint, route requests to several MCP servers, apply access policies, manage lifecycle and expose logs or metrics. Docker’s MCP Gateway documentationis one concrete example of that infrastructure pattern.
The protocol itself remains client-server. The official MCP architecturedefines hosts, clients and servers, but does not require every deployment to add a gateway. One trusted server can be connected directly when central routing would add no useful control.
MCP gateway vs API gateway
An API gateway exposes and governs backend APIs for ordinary software clients. It commonly applies authentication, quotas, monitoring and routing to HTTP or gRPC operations described by an API definition. Google Cloud’s API Gateway architectureis one example of that general API-management layer.
An MCP gateway is specific to the connection between AI hosts and MCP servers. It can route tool calls, manage server lifecycle, isolate runtimes and present several server profiles to a client. The two layers can coexist: an MCP server or gateway may still call APIs through a conventional API gateway behind the scenes. Choose the layer according to whether the immediate problem is governing backend APIs or governing the agent’s MCP tool surface.
Gateway, registry, catalog or direct server?
| Model | Primary job | In the execution path? | Who operates it? |
|---|---|---|---|
| Gateway | Route and govern calls across servers. | Yes. | The team or gateway provider. |
| Registry | Publish and discover server metadata. | No. | A registry operator and listing publishers. |
| Managed tool catalog | Package tool discovery, access, execution and commercial controls. | Yes. | The catalog provider. |
| Direct MCP server | Expose one server's tools, resources or prompts. | Yes. | The server publisher or user. |
The official MCP Registry is a metadata repository, not a proxy or marketplace. Itsterms also make clear that listing does not amount to endorsement, verification or a security warranty.
When an MCP gateway is useful
- You operate several MCP servers and want one governed client endpoint.
- You need consistent authentication, allowlists, audit logs or routing policy.
- You need to start, stop or isolate local servers behind a controlled process.
- Your platform team wants infrastructure ownership while application teams consume a stable interface.
A gateway does not remove the need to assess the servers behind it. It concentrates policy enforcement, so a weak gateway configuration can also concentrate risk.
When a managed tool catalog is simpler
Choose a managed catalog when the desired outcome is access to useful tools rather than ownership of MCP infrastructure. A catalog can organise tools by job, expose their current contracts and prices, include provider access and settle usage through one commercial relationship.
Choose direct servers when the set is small and trusted, the AI host already manages the connections well, and the team is comfortable owning each server’s credentials, upgrades and failure modes. Use a registry to find candidates, then evaluate and connect them through the model that fits your controls.
How Scrollport fits
Scrollport is a managed catalog and execution layer, not a generic reverse proxy for arbitrary MCP servers. Its remote MCP connection exposes five stable controls: apps, discover, inspect, run and wallet. Those controls reach published catalog tools without loading every provider definition into the agent’s permanent context.
Read why Scrollport uses a small control surfacefor that progressive-disclosure design, or compare MCP, APIs and CLIs if the immediate choice is how an AI host should connect.
Choose by operational burden
- List the servers or outcomes the agent actually needs.
- Decide whether your team wants to operate routing, policy and server lifecycle.
- Identify who stores credentials and who can revoke access.
- Test discovery, execution, logging and failure recovery with one real workflow.
- Add a gateway only when its central controls justify another infrastructure layer.