What is an MCP gateway, and when do you need one?
Learn where an MCP gateway fits, which access controls to evaluate, and when a shared tool connection needs centralized governance.
The decision in brief
An MCP gateway gives teams a shared place to govern tool requests across clients and connections. It is useful when access rules and evidence need to stay consistent across those paths. Routing, approvals, and audit capabilities vary by implementation.
What an MCP gateway does
Model Context Protocol (MCP) defines how applications connect to servers that expose capabilities such as tools and resources. An MCP gateway sits between those clients and upstream servers or connectors, forwarding supported requests and applying the controls it implements.
The protocol describes hosts, clients, and servers; it does not define a standard gateway feature set. Identity checks, independent approvals, and audit records are capabilities to verify in a particular product.
Durin applies access checks and policy to requests routed through its gateway. It can require an exact write approval and records authorization decisions separately from execution outcomes. Durin does not host or train AI models.
How it differs from an MCP server
An MCP server exposes capabilities and implements or adapts the underlying operations. A gateway provides a shared access point for one or more of those connections. To a client, that access point can itself behave as an MCP server.
Servers still have security responsibilities. The MCP tools specification requires access controls and input validation. A well-designed server can enforce its own authorization; adding a gateway does not make server-side or provider-side controls optional.
When a gateway is useful
Consider a gateway when multiple clients or teams need consistent access rules, connection ownership, write review, or evidence of tool activity. A shared production connection is a useful point to review those needs, but team size alone does not determine the architecture.
A direct connection may be sufficient for a limited use case if the server already provides the required authorization and audit. Read-only access still needs scrutiny: a tool that cannot change data can nevertheless disclose sensitive information.
- Access: can you identify the requester and restrict the connection, tool, and resource?
- Changes: can an upstream tool change without silently expanding access?
- Writes: can you require approval for the operations your team decides need it?
- Evidence: can you distinguish permission to execute from a confirmed result?
- Coverage: can users reach the same systems through a route outside these controls?
A request through Durin
A requester connects an approved client to their Durin MCP endpoint. A tool call must pass current identity, membership, team, connection, credential, reviewed-tool, resource, and inspection checks. Successful login alone does not authorize every connection.
Reviewed requests are allowed by default after those checks. Administrators can deny all tool access, independently require another administrator for writes, or deny writes. The same policy controls apply in sandbox and production; provider authorization and tool readiness still matter.
If approval is required, the action does not execute. A different active administrator reviews the request, and the requester must retry the exact call after approval and before expiry. Approval alone does not start the action.
Durin records the decision before dispatch and the outcome after the attempt. A potentially completed write with no reliable confirmation remains uncertain and is not automatically repeated.
What to test before rollout
Start with one reviewed connection and a low-sensitivity read. Confirm an allowed request, a denied request, and the resulting records. Then use a supported sandbox write to test approval, exact retry, expiry, and an uncertain outcome.
Check identity revocation, tool changes, credential ownership, and bypass paths as part of the same review. A gateway cannot govern a request it never receives. Review the vendor’s security evidence and contractual commitments separately from a successful demo.
Where it fits with existing controls
Your identity provider supplies identity and membership information. Existing API controls protect upstream services. MCP governance connects those controls to tool discovery and invocation; it may be provided by a dedicated gateway or by capabilities in an existing platform.
Use the gateway comparison to identify gaps, then follow the developer guide to evaluate one governed connection.