MCP Server vs API Gateway: What Each One Is For

An API gateway routes, authenticates and rate limits HTTP requests to backend services, and it knows nothing about models. An MCP gateway or server fronts tools that an AI model discovers and chooses to call at runtime. They solve different problems, and many teams end up running both, one at the network edge and one at the tool layer.

The core difference: who decides what gets called

With a traditional API, a developer writes code that calls specific endpoints. The set of calls is fixed when the code is written, reviewed and deployed. The gateway can reason about it with route patterns, quotas and schemas.

With MCP, the caller is a model. It asks the server what tools exist, reads their names and descriptions, and picks one based on a conversation. The set of calls is decided at runtime by something that can be persuaded by text. That single fact changes what a control layer must do.

Key takeaway: an API gateway protects an endpoint from clients. An MCP control layer must also protect the tools from the model, because the model is the client.

Side by side

Concern	API gateway	MCP gateway or server
Unit of control	Route or endpoint	Tool, resource or prompt
Caller	Application code	A model acting through a client
Discovery	OpenAPI or docs, read by developers	tools/list read by the model at runtime
Typical auth	API key, OAuth, mTLS	Bearer key or OAuth 2.1, per the MCP authorization specification
Risky-action handling	Usually none, the code is trusted	Approval gates, allowlists, per-run cost caps
Logging	Request, status, latency	Tool name, arguments, result, caller identity
Main threats	DDoS, credential stuffing, abuse	Tool poisoning, prompt injection, excessive agency

The table shows a lot of overlap in the first rows and a sharp split in the last three. The overlap is why people ask whether one can do the other’s job.

Where an API gateway helps an MCP deployment

Streamable HTTP is still HTTP. An MCP endpoint that you self-host benefits from everything a conventional gateway does well:

• TLS termination and certificate management.
• A web application firewall and bot filtering.
• Global and per-IP rate limits, so a runaway agent loop cannot flood the service.
• Request size limits and timeouts.
• Central identity if your company already issues tokens at the edge.

If you run your own MCP servers, do not skip these. An MCP-aware layer behind a plain edge is a normal and sensible design.

Where it falls short

Consider a request body that says tools/call with the tool name send_email. To a generic gateway it is a POST with a JSON payload to /mcp. It cannot tell a harmless read from a message to your customer list unless you teach it the MCP protocol, parse the body and keep a policy per tool. That is feasible, and some commercial gateways are adding MCP awareness, but it is not what an API gateway does out of the box.

Three gaps appear most often:

1. Per-tool authorisation. Route-level rules see one URL. The tool is inside the JSON-RPC body.
2. Catalogue filtering. A caller should see only the tools it may use, so the response to tools/list has to differ by key.
3. Human approval. Pausing a call until a person agrees is an application behaviour, not a routing one.

What MCP-layer controls look like in practice

BusinessMCP’s page on the tools its MCP endpoint exposes is a good illustration of tool-level control because it states it explicitly. It says each tool is scoped by the API key the owner issues, that a read-only key cannot reach tools marked as writes, and that tools marked as needing approval never act on their own. Per-call prices for its pay-per-call tools are stated in the same place.

The access rules behind that are described in its documentation on exposing an MCP endpoint: each key decides which workspace and tools the caller sees, per-connection allowlists narrow it further, sensitive actions like sending email are approval-gated, and every call is audit logged. None of that is something a generic edge gateway would give you for free.

This does not make the vendor’s approach right for you. It shows the shape of the controls you should expect from the MCP side of the stack, and that is a useful yardstick whatever you buy or build.

Do you need both?

A short guide:

Your situation	Likely setup
One developer, local stdio servers	Neither
Small team using a managed MCP endpoint	The vendor’s endpoint, your SSO, nothing else
Self-hosted MCP servers exposed to the internet	Edge API gateway plus an MCP-aware layer
Regulated company with internal servers	Edge gateway, MCP gateway, central logging, reviewed allowlists

If you are in the third or fourth row, compare projects in our open source MCP gateway roundup and read the security article before choosing.

Common mistakes

• Treating the edge gateway as the whole defence. Rate limits do not stop a model from calling a dangerous tool once.
• Duplicating secrets. Keep upstream credentials in one place, ideally the MCP layer, and not in the edge configuration as well.
• Logging only at the edge. A line saying POST /mcp 200 is useless in an incident. You need the tool name and the caller, which is why MCP audit logging matters.
• Forgetting the streaming transport. Long-lived responses can interact badly with edge timeouts and buffering; test with the real client, not just curl.

A worked example: one agent, two layers

Imagine a support agent that reads tickets and drafts replies, with a self-hosted MCP server in front of your helpdesk.

• Edge gateway: terminates TLS, rejects requests over a size limit, caps each source IP at a sensible request rate and blocks obvious bot traffic. It sees POST /mcp and nothing more.
• MCP layer: authenticates the key, returns only search_tickets and draft_reply to that caller, refuses close_ticket even if called by name, logs each call with the ticket ID and holds the helpdesk token itself.

If the agent loops and fires a thousand searches in a minute, the edge limit catches it. If a ticket contains text telling the agent to close every open case, the MCP layer is what refuses, because the closing tool was never in this key’s policy. Neither layer alone would have covered both situations.

Questions to ask about your own stack

• Can your current gateway read the JSON-RPC body, and does a policy engine use it?
• Does the response to tools/list differ per caller, or is everyone shown everything?
• Is there any place where a tool call can be paused for approval?
• Are cost or call ceilings enforced per key, per tool or per run?
• When something goes wrong, can you name the caller, tool and arguments within minutes?

If the honest answer to most of these is no, the MCP-aware layer is the gap to fill, whether you build it, adopt an open source project or use a hosted endpoint.

A practical approach

Start from the threat, not the product category. List the tools your agents will call, mark each as read, write or irreversible, and decide who may call which. Then choose the layer that can enforce that list. For many teams that is an MCP-aware layer, with the API gateway doing the traditional jobs in front of it. For deeper reading on the underlying protocol differences, BusinessMCP also publishes a comparison of MCP and conventional APIs.