What Is an MCP Gateway? Two Products, One Name
An MCP gateway is one endpoint that fronts many tools. Two very different products share the name, and the difference decides which one you need.
Copy this line to your agent to reach a thousand tools through one MCP endpoint.
set up https://monid.ai/SKILL.md and use context.dev /web/search to research a topic from the live web
Search for "MCP gateway" and you get two products wearing the same label. One is a control plane you put in front of MCP servers you already run, so that an enterprise can audit and authenticate them. The other is a single endpoint that gives an agent access to tools it never installed. Both are real, both are called a gateway, and confusing them is why the term feels vague. This guide separates them, then shows how the second kind works.
What is an MCP gateway?
An MCP gateway is a single Model Context Protocol endpoint that sits between an agent and many tools, so the agent connects once instead of once per tool. That is the whole definition. What splits the market is which problem the gateway is pointed at.
The governance gateway
This one faces inward. You already run several MCP servers, one for your database, one for your ticketing system, one for an internal service, and now security wants to know who called what. A governance gateway aggregates those servers behind one address and adds authentication, authorisation, audit logging, rate limits and policy. Docker's MCP Gateway and Kong's are in this group, and so is most of what currently ranks for the term. The tools already existed; the gateway is there to control them.
The access gateway
This one faces outward. Your agent needs to read a page behind bot protection, enrich a company from a domain, pull a comment thread, transcribe a call. Those tools do not exist in your stack at all, and each vendor that has one wants a signup, a key and usually a monthly minimum before you can make the first call. An access gateway carries a catalog and lets the agent call any of it through one key and one balance. Nothing is installed per tool, and the agent chooses at run time.
Why the distinction matters more than the label
Because the two answer opposite questions. A governance gateway answers "how do I keep control of the tools we run", and its success metric is policy coverage. An access gateway answers "how does my agent get a tool it does not have", and its success metric is catalog breadth and how little friction sits before the first call. Buy the wrong one and you have solved a problem you did not have.
| Aspect | Governance gateway | Access gateway |
|---|---|---|
| Faces | Inward, at servers you run | Outward, at vendors you do not |
| Tools come from | Your own team | A shared catalog |
| Main job | Auth, audit, policy, rate limits | Discovery, one key, one balance |
| Added when | Server count and compliance grow | The agent needs a capability it lacks |
| Fails when | An audit finds an untracked call | The agent cannot do the job at all |
The pattern is that governance is about tools you have too many of, and access is about tools you have none of.
How does an MCP gateway work?
An MCP gateway works by advertising a tool list to the agent, then translating each tool call the agent makes into whatever the real backend needs. The agent only ever speaks MCP. Everything vendor-specific happens on the far side of the gateway.
The handshake
When an agent connects, it asks the gateway what tools exist. A governance gateway answers with the union of the tool lists from the servers it fronts. An access gateway answers with a way into its catalog, which for a large catalog means a search tool rather than a flat list, because a list of a thousand tool definitions would fill the agent's context before it did any work.
That detail is the reason "MCP tool bloat" is a phrase people use. Every tool definition you advertise costs context on every turn, so a gateway that dumps its whole catalog into the handshake makes the agent worse at everything else.
The translation
The agent calls a tool by name with a JSON payload. The gateway maps that to a real request: an HTTP call to a vendor, a query against a database, a job submitted to an async worker. Return values come back as tool results. Auth is the gateway's problem, not the agent's, which is the single biggest practical difference from letting an agent hold API keys directly.
The metering
Somebody has to pay. A governance gateway usually does not meter, because the underlying services are already yours. An access gateway must, because it is calling vendors on your behalf, so the useful design is one balance drawn down per call, with the price visible before the call happens. That is what makes it safe to hand an agent a large catalog: nothing bills until something runs.
What is the difference between an MCP gateway and an MCP server?
An MCP server exposes one set of tools; an MCP gateway exposes many, usually by fronting other servers or a catalog. The protocol does not distinguish them, and that is the source of the confusion: a gateway is an MCP server, in the same way that a reverse proxy is an HTTP server.
What an MCP server is
A single integration, published as tools. The Slack MCP server exposes Slack. A Postgres MCP server exposes queries against a database. One vendor, one scope, and you install it and configure its credentials yourself. Most of what appears in an MCP registry is this.
What changes at gateway scale
The failure mode changes. With three servers, installing and configuring each one is fine. With thirty, you are maintaining thirty sets of credentials, thirty update paths and thirty tool lists competing for the agent's context window, and the agent still cannot reach anything outside those thirty. The gateway exists because per-server management stops scaling before agent ambition does.
The practical test
Ask what happens when the agent needs a tool nobody installed. With MCP servers, a human adds one. With a governance gateway, a human still adds one, and now also updates policy. With an access gateway, the agent searches the catalog and calls it. If your agents pick their own next step, that difference is the whole ballgame.
What is the difference between an MCP gateway and an API gateway?
An API gateway routes requests from software that already knows exactly what it wants; an MCP gateway serves an agent that does not. That is a difference in the caller, not in the plumbing, and it changes what the gateway has to provide.
What carries over
Most of the operational surface. Authentication, rate limiting, retries, observability, request and response shaping: an MCP gateway needs all of it, and the teams who ship API gateways are shipping MCP gateways for exactly that reason. This is not a new discipline.
What does not carry over
Discovery and self-description. An API gateway assumes the client was compiled against a known contract, so a schema lives in a repository and a human read it. An agent has to learn the contract at run time, from the gateway, in tokens it also needs for the actual task. So an MCP gateway is judged on things an API gateway never thought about: whether a tool description is good enough for a model to pick correctly, whether the schema is small enough to be worth loading, and whether the agent can find a tool it did not know existed.
The other thing that does not carry over is billing. An API gateway fronts services you pay for some other way. A gateway that fronts other people's paid APIs has to price each call and show that price before it runs, or the agent is spending money blind.
📖 See also Pay-Per-Call Data APIs vs Subscriptions
How do you build an MCP gateway?
You can build one, and for a governance gateway that is often right, because the servers being fronted are yours and the policy is specific to you. Several open-source projects exist for it. For an access gateway the build is much harder, because the work is not the protocol, it is the catalog: every vendor contract, every schema, every price and every auth flow behind it. What follows is how that side works when it is already built.
For agents
Grab an API key at app.monid.ai, then paste this to your agent and hand it the key:
set up https://monid.ai/SKILL.md
It learns the whole discover, inspect, run workflow itself. More in the agent quickstart.
For humans
npm install -g @monid-ai/cli
monid keys add --label main --key <your-api-key>
More in the CLI quickstart.
Step 1. Discover, so the agent does not need to know the vendor
What it does. Searches the catalog by description rather than by name, which is what lets an agent find a tool nobody told it about.
The endpoints. The whole catalog is at monid.ai/tools: web search and scraping, company and people enrichment, social and platform data, browser automation, generative media and agent telephony.
The call.
monid discover -q "turn a url into clean markdown for a prompt"
What comes back. Ranked endpoints with provider, description, billing shape and a verified tag where we have tested them.
What it costs. Nothing. Discovery is free, which is the property that keeps a large catalog from being expensive to carry.
Step 2. Inspect, so the first call is not a guess
What it does. Returns the input schema, the billing shape and the provider's docs for one endpoint.
The endpoints. context.dev/web/scrape/markdown fetches one URL and returns markdown plus page metadata, with JavaScript rendering and proxying handled server-side.
The call.
monid inspect -p context.dev -e /web/scrape/markdown
What comes back. The query parameters (url, link and image preservation, main-content-only extraction, cache reuse, proxy country), the billing shape, and the docs URL.
What it costs. Nothing. Verified live on 20 August 2026.
Step 3. Run, and pay only for that
What it does. Executes the call and draws the shared balance at the price shown in step 2.
The endpoints. context.dev/web/scrape/markdown for one page; context.dev/web/search when you want search results and their page text in a single round trip.
The call.
monid run -p context.dev -e /web/scrape/markdown \
--query '{"url": "https://modelcontextprotocol.io/", "mainContentOnly": true}' -w 120
What comes back. Clean markdown plus title, language, canonical URL, author, site name and the structured metadata blocks, which is what you want in a prompt rather than raw HTML.
What it costs. A small fraction of a cent per page, billed per call. The search endpoint bills per result instead, so its result count is the dial. Prices at monid.ai/tools.
Give this to your agent
Set up https://monid.ai/SKILL.md, and then use Monid to read this documentation page and summarise the parts that describe the tool handshake.📖 See also Any URL to LLM-Ready Markdown: A Copy-Paste Cookbook
Which endpoint should I use for which job?
| Job | Endpoint | Input | Output | Billing |
|---|---|---|---|---|
| One page to prompt-ready text | context.dev/web/scrape/markdown | url plus extraction options | markdown, title, canonical, metadata | per call |
| Search and read in one hop | context.dev/web/search | query, numResults, domain filters | ranked results with optional markdown | per result |
| Neural search with structure | exa/search | query, type, category | result list with optional contents | per call |
| Domain to company record | pdl/v5/company/enrich | name, website, LinkedIn or ticker | firmographics, funding, headcount, tech stack | per call |
Every row verified with monid inspect on 20 August 2026. The table gives the billing shape, not a figure: per call versus per result is the thing that changes how you architect, and it does not go stale the way a number does.
When do you not need an MCP gateway?
You do not need one when the tool count is small and stable. Two or three MCP servers, installed and configured once, are simpler than any gateway and have one less thing in the path. Adding a router to front two servers is architecture for its own sake.
You do not need an access gateway when the vendor you need has a free tier that covers you. Per-call pricing beats a pile of subscriptions; it does not beat zero, and pretending otherwise would be dishonest.
And if your requirement is genuinely audit and policy over servers your own team runs, the products currently ranking for this term are built for that and we are not. Kong, Docker and the API-gateway vendors moving into MCP are solving the inward problem properly. Monid is an access gateway: it is the right answer when the agent needs a capability nobody in your organisation has bought yet, and the wrong answer when the question is who is allowed to call the internal database.
Conclusion
There is no single thing called an MCP gateway, and that is the answer rather than a dodge. There are two products with one name: a control plane for tools you already run, and an access layer for tools you do not. Ask which of those you need before comparing vendors, because the comparison tables for the two groups do not share a single row.
What matters more than the choice is the property that makes either kind worth having: the agent connects once and stops caring where a tool lives. On the governance side that buys you a place to put policy. On the access side it buys something stranger and more useful, which is an agent that can attempt a job nobody anticipated when the code was written, because discovery is free and only the call costs anything.
That access-layer shape is the one we build. Monid is the OpenRouter for agent tools: the same routing an LLM gateway gives you across models, applied one layer down to the tool calls an agent makes after it has picked one.
Free next step: run monid discover for a capability your agent does not have today, then monid inspect on the top result. Neither spends anything. Start at monid.ai.
FAQ
What is Docker MCP Gateway?
Docker's MCP Gateway is a governance gateway: it aggregates MCP servers you run, in Docker's case largely containers from its own catalog, behind one endpoint with credential handling and policy. It is the inward-facing kind described above, so it manages tools you have rather than supplying tools you lack. Cloud vendors ship comparable products for their own platforms.
What is the difference between an MCP gateway and an MCP registry?
A registry is a directory you read, and a gateway is an endpoint you call. A registry tells a human that a Slack MCP server exists and where to get it; installing and authenticating it is still your job. A gateway is in the request path at run time, which means it can also handle auth, metering and translation. The two are complementary, and a large access gateway effectively contains a registry as its discovery surface.
What is an MCP router?
MCP router and MCP gateway are used interchangeably, with router slightly favoured when the emphasis is on choosing a backend per call and gateway when the emphasis is on control and policy. Neither term is standardised. The distinction that actually predicts what a product does is the inward versus outward one: whether it fronts servers you run or vendors you do not.
What is the difference between an MCP gateway and an MCP proxy?
Proxy is the narrower word: it implies passing calls through to a backend with little added beyond transport, auth and logging. Gateway implies the proxy plus a policy or catalog layer, so a gateway usually decides something and a proxy usually just forwards. In practice vendors use whichever word sounds right for their positioning, and the same product gets both labels. Read what it does to the tool list: if it changes what the agent can see, it is doing gateway work regardless of the name.
Which MCP server gives an AI agent access to live web data?
An access gateway is the general answer, because live web data means several different tools: search, single-page extraction, crawling and platform-specific feeds, usually from different vendors. Through Monid an agent reaches all of those under one key, with context.dev/web/search for search plus page text and exa/search for neural retrieval. There is a fuller comparison in the live web data guide.
Last updated August 2026.
