Context & tools
The material the work starts from: the sources, documents and tools a team already relies on.
Updated May 15, 2026 · 7 min read
MCP Gateway (October 2026)
TL;DR: An MCP gateway is the control plane for Model Context Protocol tool calls: central auth, audit, rate limit, observability, and policy across your AI fleet. Without one, every agent has its own credentials and failure modes. With one, you get a single point of governance for every tool call in the org.
Six primitives every MCP gateway should ship
The same primitives that defined API gateways a decade ago apply to MCP gateways. Without all six, the deployment is research-grade; fine for prototypes, not for production agent fleets touching real systems.
Tool registry
A centrally-managed catalogue of MCP servers any agent or chat client in the org can connect to. typed, versioned, with per-tool access policy.
Auth + secrets
Per-user, per-team, per-tool OAuth + secrets vault so an agent calling an MCP tool inherits the right identity automatically.
Permission policy
Allow / deny per tool per principal, with structured policy (e.g., "the Salesforce MCP tool may be called by Sales agents only").
Audit log
Every tool call logged with caller identity, arguments, result, latency, and cost. Searchable, exportable to SIEM, retained on policy.
Rate limit + budget
Per-tool, per-team, per-user rate limits and monthly token / call budgets. Runaway agents hit the cap, not your invoice.
Observability
OpenTelemetry traces for every MCP call, with latency p50/p95/p99 and error rates dashboards.
How MCP gateway and AI gateway differ
An AI gateway sits in front of LLM providers. The agent or app sends a chat completion request to the gateway; the gateway applies routing policy, caching, rate limits, and audit; the upstream call goes to Anthropic, OpenAI, Google, or DeepSeek.
An MCP gateway sits in front of MCP tool servers. The agent decides to call a tool; the call hits the gateway; the gateway checks the agent has permission to call this tool, applies the right credentials, rate-limits, logs the call, and forwards to the tool server. The tool result returns through the same path.
They are complementary, not competing. Most production AI fleets in 2026 run both in front of every agent, and sometimes as two separate components (Swfte AI gateway + a separate MCP gateway), sometimes consolidated into one runtime (Swfte ships both in one product). The consolidated path is simpler to operate; the split path is sometimes preferred when MCP tool calls need different network locality than LLM calls.
FAQ
What is an MCP gateway?
An MCP gateway is a centralised proxy layer for Model Context Protocol tool calls. Instead of every AI agent or chat client connecting to MCP tool servers directly, they connect through the gateway, which adds authentication, authorisation, audit, rate limiting, observability, and a shared tool registry. The gateway becomes the single control plane for what tools the org's AI fleet can call.
Why do I need an MCP gateway?
Without one, every agent has its own credentials, its own connection list, and its own failure modes. A gateway gives one set of credentials per tool, one access policy per tool, one audit trail across the fleet, and one place to enforce budgets. The same reasons traditional API gateways exist apply to MCP.
Which MCP gateway should I use?
Three credible options in 2026. Swfte ships an MCP gateway as part of the runtime: same control plane that runs your agent fleet. The official Anthropic mcp-proxy is OSS and lightweight, good for single-team deployments. Cloudflare AI Gateway has added MCP support and is a fit for edge-hosted agent fleets. For multi-team enterprise rollouts with audit + governance requirements, the managed runtime path is the standard.
Does an MCP gateway work with Claude, ChatGPT, and other models?
Yes. MCP is provider-agnostic. Any model that supports MCP tool calling; Claude Opus 4.7, Claude Sonnet 4, GPT-5.5, Gemini 3.1 Pro, Grok 4, DeepSeek V4, and can connect through the gateway. The agent or chat client points at the gateway URL; the gateway handles routing, auth, and policy on every tool call.
Is MCP the same as a function calling API?
Related but not the same. Function calling is the per-call mechanism. the model declares what it wants to call, the runtime executes it, the result returns. MCP is the protocol on top, a standard way to describe tools, server capabilities, and resources so any model can discover and use them without bespoke integration code.
Can I write a custom MCP tool server?
Yes: that's the primary use case beyond the public catalogue. The MCP spec is open; SDKs exist for TypeScript, Python, and Go. A custom MCP server typically exposes 1-10 tools backed by your internal systems (CRM, ticketing, knowledge base, internal APIs). The gateway then mediates which agents can call which tools.
Does an MCP gateway add latency?
Yes, but typically < 30ms p95. The gateway runs in the same region as the agents and adds a single network hop plus policy enforcement. The trade is more than worth it given the audit, security, and cost-control benefits.
What is the relationship between an MCP gateway and an AI gateway?
An AI gateway sits in front of LLM providers (Claude, GPT, Gemini). An MCP gateway sits in front of MCP tool servers. They're complementary control planes. Swfte ships both as part of the same runtime; one policy + audit + observability layer covers both LLM calls and tool calls in one place.
Is MCP secure?
The protocol is, and but the security posture depends on the deployment. Without a gateway, every agent holds its own credentials and connects directly to tool servers. A gateway centralises credential storage, enforces access policy, audits every call, and rate-limits to prevent abuse. That is the difference between a research-grade MCP setup and a production-grade one.
Run an MCP gateway in front of your agents
Centralised auth, audit, rate limit, observability, and policy on every tool call. Same runtime that hosts the agents.
Free tier · OpenAI-compatible API · On-prem available
Connection map / MCP Gateway
A support agent requests two different tools
Compare gateway decisions for a fictional support-team principal. Illustrative authored example · snapshot · 7 September 2026. Supplied catalogue copy, not verified performance evidence; this preview does not execute a workflow.
Request / boundary
support-agent → tickets.read
Routing consideration
The principal is allowed to retrieve assigned support tickets.
Gateway decision: allow the read and record caller identity.
Request / boundary
support-agent → tickets.delete
Routing consideration
The delete tool is outside this team’s approved tool policy.
Gateway decision: deny with the missing-permission reason.
Request / boundary
Reviewer → tool-call record
Routing consideration
Inspect the principal, requested tool and resulting policy decision.
Export record: identity, tool and decision connected in one trace.
How the pieces connect
One useful outcome.
Six deliberate layers.
A spatial explanation of the workflow.
Select a stage or scroll to explore.
EXPLORE THE ASSEMBLY
Intelligence
The reasoning step. A model reads the context that was gathered and proposes something a person can act on.
Review boundaries
The limits set before the work runs — what is in scope, what is refused, and who is asked when it is unclear.
Workflow
The sequence itself: the order of steps, the handoffs between them, and where a person is required.
Deployment
How the result reaches the people who use it, and the conditions under which it is allowed to run.
Evidence
What is kept afterwards so a reviewer can retrace the decision: inputs, choices, and the person accountable.
CONCEPTUAL WORKFLOW MODEL — NOT A DEPICTION OF SYSTEM ARCHITECTURE
Illustrative authored example · snapshot · 7 September 2026. Capabilities and figures require confirmation.