Dora NodaEvery platform team with a REST API is getting the same request this year: "where's your MCP server?" Agents want to deploy, scale, and tail logs from chat, and the Model Context Protocol is the interface they speak. The instinct is to hand-write an MCP server — a new repo, a new auth story, a new rate limiter, a new set of tool schemas to keep in sync with the API you already ship. Say yes to that instinct and you now maintain two governed interfaces instead of one, with all the drift that implies.
There is a better default: project the API you already have through a gateway and let the MCP surface be generated from it. One tool per API operation, governed by the auth and rate-limit policies that already exist. This post maps exactly what that projection gives you for free, what it can never give you, and where the line falls for the hardest case — a deploy API that agents can call from chat.
The pattern: expose, don't rebuild
The clearest worked example comes from Azure API Management. In May 2025, Microsoft put "Expose REST APIs as MCP servers" into preview: pick an API already onboarded to APIM, select which operations to expose, and APIM serves them as a remote MCP server speaking JSON-RPC over Streamable HTTP. The demo everyone passes around wires a Setlist FM API through APIM so VS Code and Copilot Studio can call it as tools — no hand-written MCP server anywhere in the path.
What makes this a pattern rather than a product demo is where the governance lives. The MCP tools inherit the gateway's existing policy chain: validate-jwt against Microsoft Entra ID for OAuth 2.1 token validation, rate-limit and quota policies per subscription key, and per-client consumption tracking — the same policies that already govern the REST API. Azure API Center then acts as the enterprise registry where those projected MCP servers are discovered. A compact version of the auth half of that policy chain looks like this:
client (MCP host) → APIM MCP endpoint → validate-jwt (Entra ID)
→ rate-limit-by-key → map tools/call → backend REST operationNothing in that chain was written for MCP specifically. That is the whole point: the MCP surface is a projection of an interface you already govern, not a second interface you now govern separately.
What the gateway gives you for free
If your API already sits behind a gateway with an OpenAPI contract, projection hands you four things without new code:
| You need | The gateway already has it | What you skip writing |
|---|---|---|
| Tool schemas for every operation | OpenAPI → one MCP tool per operation, parameters derived from the request schema | Hand-maintained tool definitions that drift from the API |
| Authentication for agent clients | OAuth 2.1 resource-server behavior: token validation, protected-resource metadata (RFC 9728) discovery | A second auth system with its own tokens, scopes, and login flow |
| Rate limiting and quotas | Per-subscription / per-key throttling applied before the backend sees the call | Per-agent throttle code and abuse handling in the MCP layer |
| Per-client consumption and audit | Metering, logging, and subscription analytics inherited from the API | A parallel observability story for "what did the agents call" |
The auth row deserves emphasis because it is where hand-rolled MCP servers go wrong fastest. The MCP authorization spec mandates OAuth 2.1 for remote servers, with RFC 9728 protected-resource metadata so clients can discover the authorization server on their own. As Okta's identity-standards lead Aaron Parecki put it: treat every MCP client as an OAuth client and the MCP server as a resource server that uses an existing authorization server — problem solved. A gateway projecting your API already is that resource server. The common anti-pattern the community keeps documenting — token passthrough, where the MCP layer forwards whatever bearer token the agent presented straight to the backend — exists precisely because teams build a second auth hop instead of reusing the one they have.
It's not just Azure
A pattern that only works on one vendor's gateway is a sales pitch, not a pattern. The projection idea now shows up across the gateway landscape, including self-hosted options:
- Kong Agent Gateway (3.14, April 2026) covers LLM, MCP, and A2A traffic on one runtime and autogenerates MCP tools from existing REST endpoints — the shortest migration path if your services are already APIs behind Kong plugins for auth, rate limiting, and PII redaction.
- Traefik Hub's MCP gateway treats MCP as middleware on the proxy teams already run: it acts as an OAuth 2.1 resource server, exposes the
/.well-known/oauth-protected-resourcediscovery endpoints, and adds task-based access control (TBAC) scoped across tasks, tools, and transactions — parameter-level constraints on what an agent may pass, not just which tools it may call. - APISIX added an
openapiMCP resource type: point it at an OpenAPI 3.x document and the gateway generates one MCP tool per operation, executingtools/callas an HTTP request against the REST base URL with a gateway-held credential (bearer, API key, or mTLS). - Standalone generators (
openapi-to-mcp,openapi-mcp-generator,mcpify) turn any OpenAPI spec into a runnable MCP server with proxied calls, input validation from the spec's schemas, and auth carried in environment configuration — no gateway required. - Framework adapters like
fastapi-mcpcollapse the gap entirely: a FastAPI service doubles as its own MCP server, exposing its REST endpoints as MCP tools over Streamable HTTP with the app's existing auth.
The mechanism differs — gateway-native projection, spec-driven codegen, framework adapter — but the economics are identical in all five: the REST contract remains the single source of truth, and the MCP surface is derived from it. When the API gains an operation, the agents gain a tool. Nothing is maintained twice.
Where gateway policy stops: the deploy-authority gap
Here is the part the demos skip. A gateway can project your API, but it cannot decide what your API means. For read-heavy APIs that distinction barely matters. For a deploy API — where one tool call can push to production — it is everything. Three things stay yours no matter which gateway you pick:
| Still yours | Why the gateway can't do it | Concrete failure mode |
|---|---|---|
| Write-scoping per tool | The gateway sees HTTP methods, not blast radius; only you know POST /deploys is production-mutating while POST /previews is not | An agent with the full projected toolset calls deploy_to_prod unprompted because nothing marked it write-sensitive |
| Human approval for destructive ops | MCP has no built-in approval mechanism — every tools/call executes immediately | A prompt-injected agent chains read tools into a delete with zero confirmation and no record of who approved what |
| Rollback semantics | "Revert to the last good deploy" is deploy-domain logic: build selection, traffic shifting, migration safety | The gateway happily proxies the bad deploy's API calls and has no notion of undoing them |
Each gap has a real shape, not a theoretical one:
- Write-scoping means following the OWASP guidance the community has converged on: grant agents the minimum tools required, split read-only from write tools, and require explicit authorization for sensitive operations. Traefik's transaction-level constraints are a start, but the read/write classification itself is a product decision the gateway cannot make for you.
- Human approval means gating destructive
tools/calls behind MCP elicitation (the spec's human-in-the-loop pause) or an approval proxy that holds the call until a human clicks yes — with an audit trail distinguishing "the human asked for this" from "the agent decided on its own." - Rollback means the deploy authority behind the API implements revert as a first-class operation: build pinning, instant traffic cutover to the previous release, forward-only migration discipline. No policy language can synthesize "undo" for an API that never had it.
Notice the asymmetry: everything in the "free" table is about governing access to operations, and everything in the "still yours" table is about the meaning of operations. Gateways govern access superbly. Meaning is the deploy authority's job, and projecting the API through a gateway doesn't transfer an ounce of it.
The roadmap shape for a deploy API
Put the two tables together and the sequencing for a Render-compatible deploy API's deploy-from-chat roadmap writes itself:
- Project first. Generate the MCP surface from the API operations you already ship — deploys, services, logs, env vars — behind the gateway auth and rate limits you already run. Agents get a complete, governed read path and a scoped write path on day one, and the MCP surface can never drift from the REST contract because it is derived from it.
- Scope writes explicitly. Classify every projected write tool by blast radius before agents touch production: preview deploys and log tails are low-stakes; production deploys, env-var writes, and deletes require elevated handling. Ship read tools broadly and write tools narrowly.
- Gate destruction on humans. Put elicitation-backed approval in front of every irreversible tool call, with an audit trail recording what was approved, by whom, and what the agent did on its own. An agent that can deploy without a human in the loop is a liability, not a feature.
- Build rollback into the authority. Make "revert to last good" a real API operation with the same care as deploy itself — then it projects to MCP as just another governed tool, and the agent that caused the incident can be the one that mitigates it, approval-gated.
The effort you save by not hand-writing an MCP server — no second auth system, no parallel rate limiter, no duplicated tool schemas — funds steps 2 through 4, which are the actual work. Teams that invert the order, building a bespoke MCP server first and bolting on governance later, end up maintaining two interfaces and discovering the deploy-authority gap late, when an agent has already used the ungated path.
Project by default, hand-write by exception
The verdict: if an agent-facing tool maps to an operation your REST API already has, projecting it through a gateway beats hand-writing it on every axis — less code, inherited governance, zero drift. Hand-writing earns its place only where there is no REST equivalent to project: composite workflows ("deploy, smoke-test, then promote"), approval-gated multi-step runbooks, tools whose inputs are conversational rather than schematic. Even those should call the same governed API underneath rather than growing their own backends.
The question was never really "where's your MCP server?" It was "how do agents safely use the API you already have?" — and the safest answer starts with the gateway, not a new repo.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Agents are first-class operators there: the same Render-compatible API that deploys your app today is the surface deploy-from-chat will project tomorrow. Star the repo on GitHub or deploy your first app today.
