MCP Gateway — agent access plane

NEW

Open your APIs to AI agents. Without opening your perimeter.

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.

See it on a real use case Request a demo

ModesTool Expose · Passthrough
TransportsStreamable HTTP · HTTP+SSE
MCP spec2024-11 · 2025-06 · 2026-07

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

Sources: REST · SOAP proxies
Schemas: auto from OpenAPI · WSDL
Preview: tool name · method · path · schema
Rollout: created undeployed · review first
Automation: APIops endpoint for CI/CD

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

Upstream authBearer · OAuth2 CC · mTLS
Aggregationmany servers, one catalog
Allow-listper environment, ${env} aware
Discoverytools/list → pinned catalog

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

json

// .mcp.json — generated by the console{  "mcpServers": {    "apinizer": {      "type": "http",      "url": "https://mcp.acme.com/mcp",      "headers": { "Authorization": "Bearer <token>" }    }  }}

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

Agent side: OAuth 2.1 + PKCE · DPoP
Token: audience-bound · short-lived
Inside: token exchange (RFC 8693) · mTLS
Directory: LDAP · Active Directory · SAML
Finance: FAPI 2.0 · PAR + RAR

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

Visibility: tools/list filtered per identity
ACL: credential · role · organization
Arguments: regex · max-length · enum
Quota: per tool · per credential
Default: deny

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

Maskingnational ID · IBAN · phone · email · card
Deny patternsregex — fail-closed, no partial leak
Guardrailsprompt · topic · DLP · loop
Deputy guardpassthrough opt-in + audience list
Egress guardmetadata · loopback · link-local blocked

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

Probe: every 5 min · guarded tools/list
Drift: SHA-256 pinned catalog
Alerts: catalog drift trigger
Report: unregistered MCP targets
History: retention-managed

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

Log fields: tool name · JSON-RPC id · call count
Tracing: per tool call, argument sizes
Dashboard: MCP bucket · type filters
Lifecycle: export / import · APIops
RBAC: System / Project / Team

Use cases

Where teams put it to work.

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

In the box

What's included

The capabilities below are part of the standard install — no add-on SKUs and no separate licenses.

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

Keep going

The bank walkthrough

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.

Open the walkthrough

MCP Gateway docs

Configure routing modes, expose tools, set per-tool authorization, and onboard agent clients.

Read the docs

MCP customer briefing

A share-ready deck on Apinizer's MCP support — how existing APIs become governed MCP tools for AI agents and assistants.

Open the deck

AI Gateway

The sibling plane — LLM routing, token budgets, prompt firewalls, and AI observability on the same runtime.

See the product

MCP server governance

The solution view — how platform teams govern MCP estates: registration, allow-lists, drift, and audit.

See the solution

Test with Testnizer

Apinizer's free offline API client speaks MCP — point it at your gateway and exercise tools/list and tools/call before any agent does.

Get Testnizer

APIops

Create and promote MCP gateways from CI/CD — manifests, deploys, and environment promotion as code.

See the workflow

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.

Request a demo Read the docs