# MCP Gateway > Convert the REST and SOAP APIs you already run into governed MCP tools, or front third-party MCP servers behind one endpoint. Every agent call passes the same identity, quota, and audit gates as your API traffic — operated from the console your team already runs. *MCP Gateway — agent access plane* ## Open your APIs to AI agents. Without opening your perimeter. [See it on a real use case](https://apinizer.com/resources/presentations/apinizer-mcp-gateway-use-case.html) · [Request a demo](https://calendly.com/apinizer/15min) **Highlights** - **Modes** — Tool Expose · Passthrough - **Transports** — Streamable HTTP · HTTP+SSE - **MCP spec** — 2024-11 · 2025-06 · 2026-07 --- ## Capabilities ### From API catalog to MCP tools — one click, nothing rewritten The APIs you already run on Apinizer become MCP tools without a line of code. Pick a REST or SOAP proxy, preview the tools that will be generated — names, methods, paths, schemas — and convert. The source API keeps serving untouched; the new MCP Gateway is created undeployed so an administrator reviews before anything goes live. - Tool names and input schemas generated from the proxy's OpenAPI spec or WSDL - Preview table before anything is written — tool name, HTTP method, endpoint path, schema source - Non-destructive: the source proxy is untouched and keeps serving - Created undeployed — an administrator reviews and deploys deliberately - Called tools dispatch through the source proxy, so its policies, routing, and logging still apply - Scriptable through APIops — create MCP gateways from CI/CD, GitOps style ### Passthrough — govern the MCP servers you didn't build Third-party and in-house MCP servers enter through your gate, not around it. The gateway fronts external MCP servers with your authentication, your quotas, and your audit trail — and can aggregate several upstream servers into one endpoint with a single, deterministic tool catalog. - Front any external MCP server with gateway-side auth, quotas, and audit - Aggregate multiple upstream servers into one endpoint — colliding tool names namespaced deterministically - Tool allow-lists per environment, with variable resolution across dev / test / prod - Upstream auth: Bearer, OAuth2 client credentials, or mTLS — secrets encrypted at rest, never returned by any API - Fail-closed discovery: a tool that has not been discovered and approved is never callable ### Standards-exact protocol — and one-line client onboarding The gateway speaks the MCP revisions the ecosystem actually ships, negotiated per client: Streamable HTTP by default, legacy HTTP+SSE for older clients, and the stateless core revision for the newest. Discovery is published, and onboarding snippets for the popular agent clients are generated from the gateway's real auth policies — not written by hand. - Streamable HTTP (2025-06-18) by default; HTTP+SSE (2024-11-05) and stateless core (2026-07-28) on the same endpoint - Client-proposed, server-negotiated protocol version — unknown versions fall back safely - Discovery document published at .well-known/mcp/server.json - Copy-paste onboarding for Claude Code, Cursor, and Claude Desktop, derived from the proxy's actual auth chain - initialize, ping, tools/list, tools/call — JSON-RPC, spec-exact ### The identity stack you already trust — now on the agent lane MCP proxies run the same policy pipeline as every other Apinizer proxy, so the authentication your security team already approved applies before any tool call executes. On top of it, the agent lane speaks the OAuth 2.1 profile the MCP spec mandates — short-lived, audience-bound, sender-constrained tokens that terminate at the gateway. - OAuth2 / OIDC, JWT, API key, Basic, Digest, mTLS — the full policy chain runs before the JSON-RPC handler - LDAP and Active Directory roles govern agents the same way they govern users - OAuth 2.1 resource-server semantics — audience-bound (RFC 8707), DPoP sender-constrained (RFC 9449) tokens - Agent tokens end at the gateway; token exchange (RFC 8693) issues short-lived internal tokens toward the backend - FAPI 2.0 profile with PAR + RAR for open-finance consent flows - IP allow / deny lists, allowed hours, and message size limits — same gates, same console ### Tool-level authorization — deny by default Authorization happens per tool, not per server. An agent's tools/list shows only what that identity may call; the same predicate rejects the call itself, so nothing leaks through discovery. Quotas and argument validation cap what even an authorized agent can do. - Per-tool OAuth2 scopes — unsatisfiable tools are hidden from tools/list and rejected on tools/call - Identity ACLs by credential, role, or organization — deny wins, default-deny once any rule exists - Argument constraints per tool: regex, max length, enum — validated before dispatch - Call quotas per tool or per credential, per minute / hour / day — denied calls never consume quota - Rate limiting, throttling, and message size limits inherited from the gateway pipeline ### Data protection on every response Tool responses are filtered before an agent sees them. Built-in PII masking and regex deny-patterns run on every tools/call in both routing modes, and the AI guardrail policies that protect your LLM traffic also attach to the MCP lane. The classic agent attack paths — confused deputy, metadata endpoints — are closed by default. - Built-in PII masking — national ID, IBAN, phone, email, credit card — on every tool response - Regex deny-patterns: one match blocks the whole response, never a partial leak - AI guardrails on the MCP lane — Prompt Guard, Topic Guard, DLP Guard, PII Mask, Loop Guard - Token passthrough is off by default; enabling it requires an explicit audience allow-list - Egress guard blocks cloud metadata, loopback, and link-local targets; private-network egress is an admin-only opt-in ### Health, drift, and Shadow MCP — the questions managers ask Is every MCP server up? Did any of them silently change their tools? Is anything in the estate reaching an MCP server we never cataloged? The gateway answers all three continuously — with probes, pinned catalog hashes, and a governance report built for exactly this audit. - Health probes on every MCP connection every five minutes — status, message, and history retained - Catalog drift detection: tool catalog hash pinned at approval, evaluated on every tools/call - Alert trigger on drifted connections — routed to Slack, Teams, email, or webhook - Shadow MCP report — runtime targets that are unregistered or unconstrained by an allow-list - Redeploy-pending banners in the console — configuration changes never silently apply ### Same platform, same audit, same operators MCP is a first-class proxy type, not a side-car — so agent traffic lands in the same logs, traces, and dashboards as your REST estate, and moves through the same lifecycle. One console, one audit trail, one pager rotation. - Tool name and JSON-RPC id on every traffic record — searchable next to REST traffic - MCP Details panel on the traffic screen; per-tool-call execution traces in Live Trace - MCP bucket on the system dashboard; saved queries filter by API type - Projects, environments, deploy / undeploy, and export / import with dependency resolution - APIops promotion across environments — MCP gateways move like any other API asset - Console RBAC — API Management or AI Development authority governs who touches the agent lane --- ## Use cases ### A customer's agent, through the bank's gates A fintech agent asks for a customer's accounts. The MCP Gateway asks the agent-plane question — may this agent, for this customer, call this tool? — while the API Gateway keeps asking the question it always has. Two gates, two answers, one platform, and the customer's consent carried explicitly at every hop. - OAuth 2.1 + PKCE with the consent captured as PAR + RAR authorization detail - DPoP-bound tokens — stolen tokens are useless from another client - Agent tokens terminate at the gateway; token exchange carries customer and consent context inside - Existing open-banking API policies and compliance remain untouched - Audit per call: which agent, on whose behalf, which tool, under which consent ### Enterprise copilots on the APIs you already run The fastest way to give an internal assistant real capability is the API catalog you already govern. Convert the proxies your teams run into MCP tools, scope tool visibility by role, and let the copilot work — inside the same quotas, masking, and audit as every other client. - One-click conversion from the existing catalog — no new microservice, no new repo - Role-scoped tools/list — each department's copilot sees only its own tools - Call quotas keep an over-eager assistant from exhausting a backend - PII masking on responses before the model ever sees them - Full traffic log per tool call for the security review ### SaaS MCP servers behind one governed endpoint Teams will adopt external MCP servers with or without a policy — the difference is whether you can see it. Passthrough mode puts every third-party server behind your gate: one endpoint, your credentials, allow-listed tools, health probes, and an alarm if the upstream catalog silently changes. - One aggregated endpoint over many upstream MCP servers - Tool allow-lists — new upstream tools stay unusable until approved - Catalog drift alerts when an upstream changes its tools - Five-minute health probes with history - Shadow MCP report surfaces the servers nobody registered ### Close the agent loop at the gateway, not in app code When your LLM traffic already flows through the AI Gateway, MCP tool execution can happen inline: the gateway intercepts the model's tool call, executes it against an allow-listed MCP server, and feeds the result back into the conversation — with the same governance objects as the MCP Gateway itself. - MCP Call (LLM) policy — intercept, execute, and return tool results inside the chat flow - MCP Call (Fixed) policy — invoke a fixed tool on the request or error lane - Fail-closed tool allow-lists and per-call timeouts - Identity ACLs, call quotas, and argument constraints — the same objects, reused - Parallel tool calls traced per call in Live Trace ### Developers onboard through an AI assistant The API Portal itself speaks MCP. A developer's assistant can search the catalog, read specs and auth requirements, create an application, obtain credentials, register APIs, and pull traffic stats — every step authenticated per portal account and scoped to that portal. - Portal MCP server with 20+ tools — search, specs, plans, auth info, test - Application lifecycle from the assistant — create, register, credential, delete - Analytics tools — stats, traffic, response times — per portal account - Portal-scoped isolation; enabled per portal with one setting - Humans keep the UI; agents get the same catalog over MCP --- ## What ships in the box ### Protocol & discovery - Streamable HTTP transport (2025-06-18 revision, default) - Legacy HTTP+SSE transport (2024-11-05 revision) - Stateless core revision (2026-07-28) - Client-proposed, server-negotiated protocol version - Discovery document at .well-known/mcp/server.json - initialize · ping · tools/list · tools/call over JSON-RPC - Generated client snippets — Claude Code, Cursor, Claude Desktop ### Security & authorization - Full gateway policy chain before any tool call — OAuth2 / OIDC, JWT, API key, Basic, Digest, mTLS - LDAP / Active Directory role-based access on the agent lane - Per-tool OAuth2 scopes — filtered discovery, rejected calls, one predicate - Identity ACLs by credential, role, or organization — default-deny - Argument constraints: regex, max length, enum - Call quotas per tool / per credential, per minute / hour / day - OAuth 2.1 · DPoP · audience-bound tokens · token exchange (RFC 8693) - FAPI 2.0 with PAR + RAR for open-finance consent ### Data protection - Built-in PII masking — national ID, IBAN, phone, email, credit card - Regex deny-patterns on tool responses — fail-closed - AI guardrails on MCP traffic — Prompt, Topic, DLP, PII, Loop - Token passthrough off by default — explicit audience allow-list to enable - Egress guard — cloud metadata, loopback, link-local always blocked - Secrets encrypted at rest, never returned by any API ### Operations & governance - Health probes every five minutes with persisted history - Catalog drift detection with pinned hashes and alert triggers - Shadow MCP governance report — unregistered runtime targets - Tool name and JSON-RPC id in every traffic record - Per-tool-call execution traces and MCP dashboards - Export / import with dependency resolution; APIops / GitOps promotion - Three-tier console RBAC — System / Project / Team --- ## Resources - [The bank walkthrough](https://apinizer.com/resources/presentations/apinizer-mcp-gateway-use-case.html) — An interactive walkthrough (in Turkish) of a real use case: which gates an agent's request passes through at a bank — OAuth 2.1, DPoP, FAPI 2.0, token exchange, step by step. - [MCP Gateway docs](https://apinizer.com/developers/docs) — Configure routing modes, expose tools, set per-tool authorization, and onboard agent clients. - [MCP customer briefing](https://apinizer.com/resources/presentations/apinizer-mcp-presentation.html) — A share-ready deck on Apinizer's MCP support — how existing APIs become governed MCP tools for AI agents and assistants. - [AI Gateway](https://apinizer.com/products/ai-gateway) — The sibling plane — LLM routing, token budgets, prompt firewalls, and AI observability on the same runtime. - [MCP server governance](https://apinizer.com/solutions/mcp-server-governance) — The solution view — how platform teams govern MCP estates: registration, allow-lists, drift, and audit. - [Test with Testnizer](https://www.testnizer.com/) — Apinizer's free offline API client speaks MCP — point it at your gateway and exercise tools/list and tools/call before any agent does. - [APIops](https://apinizer.com/developers/apiops) — Create and promote MCP gateways from CI/CD — manifests, deploys, and environment promotion as code. --- ## Next step *Open the agent lane* **Put every MCP call behind gates you already trust.** A 30-minute walkthrough of the Apinizer MCP Gateway — one-click tool exposure, passthrough governance, tool-level authorization, PII masking, drift detection, and full audit — on a Kubernetes of your choice. [Book a Demo](https://calendly.com/apinizer/15min) · [Read the docs](https://apinizer.com/developers/docs) --- ## Links - Products: https://apinizer.com/products - AI Gateway: https://apinizer.com/products/ai-gateway - Solutions: https://apinizer.com/solutions - Pricing: https://apinizer.com/pricing - Developers: https://apinizer.com/developers - Documentation: https://docs.apinizer.com/index-en - Blog: https://apinizer.com/blog - Contact: https://apinizer.com/company/contact © 2026 Apinizer. All rights reserved.