MCP vs API gateway: what is the difference?

Short version

An API gateway protects and routes API traffic. MCP gives AI clients a tool-oriented interface for using capabilities.

Traditional API gateways are built around HTTP APIs, routes, policies, and consumers. MCP is built around AI clients discovering tools and calling them with structured arguments.

They can overlap, but they are not the same layer. In many systems, an MCP gateway may call services that already sit behind an API gateway.

The mental model

An API gateway is usually service-facing. MCP is model-facing.

An API gateway sits in front of HTTP APIs and applies policies such as routing, authentication, rate limits, transformation, and observability. Its consumers are usually applications, services, partners, or developers who already understand the API contract.

MCP sits between an AI client and a set of capabilities. Its consumers are AI applications and agent runtimes that need a tool catalog, human-readable descriptions, structured input schemas, and a server that can execute calls safely. That is a different design problem from exposing routes to conventional software clients.

Comparison

The main difference is the consumer model.

Area	API gateway	MCP
Primary consumer	Applications and services.	AI clients and agent runtimes.
Interface	HTTP routes and API contracts.	Tool catalog and tool calls.
Discovery	API docs, OpenAPI, portals.	tools/list and tool metadata.
Execution concern	Route request to upstream service.	Select and call the right tool with structured arguments.
Description quality	Useful for developers, often written as endpoint documentation.	Critical for model selection because the description helps the agent choose the right tool.
Input model	Request paths, headers, bodies, and API schemas.	Tool arguments shaped for an AI workflow and validated before execution.
Operational risk	Unexpected traffic, broken contracts, auth failures.	Wrong tool selection, excessive agency, unsafe arguments, and sensitive data exposure.

Why both can matter

MCP does not remove the need for good API architecture.

If your APIs already have authentication, rate limits, and service boundaries, MCP can expose selected capabilities to AI clients without changing the upstream system.

A common production pattern is to keep existing API controls in place and add a separate AI-facing layer that curates tools, descriptions, and model-facing access.

How they work together

A mature setup often uses both layers: MCP for the AI-facing surface and an API gateway for the upstream service boundary.

In this flow, the MCP layer is responsible for the model-facing contract: tool names, descriptions, allowed actions, structured arguments, and AI-specific safety controls. The API gateway remains responsible for the HTTP service boundary: upstream routing, API auth, quotas, and service observability.

This avoids forcing the API gateway to understand AI tool selection while also avoiding a direct model-to-API pattern where every endpoint becomes available to the agent.

Common production flow

text

AI client
  -> MCP server or MCP gateway
  -> tool policy, schema validation, audit logging
  -> API gateway
  -> internal REST API or service
  -> validated result returned to the AI client

Decision guide

The right layer depends on the consumer and the risk you are trying to control.

Question	Use an API gateway when...	Use MCP when...
Who is the consumer?	The consumer is an app, service, partner, or human developer.	The consumer is an AI client or agent runtime.
What is being discovered?	Routes, API versions, schemas, and service documentation.	Tools, descriptions, arguments, resources, and prompts.
What needs curation?	API products, routes, plans, and upstream access.	A smaller set of model-safe capabilities with clear tool descriptions.
What is the main risk?	Traffic abuse, service exposure, auth gaps, and contract drift.	Unsafe tool choice, broad action surfaces, weak validation, and prompt-driven overreach.

Common anti-patterns

The most common mistake is treating every existing API endpoint as a good AI tool.

Do not publish a full administrative API as a tool catalog just because an OpenAPI file exists.
Do not assume endpoint documentation is enough for agent-ready tool descriptions.
Do not put upstream API keys into every MCP client configuration.
Do not let an API gateway policy become the only MCP safety control if the AI-facing tool is too broad.
Do not hide business constraints in prompts when they can be enforced in server-side validation.

Sources and further reading

Model Context Protocol architecture overview MCP tools specification

Common questions

Does MCP replace an API gateway?

No. MCP is an AI-facing protocol. An API gateway can still protect and route the underlying HTTP APIs.

Can OpenAPI APIs become MCP tools?

Yes. OpenAPI operations can be represented as MCP tools when the tool schema, description, and execution path are defined clearly.

Should every API route become an MCP tool?

No. MCP tools should be curated for AI workflows. Broad admin routes, destructive operations, and low-value internal endpoints should usually stay hidden unless there is a clear policy and validation model.

Why not let AI clients call APIs directly?

Direct API access can expose broad credentials and unclear operational boundaries. MCP tools provide a curated AI-facing surface.

Where should authentication live?

The AI client should authenticate to the MCP server or gateway. Upstream API credentials should stay server-side so they can be rotated, scoped, audited, and kept out of prompts and local configs.