--- title: "MCP Server vs. MCP Gateway: What's the Difference and Which Do You Need?" description: "MCP server vs. MCP gateway explained. An MCP server exposes one set of tools to an AI agent; an MCP gateway governs many servers with shared OAuth, credential brokering, tool curation, and observability. Includes a core differences table and a decision guide for which you need." canonicalUrl: "https://zuplo.com/learning-center/mcp-server-vs-mcp-gateway" pageType: "learning-center" authors: "nate" tags: "Model Context Protocol, ai-agents, API Gateway" image: "https://zuplo.com/og?text=MCP%20Server%20vs.%20MCP%20Gateway" --- An MCP server exposes one set of tools, prompts, and resources to an AI agent over the Model Context Protocol. An MCP gateway sits in front of many MCP servers (your own and third-party) and adds the shared infrastructure each server would otherwise build alone: a single OAuth authorization server, upstream credential brokering, tool curation, authorization, observability, and guardrails. In short, the server is what an agent calls; the gateway is how you govern agents calling many servers. If you have wired even one AI agent into Linear, GitHub, Stripe, or an internal API, you have already met an MCP server. The moment you run or consume a second one, you meet the problem an MCP gateway solves. This guide draws a clear line between the two, shows the core differences in a table, gives you a decision guide for which you need, and explains how they work together. ## What Is an MCP Server? An MCP server is a program that speaks the [Model Context Protocol](/blog/why-mcp-wont-kill-apis) and exposes a set of **tools**, **prompts**, and **resources** that an AI client (Claude, Cursor, ChatGPT, a custom agent) can discover and invoke. It is the unit an agent actually connects to. Think of an MCP server as a single API surface designed for agents instead of humans. Where a REST endpoint returns JSON for your frontend, an MCP server advertises a catalog of callable tools (`create_issue`, `list_charges`, `query_logs`) and the agent decides which to call to accomplish a task. A typical MCP server: - Exposes **one system's capabilities**. The Stripe MCP server exposes Stripe tools; the Linear MCP server exposes Linear tools. - Implements **its own auth**. Each server decides how it accepts credentials: an API key, an OAuth token, a pasted secret. - Maintains **its own audit trail**, if it has one at all. - Connects to **one or a few clients** that someone configured by hand. You can build an MCP server from scratch, or generate one from an API you already have. Zuplo, for example, can [turn an existing API's OpenAPI specification into an MCP server](/features/mcp-servers), so every endpoint becomes an agent-callable tool the moment it deploys, with no hand-maintained tool definitions drifting out of sync. (See the Zuplo docs on [generating an MCP server from your API](https://zuplo.com/docs/ai/mcp).) One server, fronting one system, is enough to get an agent doing useful work. The trouble starts when you have several. ## What Is an MCP Gateway? An MCP gateway sits **in front of many MCP servers** and puts each one behind a governed endpoint. It does not replace your servers; it standardizes how agents reach them and adds the cross-cutting concerns that every server would otherwise reimplement on its own. A year ago the interesting question was "do we expose an MCP server?" Today most teams run or consume several at once: a productized server for the platform they sell, third-party servers like Linear, GitHub, and Atlassian for daily work, and a handful of internal servers for their own APIs. Each one is its own OAuth flow, its own credential model, its own audit trail. That sprawl is where **shadow MCP** begins: the same drift as shadow IT, where agents get hooked up to servers nobody on the platform team can see, govern, or revoke. An MCP gateway removes that drift. Distilled to five jobs, a gateway provides: - **Discovery**: a consistent way for agents to find and connect to servers. - **Auth translation**: a single OAuth authorization server that brokers upstream credentials in front of many different credential models, so users click "Connect" instead of pasting tokens. - **Authorization and tool curation**: deciding which tools, prompts, and resources each agent is allowed to see and call. - **Observability**: one audit trail across every server, so you can see and revoke what agents are doing. - **Guardrails**: enforcing protections like rate limiting and prompt-injection or PII scanning on the traffic flowing through. Because MCP is just another protocol for calling APIs, built on the HTTP stack, the right place to govern it is the same place you govern the rest of your APIs: the gateway. The [Zuplo MCP Gateway](https://zuplo.com/mcp-gateway) (public beta as of June 2026) implements the [2025-11-25 MCP spec](https://modelcontextprotocol.io/specification/2025-11-25) over streamable HTTP and fronts both your own and third-party servers from one control plane. ### Virtual MCP servers: how a gateway curates, not merges A common misconception is that a gateway fuses several MCP servers into one super-server. It does not. A gateway governs many servers, but it does so by giving **each upstream its own governed endpoint**. In Zuplo this primitive is the **virtual MCP server**: a curated view of _one_ upstream server that exposes only the tools, prompts, and resources you pick, at its own gateway URL. You might expose the Stripe MCP server with its destructive tools filtered out, so an agent cannot make a mistake you would spend the afternoon apologizing for. Each upstream is curated individually. You do not combine multiple servers into a single virtual server. (See the [MCP Gateway quickstart](https://zuplo.com/docs/mcp-gateway/quickstart).) ## MCP Server vs. MCP Gateway: Core Differences | Dimension | MCP server | MCP gateway | | ------------------- | --------------------------------------------------- | -------------------------------------------------------------------- | | **What it is** | An endpoint exposing one system's tools to an agent | A control plane in front of many MCP servers | | **Scope** | One system (Stripe, Linear, your API) | Many servers, first-party and third-party, at once | | **What agents see** | That server's full tool catalog | A curated view per server (e.g. Zuplo virtual MCP servers) | | **Authentication** | Each server's own auth, often pasted tokens | One spec-compliant OAuth authorization server; users click "Connect" | | **Credentials** | Held per server, often on each client/desktop | Brokered centrally by the gateway | | **Tool curation** | All-or-nothing; whatever the server ships | Hand-pick or disable individual tools, prompts, and resources | | **Observability** | Per-server logs, if any | One audit trail across every server | | **Governance** | Decentralized; easy to lose track of (shadow MCP) | Central place to see, govern, and revoke agent access | | **Who runs it** | Whoever owns that system or API | Platform, IT, or security teams | | **Analogy** | A single API or microservice | An API gateway, applied to MCP traffic | The simplest way to hold it in your head: **an MCP server is a destination; an MCP gateway is the controlled door every agent passes through to reach those destinations.** ## Which Do You Need? A Decision Guide You almost always need at least one MCP **server**: it is how an agent calls anything at all. The real question is _when you also need a gateway_. There are two directions a gateway gets deployed, and your answer usually maps to one of them: - **Outside-in**: you are the API provider. You ship MCP servers to _customer_ agents and need auth, monetization, and tool curation in front of them. - **Inside-out**: you are the consumer. Your _own_ employees and agents connect to third-party MCP servers, and you need to govern that. (Zuplo runs this internally to govern how its team's agents reach Linear, Stripe, Notion, QuickBooks, and ClickHouse.) | Your situation | What you need | Why | | ---------------------------------------------------------------------- | ------------------------ | ------------------------------------------------------------------------------------ | | Getting one agent to call one API or system | **MCP server** | A single server is enough to expose tools; no control plane required yet. | | Prototyping or a hackathon | **MCP server** | Keep it simple; pasted tokens and one client are fine while you learn. | | Exposing your product to customer agents (outside-in) | **MCP server + gateway** | Customers need real OAuth, curated tools, rate limits, and per-tenant observability. | | Running or consuming two or more MCP servers | **MCP gateway** | One OAuth flow, one audit trail, and central tool curation across all of them. | | Employees wiring agents into Linear, GitHub, Stripe, etc. (inside-out) | **MCP gateway** | Stops shadow MCP; gives security a single place to see and revoke access. | | You need to disable or hide specific risky tools | **MCP gateway** | Curate tools per server without forking the upstream. | | You need an audit trail of everything agents do | **MCP gateway** | Observability across servers lives at the gateway, not in each server. | | You are bolting OAuth onto every internal server by hand | **MCP gateway** | The gateway ships a spec-compliant OAuth authorization server once, for all of them. | If you only ever have one server and one trusted client, a gateway is overkill. The instant a second server, an external consumer, or a security review enters the picture, the gateway stops being optional. ## How MCP Servers and Gateways Work Together These are not competing choices. They are layers. Agents connect to the gateway; the gateway connects to your servers; your servers connect to the underlying systems. The gateway curates and governs; the servers do the work. ![AI clients like Claude, Cursor, and ChatGPT all connect to a single MCP gateway that holds OAuth, tool curation, credential brokering, observability, and guardrails. The gateway fans out to one virtual MCP server per upstream (Stripe, Linear, and your own API), and each MCP server connects to its single backing system.](/blog-images/2026-06-10-mcp-server-vs-mcp-gateway/diagram-1.png) Zuplo is built to cover both layers on one platform: - **Build MCP servers from your APIs.** Generate a spec-compliant [MCP server from an existing OpenAPI definition](/features/mcp-servers), so your endpoints become agent tools without hand-written glue. - **Govern many servers with the MCP Gateway.** Front your own and third-party servers with virtual MCP servers, a [full OAuth 2.0 authorization server](https://zuplo.com/docs/mcp-gateway/quickstart) (with [pluggable identity providers](https://zuplo.com/docs/mcp-gateway/auth/configuring-okta) like Okta, Auth0, Entra, Google, and WorkOS), credential brokering, tool curation, and observability. Because a virtual MCP server is a first-class route in Zuplo's OpenAPI-driven config, a single project can ship a REST API, a GraphQL endpoint, and a governed MCP server side by side: the same place you already manage [your other API traffic](/learning-center/what-is-an-api-gateway). ## The Bottom Line - An **MCP server** exposes one system's tools, prompts, and resources to an agent. It is the thing an agent calls. - An **MCP gateway** sits in front of many servers and adds shared OAuth, credential brokering, tool curation, authorization, observability, and guardrails. It is how you govern agents calling many servers. - A gateway does not merge servers into one; it gives each upstream a curated, governed endpoint. - You need a **server** to do anything. You need a **gateway** the moment you have more than one server, an external consumer, or a security requirement. If you want both layers without stitching them together yourself, [Zuplo](https://zuplo.com) generates MCP servers from your APIs and provides the [MCP Gateway](https://zuplo.com/mcp-gateway) to govern them, alongside a full [API gateway](/learning-center/what-is-an-api-gateway) on the same platform. [Spin up a free project](https://portal.zuplo.com/signup) and try it. No credit card required. ## Related Guides - [Why Enterprises Need an MCP Gateway](/blog/why-enterprises-need-an-mcp-gateway). The governance, security, and compliance case for putting a gateway in front of MCP traffic. - [What the Best MCP Gateways Do in 2026](/blog/what-the-best-mcp-gateways-do-in-2026). The capabilities that separate a real MCP gateway from a thin proxy. - [Introducing the Zuplo MCP Gateway](/blog/introducing-zuplo-mcp-gateway). A deep dive on virtual MCP servers, MCP-spec OAuth, and the five whys of an MCP gateway. - [Three Gates of AI Infrastructure: API, AI, and MCP Gateways](/learning-center/three-gates-ai-infrastructure-api-ai-mcp-gateway). How the three gateway types relate and where each one fits. - [The Search-and-Execute MCP Design Pattern](/learning-center/search-execute-mcp-design-pattern). A practical pattern for building MCP servers that scale to large tool catalogs. - [Never Ship an MCP Server Without Rate Limiting](/blog/never-ship-mcp-server-without-rate-limit). Why MCP servers need the same abuse protection as any public API. - [What Is an API Gateway? The Complete Guide](/learning-center/what-is-an-api-gateway). The foundational gateway concepts that MCP gateways build on.