
MCP gateway vs API gateway: which controls do you need?
Compare API and MCP gateway capabilities, check what your existing platform supports, and identify gaps in tool policy, approvals, and audit.
The decision in brief
API gateways and MCP gateways have overlapping capabilities. Keep existing API protection, verify your platform’s MCP support, and add the missing controls for tool access, approvals, and execution evidence. Two product labels do not necessarily require two deployments.
Start with the capabilities
An API gateway commonly routes requests and applies authentication, rate limits, and other policies before traffic reaches a service. An MCP gateway applies routing and controls to MCP connections and messages. The two roles can exist in the same platform.
For example, Azure API Management can expose existing MCP servers or turn managed REST operations into MCP tools, with gateway policies for access and traffic management. It would be inaccurate to assume that an API gateway cannot understand MCP.
The design question is which requirements your configured deployment satisfies. Supporting MCP transport does not by itself prove exact human approvals, tool-change review, or safe handling of uncertain writes.
Compare these controls
Use the same checklist for a dedicated MCP product and an API gateway with MCP support. Ask for a working demonstration of each requirement.
- Transport: confirm the MCP transport and session behavior used by your clients, including streaming and timeouts.
- Discovery: check which tools a requester can see and how changed tool definitions are reviewed.
- Authorization: test tool, connection, credential, and resource restrictions as well as HTTP authentication.
- Approvals: verify who can approve, what the grant binds, when it expires, and how it is consumed.
- Execution: distinguish an authorization decision from a provider result, especially after a write timeout.
- Evidence: trace the requester, connection, tool, decision, approval where required, and outcome without exposing secrets.
HTTP routing and tool authorization
MCP tool calls carry a method, tool name, and arguments inside protocol messages. Multiple tools may share one HTTP endpoint. A rule that only permits that endpoint cannot distinguish a document search from a record deletion.
An MCP-aware policy or integration can inspect the relevant operation. Evaluate that implementation directly: route filters, token validation, and MCP-aware tool controls solve different parts of the request.
An illustrative refund tool makes the distinction concrete. Permission to reach the service does not answer whether this requester may refund this order, for this amount, using this account. Those conditions need enforcement somewhere on the path.
Identity and provider authority
An identity provider establishes identity and can supply groups, app assignments, and other authorization inputs. A gateway and the upstream service must use the relevant inputs to decide whether the requested action is permitted.
Check both sides of the connection: how the client authenticates to the gateway and how the gateway authenticates upstream. A gateway approval cannot grant permissions that the upstream credential lacks. Direct access using another credential remains outside that gateway’s coverage.
Test the approval lifecycle
A confirmation in an agent client, an approved change ticket, and an exact server-enforced approval are different controls. Decide which you need and test the full lifecycle, including changed arguments, revoked membership, expiry, and repeated requests.
In Durin, a different active administrator approves a request bound to its authorization context and argument digest. The requester retries the exact call before expiry. Approval does not automatically execute it, and an uncertain dispatched write is not automatically repeated.
An API request log can help diagnose the HTTP exchange. Also check whether your records identify the policy decision and execution outcome; a successful HTTP response alone does not establish a successful tool action.
Keep, extend, or add
Keep the gateway controls required by your existing APIs. If your platform already supports MCP, first test whether it meets the tool access, review, and evidence requirements above.
Extend that deployment when its supported policies can meet the requirements and your team can maintain them. Add a dedicated service when it provides controls or operating workflows you need. Account for the extra network hop, availability dependency, and ownership.
Durin provides a governed path for reviewed connections, mandatory access checks, configurable write approval, and decision and execution records. Evaluate it with one approved client and a supported sandbox connection before expanding the rollout.