--- title: "What Is an MCP Gateway?" url: "https://atlan.com/know/ai-agent/what-is-an-mcp-gateway/" description: "Learn what an MCP gateway is, how aggregator, proxy, and composite patterns work, and when you actually need one instead of a single MCP server." author: "Emily Winks" author_role: "Data Governance Expert" published: "2026-09-25" updated: "2026-09-25" --- --- An MCP gateway is infrastructure that sits in front of multiple [MCP](https://atlan.com/know/what-is-model-context-protocol/) servers, handling routing, authentication, rate limiting, and observability so clients don't configure every server individually. Atlan's context layer addresses the orthogonal question a gateway leaves open, whether what those servers hand back is correct and governed, not just reachable. The term extends the [Model Context Protocol specification's](https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture) own "MCP Proxy Server" concept from one server to many. Gartner's Innovation Insight: MCP Gateways (2025), [as reported by TrueFoundry](https://www.truefoundry.com/blog/truefoundry-and-the-mcp-gateway-revolution-insights-from-gartners-2025-report), identifies three deployment patterns: aggregator, proxy, and composite. What follows grounds that definition in what the spec actually says, breaks down each deployment pattern, draws the line between a gateway, a single MCP server, and a general AI/LLM gateway, and closes on the governance question a gateway alone doesn't answer. ### Do You Need an MCP Gateway Give it your server count, client count, and who owns them. It returns whether a gateway is warranted and which pattern fits. [Read the skill](/skills/mcp-gateway-need-check.md). *Paste into a new chat* ``` Use the skill at https://atlan.com/skills/mcp-gateway-need-check.md to work out whether we need an MCP gateway and which pattern fits. Ask me for whatever it needs. ``` *Run once in a terminal* ``` curl -fsSL --create-dirs \ -o ~/.agents/skills/mcp-gateway-need-check/SKILL.md \ https://atlan.com/skills/mcp-gateway-need-check.md ``` *For an agent* ``` curl -fsSL https://atlan.com/skills/mcp-gateway-need-check.md ``` Human Agent ClaudeChatGPTGeminiCursorOther Copy .skp{margin:1.75rem 0;padding:1rem 1.125rem 1.125rem} .skp h3{margin:0 0 .375rem!important;font-size:20px!important;line-height:24px!important; font-family:var(--font-funnel-display)!important;font-weight:600!important;color:#2B2B39!important} .skp > p{margin:0 0 .875rem!important;font-size:14px!important;line-height:22px!important;color:#555572!important} .skp > p a{color:#2026D2;text-decoration:underline} .skp-box{margin-bottom:.75rem} .skp-p em{display:block;font-size:10px;font-weight:700;letter-spacing:.06em;text-transform:uppercase; color:#F34D77;font-style:normal;margin-bottom:.25rem} .skp-p > p{margin:0!important} #seo-layout article .skp .skp-p pre{margin:0!important;overflow-x:auto} #seo-layout article .skp .skp-p pre code{color:#2B2B39!important;font-size:12px!important;line-height:19px; white-space:pre-wrap;overflow-wrap:anywhere;background:none;padding:0; font-family:ui-monospace,SFMono-Regular,Menlo,monospace} .skp-p + .skp-p{margin-top:.625rem} .skp-cs{display:flex;flex-wrap:wrap;align-items:center;gap:.375rem} .skp-seg{display:inline-flex;flex:0 0 auto;border:1px solid #DDDDE3;border-radius:999px;overflow:hidden;background:#fff} .skp-m{min-height:32px;padding:.25rem .75rem;border:0;background:transparent;font-family:inherit;color:#77778E;cursor:pointer} .skp-m:hover{color:#2026D2} .skp-m.on{background:#2026D2;color:#fff} .skp-sep{flex:0 0 auto;width:1px;height:20px;background:#DDDDE3;margin:0 .25rem} .skp-tools{display:inline-flex;flex-wrap:wrap;gap:.375rem;min-width:0} .skp-cp{margin-left:auto;min-height:32px;padding:.25rem .75rem;border-radius:999px;background:#fff; font-family:inherit;color:#555572;cursor:pointer} .skp-cp:hover{border-color:#2026D2!important;color:#2026D2} .skp-cs .skp-c{display:inline-flex!important;width:auto;flex:0 0 auto;align-items:center;gap:.375rem; min-height:32px;padding:.25rem .625rem;border-radius:999px;background:#fff;font-family:inherit; color:#555572;cursor:pointer} .skp-cs .skp-c img{display:block!important;width:14px!important;height:14px!important; max-width:14px!important;flex:0 0 auto;opacity:.55;margin:0} .skp-c:hover img,.skp-c.on img{opacity:1} .skp-cs .skp-c:hover{border-color:#797DE4!important;color:#2026D2} .skp-cs .skp-c.on{border-color:#2026D2!important;background:#F4F4FD;color:#2026D2} .skp-agent .skp-tools,.skp-agent .skp-sep{display:none} (function(){ var p=document.querySelector('.skp[data-skill="mcp-gateway-need-check"]');if(!p)return; var panes=p.querySelectorAll('.skp-p'); function show(id){panes.forEach(function(x){x.hidden=x.dataset.skp!==id;});} function cur(){var a=p.querySelector('.skp-p:not([hidden]) pre code');return a?a.textContent:'';} show('prompt'); p.querySelectorAll('.skp-p em').forEach(function(e){ var par=e.parentElement; ((par.tagName==='P'&&par.textContent.trim()===e.textContent.trim())?par:e).hidden=true; }); p.querySelectorAll('.skp-c').forEach(function(b){ b.addEventListener('click',function(){ p.querySelectorAll('.skp-c').forEach(function(x){var on=x===b;x.classList.toggle('on',on);x.setAttribute('aria-pressed',on);}); show(b.dataset.skp); }); }); p.querySelectorAll('.skp-m').forEach(function(m){ m.addEventListener('click',function(){ var agent=m.dataset.skpMode==='agent'; p.classList.toggle('skp-agent',agent); p.querySelectorAll('.skp-m').forEach(function(x){var on=x===m;x.classList.toggle('on',on);x.setAttribute('aria-pressed',on);}); if(agent){show('agent');}else{var s=p.querySelector('.skp-c.on');show(s?s.dataset.skp:'prompt');} }); }); var c=p.querySelector('[data-skp-copy]'); c.addEventListener('click',function(){ navigator.clipboard.writeText(cur()).then(function(){ c.textContent='Copied';setTimeout(function(){c.textContent='Copy';},1600); }); }); })(); --- A few things worth knowing before you evaluate any specific gateway product against this definition: * **The MCP spec never uses the word "gateway."** The closest official term is "MCP Proxy Server," and treating them as synonyms without saying so overstates how settled the vocabulary actually is. * **"Gateway" as a product category is vendor-defined, not spec-defined.** Docker, Kong, and IBM each build the pattern differently, and none of that variation is wrong, it's just not yet standardized. * **A gateway solves reachability, not correctness.** It gets a client to the right server. Whether what that server returns is the accurate, current, governed answer is a different problem entirely. * **You don't need one until you cross a specific threshold.** A single developer with one trusted server and a local config file is not the audience for this infrastructure. **Quick facts** | What It Is | Key Benefit | Best For | Not Needed For | Core Deployment Patterns | | ----- | ----- | ----- | ----- | ----- | | Infrastructure layer in front of multiple MCP servers, extending the spec's "MCP Proxy Server" concept to many-server, many-client scale | Solves the N×M integration problem: one managed access point instead of every client configuring every server | Teams running many MCP servers across many clients with shared credentials, audit, or rate-limit needs | A single developer with one trusted server and a local config file | Aggregator, Proxy, Composite/Hybrid ([Gartner via TrueFoundry](https://www.truefoundry.com/blog/truefoundry-and-the-mcp-gateway-revolution-insights-from-gartners-2025-report), 2025) | --- ## What is an MCP gateway? The [MCP specification](https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture) never uses the word "gateway." The closest official term is "MCP Proxy Server," defined in the spec's own [Security Best Practices page](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices) as "an MCP server that connects MCP clients to third-party APIs, offering MCP features while delegating operations and acting as a single OAuth client to the third-party API server." That's a narrower claim than most vendor marketing implies, and it's worth sitting with before reaching for a product. MCP's architecture is explicitly client-server: an MCP host establishes one MCP client for each MCP server it connects to, over one of exactly two transports, Stdio or Streamable HTTP, [per the spec](https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture). A proxy server is a variant of that same pattern, a server that itself talks to other servers on a client's behalf. A gateway is what the ecosystem built when that pattern needed to scale from one downstream server to dozens or hundreds. That gap between "spec-defined" and "vendor-built" is worth stating plainly, not smoothing over. Docker frames its gateway around container isolation, Kong extends its existing API-gateway lineage into MCP, and IBM's ContextForge unifies MCP alongside other protocols entirely. All three are legitimately "MCP gateways." None of them is what the specification formally defines. Gartner naming this an "Innovation Insight" category is evidence the pattern is real and analyst-recognized, even while the protocol's own documentation hasn't caught up to the term yet. None of this happens in isolation from the rest of the protocol stack. [Why MCP matters for AI agents](https://atlan.com/know/mcp/why-mcp-matters-for-ai-agents/) covers the case for the base protocol a gateway extends, and [agent interoperability protocols](https://atlan.com/know/agent-interoperability-protocols/) situates MCP among the other standards (A2A, ANP) an enterprise stack typically ends up running alongside it. A gateway is infrastructure built on top of MCP specifically. It doesn't touch those adjacent protocols directly, which is exactly why the three-way distinction below matters. --- ## How does an MCP gateway work? [Gartner's Innovation Insight: MCP Gateways (2025)](https://www.truefoundry.com/blog/truefoundry-and-the-mcp-gateway-revolution-insights-from-gartners-2025-report), as reported by TrueFoundry, defines gateways as "the missing enterprise layer for registration, discovery, authentication/authorization, and observability across thousands of MCP servers," and names three deployment patterns that structure almost every real implementation. ### Aggregator A central gateway consolidates multiple MCP servers into one access point, so a client makes one connection instead of many. This enables cross-server orchestration, a client can pull tools from several servers in a single session, but it concentrates traffic behind one component, which risks becoming a bottleneck if that component isn't built to scale. ### Proxy A smart intermediary sits in front of one or more servers, handling cross-cutting concerns like SSL termination, authentication, and logging without combining their responses into a unified view. This has less orchestration power than an aggregator but a smaller blast radius if it fails. ### Composite / hybrid Combines aggregator and proxy patterns, often distributed across regions, for flexibility and fault isolation at the cost of more moving parts to operate. **Table: Gartner three-pattern taxonomy** | Pattern | What it does | Trade-off | | ----- | ----- | ----- | | Aggregator | Central gateway consolidates multiple MCP servers into one-stop access, enabling cross-server orchestration | Risks becoming a bottleneck | | Proxy | Smart intermediary for one or more servers, handling SSL termination, auth, and logging, without combining responses | Less orchestration power than aggregator | | Composite / hybrid | Combines both, often across regions | Highest flexibility and fault isolation, highest complexity | Real implementations illustrate the range rather than settle it. [Docker's MCP Gateway](https://docs.docker.com/ai/mcp-catalog-and-toolkit/mcp-gateway/) is documented as a container-native aggregation and access-control layer. [Kong's AI Gateway](https://konghq.com/products/kong-ai-gateway) extends Kong's existing API-gateway product to add MCP support, including generating MCP interfaces from existing REST APIs. [IBM's ContextForge](https://github.com/IBM/mcp-context-forge) is an Apache-licensed open source project that unifies MCP, A2A, REST, and gRPC behind one endpoint, closer to a proxy-and-aggregator hybrid than a pure single pattern. [WSO2's AI Gateway](https://wso2.com/ai/) is a fourth variant, built on WSO2's existing API management platform rather than from scratch. None of these four is more "correct" than the others; they're solving the same underlying scaling problem with different architectural bets, and the pattern that fits depends on how many servers you're fronting and how much orchestration you actually need. A gateway's job is fronting real servers, not existing in the abstract, many of them built on the open [reference server implementations](https://github.com/modelcontextprotocol/servers) the MCP project publishes. Named implementations like an [MCP server for dbt](https://atlan.com/know/mcp/mcp-server-for-dbt/), an [MCP server for Databricks](https://atlan.com/know/mcp/mcp-server-for-databricks/), an [MCP server for Snowflake](https://atlan.com/know/mcp/mcp-server-for-snowflake/), and an [MCP server for Salesforce](https://atlan.com/know/ai-agent/mcp-server-for-salesforce/) are typical examples of what sits behind one in a real deployment, each a separate connection a gateway would otherwise force a client to manage on its own. [Databricks' own Unity AI Gateway](https://atlan.com/know/ai-agent/databricks/unity-ai-gateway/) is a useful contrast point too: it solves the model-routing version of this problem, not the MCP-server version, a distinction the next section makes explicit. --- ## MCP gateway vs. MCP server vs. AI/LLM gateway: what's the difference? A single MCP server connects one client to one set of tools. An MCP gateway sits in front of *many* MCP servers, adding routing, auth, and rate limiting across all of them. An AI/LLM gateway routes traffic to model providers like OpenAI, Anthropic, and Google, and isn't MCP-specific at all, a distinction covered in full on [what an AI gateway or LLM gateway actually is](https://atlan.com/know/what-is-ai-gateway-llm-gateway/) rather than restated here. **Table: three-way comparison** | | Single MCP server | MCP gateway | AI/LLM gateway | | ----- | ----- | ----- | ----- | | **Connects** | One client to one server | Many clients to many servers | Apps to model providers (OpenAI, Anthropic, etc.) | | **Scope** | Single tool/data source | Cross-server routing, auth, rate limits | Cross-provider routing, cost/rate control | | **MCP-specific** | Yes | Yes | No | | **Typical trigger** | One developer, one trusted source | Many servers, many clients, shared credentials, audit needs | Multi-model deployments needing a unified API | Most vendor pages only draw the two-way line, why you need a gateway instead of a bare server, without placing an AI/LLM gateway in the same picture. That leaves a real gap: a page that only makes the two-way case gives a reader no way to tell an MCP-specific gateway apart from the model-routing layer, and the two solve different problems that happen to share the word "gateway." [Model Router vs. Model Gateway](https://atlan.com/know/llm/model-router-vs-model-gateway/) goes deeper on that adjacent AI-gateway distinction. For the deep-dive on MCP's client-server mechanics beneath both patterns, see [MCP architecture, explained in depth](https://atlan.com/know/ai-agent/mcp-architecture-deep-dive/), which touches "do I need a gateway" in a single FAQ line and goes no further than that. The distinction that actually matters for a buying decision isn't which vendor's diagram looks cleaner. It's whether you're solving an MCP-scaling problem (many servers) or a model-routing problem (many providers), because a gateway built for one doesn't automatically solve the other. It also sits one level above a separate set of protocol-choice questions worth knowing exist: [MCP vs. function calling](https://atlan.com/know/mcp-vs-function-calling/), [when to use MCP vs. an API](https://atlan.com/know/when-to-use-mcp-vs-api/), [MCP vs. the A2A protocol](https://atlan.com/know/mcp/mcp-vs-a2a-protocol/), and [how to choose between MCP, A2A, and ANP](https://atlan.com/know/mcp/how-to-choose-mcp-a2a-anp/) all address which protocol to use in the first place, a decision that comes before any gateway question, not after it. [Agent skills vs. MCP](https://atlan.com/know/ai-agent/ai-agent-skills/agent-skills-vs-mcp/) and [MCP vs. OpenAI function calling's design philosophy](https://atlan.com/know/ai-agent/mcp-vs-openai-function-calling-design-philosophy/) cover two more adjacent interface debates in the same family. None of these change once a gateway enters the picture; a gateway routes to whichever servers you've already decided to build on MCP. --- ## What problems does an MCP gateway solve? Without a shared access point, every client has to integrate every server individually, the N×M problem: N clients times M servers means N×M separate configurations to build, secure, and maintain. That's a different problem from server discovery, which the [official MCP Registry](https://registry.modelcontextprotocol.io/) addresses by cataloging available servers rather than routing traffic between them. Practitioners are actively comparing gateway options for exactly this reason on threads like [Hacker News's discussion of MCPJungle](https://news.ycombinator.com/item?id=44813791) and its [discussion of Permit's authorization-focused gateway](https://news.ycombinator.com/item?id=47426690), weighing which open source option fits an enterprise production environment rather than debating whether the underlying problem is real. The concrete operational gains map directly to the patterns above: a shared credential store instead of every client holding its own copy, a single audit trail instead of scattered logs across servers, centralized rate limiting instead of each server enforcing its own, and isolation that keeps one server's failure from taking down every client connected to it. Each of these traces back to the aggregator, proxy, or composite pattern doing the actual work, not to the word "gateway" itself. The credential and audit piece overlaps directly with [AI agent identity](https://atlan.com/know/ai-agent/ai-agent-identity/) and the broader [AI security](https://atlan.com/know/ai-security/) question of what an agent is actually authorized to touch, and the same access surface a gateway centralizes is also the one [prompt injection attacks on AI agents](https://atlan.com/know/prompt-injection-attacks-ai-agents/) target when a malicious tool response tries to escalate what an agent does next. The honest counter-signal deserves equal weight: a gateway is real overhead, not free infrastructure. It's justified once you cross from one developer's local config file to a shared platform with many servers, many clients, sensitive credentials, or audit requirements, not before. Teams managing the resulting sprawl of tools and connections face a broader version of this same problem, covered in [agent sprawl](https://atlan.com/know/ai-agent/agent-sprawl/). Adding a gateway before you need one is one more service to run, patch, and monitor for a problem you don't have yet. --- ## Do you need an MCP gateway? Whether you need one comes down to a handful of concrete signals, not a fixed team size or server count. **Table: signals you need a gateway** | Signal present | Lean toward | | ----- | ----- | | One developer, one trusted server, local config | No gateway. A single MCP server is enough | | Multiple teams, multiple servers, shared credentials | Gateway (aggregator or proxy pattern) | | Compliance or audit requirement across MCP traffic | Gateway (proxy or composite pattern) | | Tool-count or context-window pressure from many servers | Gateway (aggregator pattern) | None of these signals demand a gateway in isolation. What changes the calculus is a shared platform: several servers, several client applications, and credentials or audit obligations that a single developer's config file was never designed to hold. That threshold, not a fixed team size or server count, is the real decision point. For the full decision framework, including architecture trade-offs and named implementation guidance for making that call, see [MCP gateway vs. a single MCP server](https://atlan.com/know/ai-agent/mcp-gateway-vs-single-mcp-server/). The same scaling question shows up one layer over, in how an organization tracks the servers and agents themselves rather than just routing traffic between them. [Agent registry vs. MCP registry](https://atlan.com/know/ai-agent/agent-registry-vs-mcp-registry/) covers a parallel but separate infrastructure decision: a gateway routes and secures live traffic, while a registry is the inventory of what exists to route to in the first place. [What is an AI agent registry?](https://atlan.com/know/ai-agent/what-is-an-ai-agent-registry/), [agent registry vs. model registry](https://atlan.com/know/ai-agent/agent-registry-vs-model-registry/), [what is an AWS agent registry?](https://atlan.com/know/ai-agent/aws/what-is-aws-agent-registry/), and [agent skills registry](https://atlan.com/know/ai-agent/ai-agent-skills/agent-skills-registry/) cover that adjacent inventory question in more depth than fits here. --- ## What are common MCP gateway security mistakes? Crossing the threshold into gateway territory adds a security obligation, not just an operational one. A gateway inherits MCP's own proxy security obligations; it doesn't replace them. The spec's [Security Best Practices page](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices) defines exactly what an "MCP Proxy Server" takes on by acting as a single OAuth client and delegating operations on a client's behalf: confused-deputy risk, where the gateway is tricked into acting with more authority than the original caller had, and token-passthrough risk, where a token meant for one downstream service leaks to another. Both attack surfaces exist because centralizing access is exactly what a gateway is built to do. The mistake worth naming directly: a gateway does not automatically fix per-server authorization. Centralizing access changes the shape of the risk, one component to secure instead of many, but a misconfigured gateway now concentrates that risk instead of removing it, since the same central point that simplified routing also became the single thing an attacker needs to compromise. For the broader threat landscape across the MCP ecosystem, not gateway-specific but relevant context for anyone running one, see [Hou, Zhao, Wang, and Wang's threat taxonomy](https://arxiv.org/abs/2503.23278), which categorizes security and privacy risks across the full MCP server lifecycle. --- ## How Atlan approaches MCP gateways A gateway solves reachability and operational governance: which servers, which clients, what rate limits, what audit trail. It does not solve content correctness: whether the metric definition an agent gets back is actually right, whether the lineage behind it is current, or whether the term matches how the business actually uses it. Those are two different failure modes, and fixing the first doesn't touch the second. Atlan runs a hosted, per-tenant Remote [MCP](https://atlan.com/know/what-is-atlan-mcp/) server at `mcp.atlan.com/mcp` that connects MCP-compatible clients, including Claude, Cursor, ChatGPT, Gemini, Copilot, Snowflake, and Databricks, to Atlan's context layer, authenticated via OAuth or API keys that inherit a user's existing Atlan permissions. It exposes asset and semantic search, structured asset queries, lineage traversal, metadata and glossary operations, data quality workflows, SQL queries against connected assets, and controlled metadata updates, the mechanics of which are covered in the [MCP server implementation guide](https://atlan.com/know/mcp-server-implementation-guide/) and [MCP-connected data catalog](https://atlan.com/know/mcp-connected-data-catalog/). Atlan does not market a separate gateway product that aggregates other vendors' MCP servers. The framing is [MCP delivers the transport](https://atlan.com/know/mcp-delivers-business-context/); Atlan is the governed context layer behind it, not a gateway vendor competing with Docker, Kong, or IBM. That's a narrower claim than a gateway vendor's pitch, and it's the accurate one. A gateway gets an agent to the right server. Whether what that server hands back is correct, current, and governed is a separate question, and it's the one that decides whether the agent's answer is actually trustworthy. --- ## The gateway question and the governance question are different problems A gateway is infrastructure for reaching MCP servers at scale: routing, auth, rate limits, and audit trails across many servers and many clients. It doesn't by itself answer whether the context those servers return is correct, current, or governed. A gateway can route a client to the right dbt or Snowflake MCP server flawlessly and still hand back a metric definition that's six months stale; reachability and correctness fail independently of each other. Both problems are real. Solving one doesn't solve the other, and a team that's confident about its gateway architecture can still be running on stale or wrong context underneath it. "Gateway" also remains a vendor-defined category the MCP spec itself hasn't standardized. That's worth knowing going into any evaluation, not as a caveat to smooth over, but as a reason to check what a specific product actually does rather than assume the word means one settled thing across every vendor using it. Where this leads next depends on which half of the problem you're solving for. For the infrastructure question, [context infrastructure for AI agents](https://atlan.com/know/context-infrastructure-for-ai-agents/) and the tool landscape in [agent context layer tools](https://atlan.com/know/ai-agent/agent-context-layer-tools/) go further than a single gateway pattern does. For the governance half, [what is context engineering?](https://atlan.com/know/what-is-context-engineering/), [what is a context graph?](https://atlan.com/know/what-is-a-context-graph/), and [the context layer for AI agents](https://atlan.com/know/context-layer-for-ai-agents/) cover the substance a gateway routes but doesn't govern. A [semantic layer](https://atlan.com/know/semantic-layer/) and a [reference architecture for implementing an enterprise context layer](https://atlan.com/know/how-to-implement-enterprise-context-layer-for-ai/) are reasonable next stops for teams past the definitional stage, and [how to build an AI agent harness](https://atlan.com/know/how-to-build-ai-agent-harness/) covers the layer above both, where an agent actually puts a gateway's routing and a context layer's governance to use. --- ## FAQs about MCP gateways ### 1. What is the difference between an MCP server and an MCP gateway? A single MCP server connects one client to one set of tools or data sources. An MCP gateway sits in front of many MCP servers, adding shared routing, authentication, rate limiting, and observability across all of them. A server is the thing being connected to; a gateway is the infrastructure managing access to many of them at once. ### 2. Do I need an MCP gateway? You likely need one once you have multiple teams, multiple servers, shared credentials, or compliance and audit requirements across MCP traffic. A single developer running one trusted server from a local config file doesn't need this infrastructure yet. ### 3. Is an MCP gateway the same as an API gateway? No, though they're related. Some MCP gateways, like Kong's, extend an existing API gateway product to add MCP-specific support, including generating MCP interfaces from existing REST APIs. A general API gateway isn't MCP-aware by default; it needs that extension to route MCP traffic correctly. ### 4. What is the difference between an MCP gateway and an AI/LLM gateway? An MCP gateway is MCP-specific: it routes and secures traffic to MCP servers. An AI/LLM gateway routes traffic to model providers like OpenAI, Anthropic, and Google, and isn't tied to MCP at all. Teams sometimes need both, one for MCP server access, another for multi-model routing, and they solve separate problems that happen to share the word "gateway." ### 5. What are examples of MCP gateways? Named implementations include Docker's MCP Gateway (container-native aggregation and access control), Kong's AI Gateway (API-gateway lineage extended to MCP), and IBM's ContextForge (open source, unifying MCP alongside A2A, REST, and gRPC). Each builds the aggregator, proxy, or composite pattern differently. ### 6. Is MCP secure without a gateway? A single MCP server still has to meet the spec's own security obligations for proxying and delegated access, with or without a gateway in front of it. A gateway centralizes those obligations into one component rather than eliminating them, which changes the risk shape but doesn't remove the underlying requirements. ### 7. Can I build my own MCP gateway? Yes. Open source projects like IBM's ContextForge provide a starting point, and teams on developer forums regularly build internal MCP control planes for their own infrastructure. The tradeoff is the same as any self-built infrastructure: full control in exchange for owning the maintenance and security review yourself. ### 8. What problems does an MCP gateway solve? A gateway solves the N×M integration problem, where every client would otherwise need to configure every server individually, along with credential sprawl, fragmented audit trails, inconsistent rate limiting, and the isolation risk of one server's failure affecting every connected client. ### 9. Does Atlan have an MCP gateway? Atlan runs a hosted, per-tenant Remote MCP server that connects clients like Claude, Cursor, and Copilot to Atlan's context layer, but Atlan does not market a separate gateway product that aggregates other vendors' MCP servers. MCP is the transport; Atlan delivers the governed context that flows through it. --- ## Sources 1. [Model Context Protocol: Introduction, Model Context Protocol](https://modelcontextprotocol.io/introduction) 2. [MCP Architecture Overview, Model Context Protocol](https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture) 3. [MCP Security Best Practices, Model Context Protocol](https://modelcontextprotocol.io/docs/2026-07-28/tutorials/security/security_best_practices) 4. [Official MCP Registry, Model Context Protocol](https://registry.modelcontextprotocol.io/) 5. [MCP Registry GitHub, Model Context Protocol](https://github.com/modelcontextprotocol/registry) 6. [Docker MCP Gateway Docs, Docker](https://docs.docker.com/ai/mcp-catalog-and-toolkit/mcp-gateway/) 7. [IBM ContextForge (mcp-context-forge), IBM](https://github.com/IBM/mcp-context-forge) 8. [Kong AI Gateway Product Page, Kong](https://konghq.com/products/kong-ai-gateway) 9. [WSO2 AI Gateway, WSO2](https://wso2.com/ai/) 10. [Hacker News: MCPJungle Discussion, Hacker News](https://news.ycombinator.com/item?id=44813791) 11. [Hacker News: Permit MCP Gateway Discussion, Hacker News](https://news.ycombinator.com/item?id=47426690) 12. [MCP Reference Server Implementations, Model Context Protocol](https://github.com/modelcontextprotocol/servers) 13. [MCP Inspector, Model Context Protocol](https://github.com/modelcontextprotocol/inspector) 14. [Truefoundry and the MCP Gateway Revolution: Insights From Gartner's 2025 Report, TrueFoundry](https://www.truefoundry.com/blog/truefoundry-and-the-mcp-gateway-revolution-insights-from-gartners-2025-report) 15. [Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions, arXiv](https://arxiv.org/abs/2503.23278)