Dora NodaThe fastest way to make your API callable by AI agents in 2026 involves writing zero MCP server code. No new SDK, no parallel tool codebase, no second auth system to maintain. You point your API gateway at the REST API you already ship, tick which operations become tools, and hand the agent a URL. In Microsoft's demo, two read operations from a sample API — search for artists, search for setlists — become tools a Copilot agent can call within minutes, with the gateway translating MCP's JSON-RPC into the same HTTP requests your dashboard has always made.
That is the gateway-native REST-to-MCP bridge pattern, and Azure API Management's REST-to-MCP feature is its most fully worked public example: operations in, tools out, with the gateway's existing policies as the security layer. A community demo repo, olivMertens/mcp-azure-apim, walks the whole loop — deploy, expose, call from Copilot and from a Python agent, lock down with policies.
This post is the honest version of that story: how the bridge works mechanically, what you genuinely get for free, and the five concrete places where a bridge stops being enough and you need a purpose-built MCP server instead.
How the bridge works, mechanically
Start with what APIM actually does, because every other bridge implementation is a variation on the same five moves. In the Azure portal you open your API Management instance, go to MCP Servers, and choose "Expose an API as an MCP server." Then:
- Pick a managed API and its operations. Any HTTP-compatible API already imported into APIM qualifies. You select which operations become tools — all of them, or a subset — and you can change that selection later from the Tools blade. This selectivity matters: the demo exposes two harmless search operations, but a real platform API would expose a read like "get order" alongside an authenticated write like "create deployment," each becoming a separately invokable tool.
- Name the server. Display name, resource name, optional description — plus, optionally, associate it with a product, which is how APIM gates access through subscriptions.
- Get a Server URL. The portal hands you an endpoint shaped like
https://<apim-service>.azure-api.net/<api-name>-mcp/mcp. That URL is the MCP server as far as any client is concerned. - Configure the client. In VS Code you run "MCP: Add Server," pick HTTP transport, paste the Server URL, and add your auth header — typically the APIM subscription key — to
.vscode/mcp.json. Claude Code points at the same Server URL through its own MCP client configuration. Agent frameworks skip the editor entirely: the demo repo's Python client calls the same endpoint with theazure-ai-agentslibrary, and Microsoft's docs show Semantic Kernel and Copilot Studio against the same hosted endpoint. One server URL, three client shapes, zero client-side API knowledge beyond the tool list. - Lock it down with policies. This is the step people skip in demos and regret in production. APIM policies apply to every operation exposed as a tool:
rate-limit-by-key(Microsoft's own example caps calls at 5 per 30 seconds per IP), JWT validation, subscription enforcement, and tracing that stamps the calling agent's ID onto each request for audit.
Note what never appears in that list: touching the backend. The REST API behind the gateway has no idea some of its callers are now language models. Agent tool calls land on the same routes, the same auth, and the same rate limits human clients use — which is the entire economic argument for the pattern. You maintain one API surface instead of two.
What the gateway gives you for free
The "same-everything" property deserves a closer look, because it is doing more work than it seems. When agent traffic flows through the gateway rather than a bespoke MCP codebase, you inherit four things that are genuinely expensive to build yourself.
Authentication and authorization without a second system. The bridge reuses whatever the gateway already enforces: subscription keys for simple cases, OAuth 2.0 and JWT validation where it matters. Microsoft's companion pattern — APIM as auth gateway in front of MCP servers, with Entra ID handling authentication and authorization — shows where this graduates to: the gateway holds the token logic so neither the backend nor every agent client has to reinvent it. The most common production failure here is mundane enough to be reassuring: a 401 Unauthorized from the backend almost always means the authorization header wasn't forwarded, fixed with a single set-header policy.
Rate limiting and governance per tool call. Agents are bursty, retry-happy callers — exactly the traffic shape rate limits exist for. Gateway-level limits, IP restrictions, and audit logging apply to tool calls the same way they apply to dashboard clicks. Microsoft Foundry's framing is blunt: the AI gateway is "a single, governed entry point where you can enforce authentication, rate limits, IP restrictions, and audit logging without modifying your MCP servers or agent code." That sentence is the bridge thesis in one line.
A registry for what agents can touch. APIM pairs the bridge with API Center as a centralized registry for MCP servers, so the platform team can see every agent-facing tool surface in one place instead of discovering MCP servers the way teams used to discover shadow APIs. For a platform shipping a Render-compatible REST API, that registry view is the difference between "agents can call our API" as a rumor and as an operated surface.
Proof it is a pattern, not a product. Azure is the worked example, not the only vendor. Google's Apigee has tooling that "MCP-ifies" any REST API from its OpenAPI spec into an MCP server proxy. The self-hosted world has the same idea in open source: FastMCP.from_openapi() turns a spec into tools with one call, and gateways like AnythingMCP translate MCP tool calls into REST, GraphQL, and even SQL requests behind one authenticated endpoint. If your API has a machine-readable spec and a gateway in front of it, you are most of the way there already.
Where the bridge stops being enough
Here is the part the five-click demo doesn't show you. A bridge converts operations into tools, but MCP servers are more than tool lists — and REST APIs are less expressive than agents sometimes need. Five concrete crossover points, each with its symptom and its graduate path:
| # | Crossover | Symptom you've hit it | What a purpose-built server does instead |
|---|---|---|---|
| 1 | Tools only — no resources or prompts | Agents need to browse state (server logs, deployment history) or reuse canned prompts, not just invoke calls. APIM's bridge explicitly supports tools but not MCP resources or prompts. | Native servers expose resources for stateful reads and prompts for reusable interactions alongside tools. |
| 2 | No elicitation — OpenAPI can't ask the user a question | A deploy tool needs a missing parameter confirmed mid-run ("which region?"), and the bridge has nowhere to express "pause and ask." Spec authors have noted that OpenAPI simply doesn't capture elicitation patterns. | Native servers use elicit() to request the missing input conversationally instead of failing the call. |
| 3 | Tools don't map 1:1 to endpoints | You want one "deploy my app" tool that fans out to five API calls with a confirmation step, or a destructive write that needs preview-then-apply. A bridge gives you five tools and no workflow. | Purpose-built tools wrap multi-call workflows with confirmation patterns the raw endpoints never had. |
| 4 | Streaming fragility | Long tool results stall or break. MCP's transport needs true streaming, and anything that buffers the response body — a policy reading context.Response.Body, response-body logging at global scope — can silently break the server. Microsoft documents both as known failure modes. | A native server owns its transport and streams partial results deliberately instead of hoping the gateway doesn't buffer. |
| 5 | Per-agent, fine-grained scopes | "This support agent may read logs but never trigger deploys, and only for its tenant" can't be expressed by a shared subscription key. Per-user capabilities, delegation via token exchange, and per-tool audit trails are gateway engineering projects, not toggles. | Purpose-built servers verify per-agent identity and resolve scopes per tool, parameter, and operation. |
The good news: graduating doesn't mean abandoning the gateway. APIM's other MCP feature — connect and govern an existing MCP server — puts the same policy, auth, and rate-limit layer in front of a purpose-built server you host yourself. Bridge first, then slide the custom server behind the same gateway when one of the five rows bites. The gateway stays; only the tool implementation changes.
The self-hosted reading: bridge first, graduate deliberately
Strip out the Azure brand names and the decision rule travels well. If you operate a platform with a REST API you already ship — Render-compatible or otherwise — the bridge-first playbook is: expose the existing OpenAPI surface as tools at the gateway on day one, reuse the auth and rate limits your human clients already live under, register the tool surface where your team can see it, and graduate individual tools to a purpose-built server behind the same gateway the day a crossover row bites.
You get agent-queryable in an afternoon; you pay for custom MCP engineering only where the bridge provably can't reach.
For a self-hosted PaaS this sequencing matters more than for anyone, because the team is small and the API surface is the product. Every week spent hand-rolling MCP tools for operations the gateway could have bridged is a week not spent on the deploy path itself. Start with the bridge, watch which tools agents actually call, and let real usage — not speculation about what agents might want — pick the tools worth rebuilding natively.
The broader direction is unmistakable: every major gateway is growing an MCP story, registries are absorbing tool surfaces next to API surfaces, and "agent-queryable" is becoming a checkbox on API operations the way "rate-limited" was a decade ago. The platforms that treat agent access as gateway configuration rather than a rewrite project will ship it months earlier. Just keep the crossover table pinned above your desk, so you recognize the day the bridge stops being enough.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with a Render-compatible API that agents can operate. Star the repo on GitHub or deploy your first app today.
