MCP Gateway vs MCP Proxy vs AI Gateway vs API Gateway

An MCP gateway, MCP proxy, AI gateway, and API gateway can all appear between a client and an upstream system. The important difference is not where the component is drawn. It is which protocol and policy boundary the component owns.

A standard API gateway governs HTTP, gRPC, or other API traffic. An AI gateway adds controls for model-provider APIs, such as token accounting and model-aware routing. An MCP gateway governs Model Context Protocol requests and tool access. An MCP proxy may only bridge or forward MCP traffic. These are deployment patterns, not four mutually exclusive product categories.

This guide uses the current MCP 2026-07-28 specification. That revision made the protocol core stateless and removed the previous initialization handshake and protocol-level sessions. A separate compatibility section explains the 2025-era behavior that existing clients and servers may still use.

Key Takeaways

• The MCP specification defines hosts, clients, and servers. It does not standardize an “MCP gateway” or “MCP proxy” role.
• MCP 2026-07-28 is stateless at the protocol layer. Each request carries its protocol version and client capabilities; server/discover provides optional up-front discovery.
• Current Streamable HTTP uses POST requests to one MCP endpoint. Mcp-Method and Mcp-Name headers let an intermediary route or authorize without parsing the JSON body.
• MCP authorization is optional. When used over HTTP, access tokens must be validated for the intended MCP server; token passthrough is prohibited.
• A protocol-level retry does not make a state-changing tool idempotent. Tool and application semantics must prevent duplicate side effects.

Start with the Standard MCP Roles

The current MCP architecture is host-client-server:

• A host is the AI application that coordinates one or more MCP clients and enforces user-facing security and consent decisions.
• An MCP client is created by the host, communicates with exactly one server, and attaches protocol version and client capabilities to every request.
• An MCP server exposes tools, resources, or prompts to that client.

The protocol does not reserve a gateway role. A component marketed as an MCP gateway therefore needs a concrete definition: Does it terminate and originate MCP connections? Does it aggregate tools from several servers? Does it only forward messages? Does it make tool-level authorization decisions? Those answers matter more than the label.

flowchart LR
  U[User] --> H[AI Host]
  H --> C1[MCP Client A]
  H --> C2[MCP Client B]
  C1 --> G[MCP Policy Layer]
  C2 --> G
  G --> S1[MCP Server A]
  G --> S2[MCP Server B]

MCP 2026-07-28 is stateless at the protocol layer: each request is self-contained. If an application needs state across calls, a server can return an explicit handle that a later tool call supplies as an ordinary argument. This is different from hiding application state in a transport session.

What Is an API Gateway?

An API gateway is an API-focused reverse proxy and policy enforcement point. Depending on the product and configuration, it may provide:

• routing and upstream load balancing;
• TLS termination and service-to-service TLS;
• authentication and authorization integration;
• rate limiting;
• request and response transformation;
• logs, metrics, and trace propagation; and
• lifecycle controls such as route publication and policy rollout.

Those capabilities apply to normal API traffic. They do not automatically make a gateway aware of MCP methods, tools, capabilities, or compatibility eras. A generic gateway can still provide an outer network and identity boundary for an MCP server, while MCP-specific policy requires MCP-aware processing or the standardized MCP routing headers.

What Is an AI Gateway?

An AI gateway focuses on calls from applications to model-provider APIs. Common responsibilities include:

• routing across approved models or providers;
• adapting provider-specific request formats;
• measuring input and output tokens;
• enforcing model, tenant, or budget policy;
• applying prompt and response controls where appropriate;
• preserving streamed model responses; and
• recording model latency, errors, and usage.

An AI gateway handles the application-to-model path. MCP handles the host-to-tool or context server path. One user task may cross both: an agent calls a model through an AI gateway, then uses MCP to invoke a tool through an MCP gateway.

What Is an MCP Proxy?

“MCP proxy” has no single standards definition. In practice, it often means a narrow intermediary that does one or more of the following:

• exposes a remote MCP server through a different network endpoint;
• bridges a local transport to a remote transport;
• forwards Streamable HTTP while applying basic network controls; or
• presents one or more upstream servers behind a stable address.

A proxy may be useful without being a governance platform. Before adopting one, determine which protocol revisions it accepts, whether it translates between modern and legacy eras, how it validates mirrored headers against body metadata, and whether it transforms or only forwards MCP messages.

What Is an MCP Gateway?

An MCP gateway is an architectural pattern for applying centralized policy to agent-to-tool traffic. A production implementation may provide:

• identity-aware access to servers, tools, resources, or prompts;
• tool allowlists scoped to a user, agent, tenant, or environment;
• discovery or aggregation of approved tools;
• MCP request and result audit records;
• rate, concurrency, or budget controls;
• protocol-version and capability checks; and
• routing to eligible, authorized MCP server instances.

MCP 2026-07-28 improves intermediary visibility. Streamable HTTP requests mirror the MCP method and, where applicable, object name into required Mcp-Method and Mcp-Name headers. The message body remains the source of truth, and the transport defines how a mismatch must be rejected. A gateway can use those headers for routing or policy without turning every JSON body into a custom parsing contract.

An MCP gateway can be built beside a standard API gateway, behind it, or as an MCP-aware capability within the same platform. The architecture should avoid two policy layers making contradictory identity, timeout, or retry decisions.

Side-by-Side Comparison

Dimension	API gateway	AI gateway	MCP proxy	MCP gateway
Primary traffic	APIs such as HTTP or gRPC	Model-provider APIs	MCP transport traffic	MCP methods and tool traffic
Protocol awareness	API protocol and route	Model request, response, stream, and usage	Varies; often transport-focused	MCP version, headers, capabilities, and operations
Typical policy object	Route, service, consumer	Model, provider, tenant, token budget	Endpoint or connection	Server, tool, principal, request
State responsibility	Usually request-oriented	Provider stream or application metadata	Depends on translation mode	Modern core is stateless; explicit application handles remain possible
Main value	Central API traffic policy	Model governance and operations	Connectivity or compatibility bridging	Tool governance and auditability
Standardized role	No; deployment pattern	No; deployment pattern	No	No

The rows describe common patterns, not guaranteed product features. Verify each implementation against the protocol revisions and controls you need.

Current MCP Transport Behavior

The current transport specification defines stdio and Streamable HTTP as standard transports; custom transports are also allowed when they preserve protocol semantics.

Streamable HTTP in 2026-07-28

Each message is an HTTP POST to one MCP endpoint. A reply is either a JSON object or a request-scoped SSE stream. Every request carries protocol version and client capabilities in _meta.io.modelcontextprotocol/*; Streamable HTTP mirrors selected values into headers for intermediaries.

Important current behavior includes:

• no initialize/notifications/initialized handshake;
• no protocol-level Mcp-Session-Id;
• server/discover, which a server must implement and a client may call for supported versions and capabilities;
• required Mcp-Method and Mcp-Name request headers where defined;
• subscriptions/listen, a long-lived POST response stream for opted-in change notifications; and
• no SSE event-ID resumability for a broken response stream.

The 2026-07-28 key changes also make list results cacheable using ttlMs and cacheScope. A shared intermediary must respect private cache scope and must never let one principal receive another principal's tool or resource listing.

Legacy 2025-Era Compatibility

Earlier revisions through 2025-11-25 used an initialization exchange and could establish a connection-scoped session with Mcp-Session-Id. The older Streamable HTTP design allowed an HTTP GET listening stream, and still older HTTP+SSE used separate endpoints. These behaviors are legacy compatibility concerns, not the current architecture.

A gateway supporting both eras should:

• detect and validate the declared protocol version;
• keep 2025-era session routing or shared state isolated from modern stateless traffic;
• avoid inventing a session ID for 2026-07-28 requests;
• translate only when semantics are fully defined; and
• log the negotiated or declared era so incidents can be diagnosed.

HTTP+SSE is deprecated under the current feature-lifecycle policy. New implementations should use current Streamable HTTP.

Authentication and Authorization Boundaries

MCP authorization is optional. When an HTTP deployment uses the current MCP authorization framework, the protected MCP server acts as the OAuth resource server. It must accept only access tokens intended for that server and must not pass the caller's token through to an upstream resource.

A sound gateway design answers four questions:

1. Who authenticates the principal? This may be an identity provider integrated with the host or gateway.
2. Who validates the access token? Validate issuer, intended resource or audience, time constraints, and permissions using the token format and authorization-server contract.
3. Who authorizes the specific MCP operation or tool? URL-level permission is often too broad for a server exposing tools with different effects.
4. Which identity reaches a downstream system? Use an explicit delegation or service-identity design. Do not blindly forward the caller's bearer token.

Client and server self-identification in _meta is useful for display, logging, and debugging; it is not authenticated identity and must not drive a security decision by itself. Use short-lived credentials, least privilege, and an auditable mapping from the authenticated principal to tool authorization. Treat tool arguments and results as untrusted data.

Retry, Failure, and Application State

MCP 2026-07-28 removed resumability for a broken Streamable HTTP response. A retried request uses a new request ID. That protocol behavior does not prove that a state-changing tool made no change before the response was lost.

• Give state-changing tools an end-to-end idempotency or deduplication mechanism where replay is possible.
• If the outcome is uncertain and no such mechanism exists, surface that uncertainty instead of silently calling the tool again.
• Pass explicit server-minted handles when an application workflow needs state across calls.
• Bound total deadline and retry count; honor cancellation where the transport supports it.
• Record the original operation identity and every attempt for investigation.

Round-robin routing is straightforward for stateless protocol requests, but application handles may still refer to state stored by a service. Design that storage and failover explicitly.

A Reference Deployment

sequenceDiagram
  participant Host as AI Host / MCP Client
  participant Edge as API Gateway
  participant MCPG as MCP-Aware Gateway
  participant IdP as Identity and Policy Service
  participant Server as MCP Server

  Host->>Edge: Streamable HTTP POST with credential
  Edge->>Edge: TLS, token validation, network policy
  Edge->>MCPG: Authenticated principal and protected context
  MCPG->>MCPG: Validate MCP version and mirrored headers
  MCPG->>IdP: Authorize principal, server, and tool
  IdP-->>MCPG: Scoped decision
  MCPG->>Server: Self-contained MCP request
  Server-->>MCPG: JSON or request-scoped stream
  MCPG-->>Host: MCP response

The edge and MCP-aware layers may be separate services or capabilities of one platform. If separate, the gateway must strip or overwrite untrusted client-supplied identity headers, protect the gateway-to-MCP hop, and let the server trust identity context only from an authenticated gateway path.

Where Apache APISIX and AISIX Fit

Apache APISIX can provide an API traffic layer with routing, authentication integrations, rate limits, observability, and streaming proxy behavior when configured for the workload. Its AI Proxy plugin supports model-provider traffic, but a standard APISIX route should not be described as an MCP-aware gateway by default.

AISIX provides MCP gateway capabilities for publishing and governing MCP tools and supports the current MCP 2026-07-28 era. Verify the documented protocol mode, tool-access model, and deployment topology for the release you operate. Separating these claims matters: APISIX is the open-source API gateway foundation, while MCP aggregation and tool governance require explicit product support.

Selection Checklist

Choose the smallest architecture that meets the policy boundary:

• Use a standard API gateway for normal API routing, identity enforcement, traffic policy, and observability.
• Add an AI gateway for model-provider routing, token usage, model policy, or AI-specific telemetry.
• Use an MCP proxy for a narrow, documented connectivity or protocol-compatibility problem.
• Use an MCP gateway when agents or users need centralized, tool-level authorization, discovery, quotas, and audit controls.

Before production, test:

• 2026-07-28 request metadata and server/discover;
• Mcp-Method/Mcp-Name mismatch rejection;
• JSON and request-scoped streaming responses;
• subscriptions/listen authorization and cancellation;
• expired, mis-audienced, and under-scoped tokens;
• unauthorized or unknown tools;
• uncertain outcomes from state-changing calls; and
• legacy-era isolation if 2025 clients are supported.

FAQ

Is an MCP gateway part of the MCP standard?

No. MCP standardizes host, client, server, messages, transports, and optional authorization. “MCP gateway” is a deployment pattern for applying policy and routing between clients and servers.

Is an MCP proxy the same as an MCP gateway?

Not necessarily. A proxy may only forward or bridge transports. A gateway usually implies centralized identity, authorization, tool policy, audit, and operational controls. Product names alone do not prove those capabilities.

Does current MCP use sessions?

MCP 2026-07-28 removed the protocol-level session and Mcp-Session-Id. Applications can still use explicit state handles passed as tool arguments. Clients and servers supporting 2025-era revisions may retain legacy session behavior for compatibility.

Does current MCP require SSE?

Each Streamable HTTP message is a POST. A response can be a JSON object or a request-scoped SSE stream, and notification subscriptions use a long-lived subscriptions/listen POST response. The old two-endpoint HTTP+SSE transport is deprecated.

Can a standard API gateway protect an MCP server?

Yes, it can provide TLS, token validation, network controls, rate limits, and observability. Tool-level authorization and protocol-version handling require MCP-aware policy or use of the standardized MCP headers.

Should a gateway retry MCP tool calls?

Only when the operation is idempotent or protected by an end-to-end deduplication mechanism. A lost response does not prove that the tool made no change.

Next Steps

• Review the current MCP 2026-07-28 specification.
• Follow Set Up MCP Gateway for current AISIX behavior.
• Review What Is an API Gateway?.
• Compare API gateway platforms.
• Explore AISIX AI Gateway for current AI and MCP gateway capabilities.