An agent that can delete a production resource is not a clever chatbot problem. It’s an API gateway problem. MCP-native API gateways put Model Context Protocol controls beside the REST endpoints that already carry your business logic.
That distinction matters. Model Context Protocol (MCP) is emerging as a standard way for assistants and agents to discover and invoke tools, prompts, and resources from back-end services. At the wire level, it uses JSON-RPC conventions, but the operational change is larger: an API operation once called only by a deliberately coded client can now be selected dynamically by an agent.
Don’t start by rebuilding REST services as bespoke agent integrations. Google Cloud API Gateway, Tyk, Docker MCP Gateway, and Zuplo MCP Gateway suggest a more durable design: retain OpenAPI as the contract, project selected operations into MCP tools at a controlled boundary, and treat tool metadata as a security-sensitive product surface.
MCP-native API gateways change the API boundary
A REST API and an MCP server do different jobs. REST expresses resources, HTTP methods, status codes, and transport-oriented parameters. MCP exposes a catalog of named tools and lets an MCP client invoke one with structured arguments. The gateway is the adapter: it receives tools/call, validates an MCP-shaped payload, maps arguments to a REST operation, calls the upstream, then returns a tool result.
Think of the request path as four planes. An agent runs on the left. It connects over Streamable HTTP or another supported MCP transport to an MCP endpoint. The gateway in the middle authenticates the caller, selects a tool definition, applies policy, and transforms the call into HTTP. Existing REST services remain on the right, unchanged. Along the bottom, an audit plane collects tool discovery, authorization decisions, upstream latency, request identity, and result status.
This is why MCP configuration belongs with platform engineering, not just AI application teams. It hits the same controls as any exposed API: identity, tenancy, rate limits, schema validation, egress, secrets, and incident response. Prompt quality affects whether a tool is chosen. Gateway policy decides whether the tool can cause damage.
OpenAPI is the canonical source, not an incidental export
Google and Tyk both use OpenAPI as the basis for MCP integration. That is the right default. A disciplined specification already contains operation identifiers, descriptions, parameters, request schemas, response shapes, and security declarations. Those fields are the raw material for a safe tool catalog. Weak descriptions and ambiguous schemas don’t become safer when an agent reads them; they become easier to misuse at speed.
Tool design shouldn’t mirror every REST operation automatically. Read-only lookup tools are low-friction candidates. State-changing operations need stronger descriptions, narrower schemas, explicit tenant identifiers, idempotency requirements, and often a separate confirmation workflow. I’d rather publish six precise tools than expose a hundred CRUD operations because a generator made it easy.
Google Cloud API Gateway MCP server mode, in practice
Google Cloud API Gateway’s September 11, 2026 release notes introduced public-preview support for configuring API Gateway as a remote MCP server. The key engineering property is straightforward: the gateway can expose existing REST operations as MCP tools without modifying the back-end service. Configuration lives in an OpenAPI 3.x document through x-google-api-management and x-google-mcp-tool.
At document scope, x-google-api-management: mcp: true exposes eligible GET, POST, PUT, PATCH, and DELETE operations. Their operationId and description provide the default tool identity and metadata. Per-operation configuration is the escape hatch: rename the tool, add agent-specific instructions, or set x-google-mcp-tool: false to keep an operation out of the catalog.
openapi: 3.0.0
x-google-api-management:
mcp: true
paths:
/v1/{name=publishers/*/shelves/*}:
delete:
operationId: deleteShelf
description: Deletes a Bookstore shelf.
x-google-mcp-tool:
name: delete_shelf
description: Delete one empty Bookstore shelf only after confirming its name and intended scope. Do not use for bulk cleanup.
parameters:
- name: name
in: path
required: true
schema:
type: string
responses:
'200':
description: Shelf deletedThe Bookstore-style example makes the point. A REST operation called deleteShelf becomes a tool called delete_shelf. The tailored description isn’t decoration. It is an instruction boundary visible to the agent before invocation. It can’t replace authorization, but it reduces accidental ambiguity and gives reviewers an obvious place to inspect intended use.
The handshake and the overlooked discovery endpoint
Google exposes an /mcp endpoint for MCP JSON-RPC. A client first sends initialize with its protocol version and capabilities. The gateway responds with HTTP 202 Accepted; the client then sends notifications/initialized. Only then should it enumerate tools with tools/list or invoke one with tools/call.
{"jsonrpc":"2.0","id":7,"method":"tools/call","params":{"name":"delete_shelf","arguments":{"name":"publishers/acme/shelves/archive"}}}tools/list is the subtle risk. It is unauthenticated by default, while Google explicitly recommends JWT-based protection through x-google-api-management/mcp/tools-list/security; API keys are not supported for this enumeration endpoint. Tool listing reveals capability names, descriptions, and often parameter semantics. Treat it as an authenticated API inventory, not a harmless health check.
A practical policy is simple: JWTs for discovery, JWT or workload identity for invocation, separate audiences for human-operated clients and service agents, and logs for denied and successful enumeration. A tenant must never discover a cross-tenant administration tool merely because it cannot call it. Hiding it behind an authorization failure is the wrong default.
Tyk API-to-MCP and the separate server pattern
Tyk Gateway took a related but structurally different route. Its September 1, 2026 release notes added the ability to turn an existing Tyk OAS API into a functional MCP proxy. Tyk’s api-to-mcp tooling ingests an OpenAPI specification, can apply overlays, converts operations into MCP tools, and runs an MCP server that clients can connect to.
MCP governance starts with curated discovery and carefully bounded tool access.
Google makes the API gateway itself the remote MCP server. Tyk’s reference setup commonly runs api-to-mcp as a separate process. This is useful during development: connect Claude Desktop, Cursor, or Vercel AI SDK to a controlled local server, validate tool descriptions and schemas, then graduate the API through Tyk policies. Node.js v18+ is a stated runtime requirement.
{
"mcpServers": {
"api-tools": {
"command": "npx",
"args": [
"@tyk-technologies/api-to-mcp@latest",
"--spec",
"https://petstore3.swagger.io/api/v3/openapi.json"
]
}
}
}This pattern separates conversion from perimeter enforcement. The specification remains the source of truth; overlays can remove or refine operations; the MCP process performs protocol translation; Tyk manages API policy, sessions, and runtime support. An assistant can receive a request such as “List all pets” or “Create a new user,” select a generated tool, and obtain a formatted REST response without anyone hand-writing an integration for each endpoint.
Automatic conversion is useful for breadth, not permission. Filter operations before publication and set required headers in the AI access configuration. Keep destructive endpoints, raw export endpoints, and operations returning sensitive fields out of the first catalog. The first successful demo is usually too permissive. Fix it before it becomes a dependency.
MCP gateways as isolation and governance layers
Once a team has more than one MCP server, direct client-to-server wiring becomes operational debt. Docker MCP Gateway addresses this by acting as a centralized proxy: applications target one gateway endpoint while the gateway handles routing, authentication, configured profiles, and server lifecycle. With MCP Toolkit enabled, Docker Desktop runs it in the background. Docker Engine users install the docker mcp CLI plugin in ~/.docker/cli-plugins, or the Windows equivalent, and mark it executable.
Docker’s useful contribution is blast-radius control. Each MCP server runs in an isolated container with restricted privileges, constrained network access, and controlled resource use. Built-in logging and call tracing capture agent tool activity. Put a read-only inventory server in one container profile, a change-management server behind stricter network rules in another, and don’t grant either unrestricted access to the other’s credentials.
Zuplo MCP Gateway focuses more directly on governance. Its public beta launched June 2, 2026 and is now generally available. Zuplo provides a spec-compliant gateway URL for each upstream MCP server while centralizing OAuth, credential brokering, tool curation, and observability. That means those controls don’t need to be rebuilt in every standalone server.
Its credential models are practical: per-user OAuth with token brokering and refresh per session; a shared OAuth grant with per-user attribution in audit logs; per-user API keys in an encrypted vault on the roadmap; and shared API keys rotated once at the gateway. Choose based on upstream capability, not convenience. Shared grants can be a sound middle ground when an upstream cannot support delegated identity, provided each tool call still carries attributable principal context.
Zuplo calls external product exposure “outside-in”: first-party MCP servers, virtual MCP servers, and curated catalogs for customer agents. “Inside-out” means governing internal agents’ access to third-party tools. These are separate threat models. Outside-in needs a stable, product-grade contract and consumer isolation. Inside-out needs credential containment, approval boundaries, and audit trails for services your organization does not control.
Control planes are becoming expected infrastructure
Nordic APIs lists Azure API Management, APIPark, Apache APISix, Kong Konnect, Solo.io Agent Gateway, Moesif, WunderGraph MCP Server, Tyk API Gateway, Gravitee.io Agent Mesh, Zuplo, Lunar.dev’s MCPX, and other gateways supporting MCP. The products differ, but the category is real. Obot frames the gateway as a control plane that solves the N×M credential and policy problem; its MIT-licensed platform combines gateway, catalog, hosting, chat client, composite servers, multi-role RBAC, and IdP integration for Kubernetes, Docker, or managed deployments.
For AI-heavy backends, Bifrost offers another boundary: a Go-based combined LLM and MCP gateway. GetMaxim’s summary reports roughly 11 microseconds of overhead at 5,000 RPS, routing across 20+ LLM providers and aggregating tools behind one /mcp endpoint. Published figures need workload validation, especially when tool calls trigger slow upstreams, but the number makes the architectural question concrete. A unified gateway reduces hops; separate gateways reduce vendor coupling and isolate failure domains.
Security, telemetry, and a migration sequence
MCP adds attack surfaces that ordinary REST telemetry often misses. Tool enumeration or description manipulation can steer prompt-influenced argument selection, while credential delegation makes multi-step side effects harder to trace. Log the MCP method, tool name, authenticated subject, tenant, policy decision, upstream route, normalized arguments with sensitive fields redacted, latency, result class, and correlation ID. Six fields is not enough when an incident spans an agent, gateway, and service.
Alert on unusual sequences, not just error rates: a burst of tools/list, rapid state changes from one agent identity, invocation of rarely used administrative tools, or repeated schema-validation failures after a prompt change. Docker call tracing, Zuplo’s per-call audit logs, Tyk filtering and headers, and Google’s JWT protection for tool listing cover different parts of this chain. Use them together where the architecture requires it.
A measured migration has four moves. First, improve OpenAPI operation IDs, descriptions, schemas, and security definitions. Second, expose read-only tools in a non-production catalog and replay representative agent calls. Third, introduce write tools only with narrow scopes, idempotency keys, explicit authorization, and strong audit events. Fourth, place cross-server access behind Docker, Zuplo, Obot, or a comparable control plane once direct wiring begins to multiply.
Google’s platform direction makes this more than protocol trivia. Forkast News reported the legacy Cloud API Registry API shutdown on July 30, 2026 after April 30, 2026 deprecation, replacing legacy tooling, gcloud CLI commands, and IAM permissions with Agent Registry capabilities including create_service, update_service, search_agents, and list_mcp_servers. MCP-aware discovery is moving into core platform administration.
Build for reversibility, then make one tool useful
MCP gateway products are changing too quickly to make a permanent vendor bet from a single prototype. Keep tool definitions traceable to OpenAPI, store gateway configuration as code, avoid client-specific tool names where possible, and test the JSON-RPC contract independently of a particular assistant. LLM Gateway already demonstrates the SaaS form of this model with Streamable HTTP endpoints at https://llmgateway.io/mcp and https://api.llmgateway.io/mcp, using Authorization: Bearer API keys and public server information over GET.
MCP-native architecture should preserve choice while making every route observable and governable.
The concrete takeaway is less glamorous than “make every API agentic.” Start with one read-only operation whose OpenAPI contract is already excellent. Protect tools/list, trace every invocation, impose a tenant boundary, and prove that an agent can use it without revealing more than the caller should know. It’s fine for a prototype, not for a fleet, if that small tool cannot be governed cleanly. Exposing the rest of the API will only scale the mistake.