The expensive part of wiring AI agents to your backend is the glue. You end up writing a thin wrapper service whose only job is to translate your existing REST API into something an LLM can call. That wrapper needs to be deployed, versioned, secured, and maintained. It's a tax on every API you want an agent to touch, and Google Cloud API Gateway just made it optional.
The short version: you add an x-google-api-management.mcp annotation to your existing OpenAPI 3.x spec, and API Gateway starts acting as a native remote MCP server. There's no custom middleware and nothing extra to deploy. The API you already have becomes a tool an agent can call directly, and a per-operation x-google-mcp-tool extension lets you tune or exclude individual endpoints. It's in Preview for now.
That's the announcement. What I care about more is where the sharp edges are when you point it at real enterprise APIs that were never designed with agent callers in mind.
Why the "Just Annotate Your Spec" Promise Is Mostly True
OpenAPI specs are already machine-readable contracts. They describe endpoints, parameters, request shapes, and response schemas in a format close enough to what an MCP tool definition needs that the gap between the two is mostly annotation overhead. People have been generating tool definitions from OpenAPI specs for a while. The new part is that the gateway does the translation, so you don't have to hand-roll it.
When I built AgentReview, a multi-agent PR review system whose agents reach Roslyn and Semgrep through an MCP server I wrote in C#/.NET, defining what each tool does was the quick part. The slow part was serving those definitions reliably and getting each tool's input/output contract tight enough that the model doesn't hallucinate parameters. For HTTP APIs, API Gateway now takes a meaningful chunk of that off your plate, along with the auth layer a network-facing tool server needs.
The annotation approach also keeps your API docs and your agent tool definitions in sync by construction. In a long-lived enterprise codebase, whatever is maintained in two places is what drifts first. If your OpenAPI spec is the source of truth and the MCP surface is derived from it automatically, you've eliminated a whole class of "the agent is calling an endpoint that changed three months ago" bugs.
Your API Has to Be Agent-Legible
This is where I'd pump the brakes before annotating your whole API surface. Most enterprise REST APIs were designed for human-driven clients: React frontends, mobile apps, backend services written by engineers who read the docs. Those callers tolerate ambiguity. The engineer knows that POST /claims/process only works after you've called GET /claims/{id} and read the response to see which process codes are valid. A human developer figures that out from the docs. An LLM calling your tool won't.
I've spent seven-plus years building high-volume enterprise data applications in C#/.NET and SQL Server, and plenty of the APIs I've worked with have implicit ordering requirements, shared mutable state, or parameters whose validity depends on context. Those are much harder to expose safely to an autonomous caller than they look on paper. The tool call succeeds, the downstream effect is wrong, and the agent has no idea.
Before you annotate an endpoint, ask three questions:
- Is this endpoint safe to call without side-effect guardrails? If it writes data, what's the blast radius of a bad call?
- Are the parameter names and descriptions self-explanatory to a model with no session context? Rename
proc_cdto something a language model can reason about. - Does this endpoint depend on state established by a prior call? If so, either expose a compound operation or document the dependency in the tool description itself, where the model will see it, instead of in your internal wiki.
The annotation is easy. The API hygiene work that makes the annotation safe is the real project.
Auth, Rate Limits, and the Stuff That Bites You in Production
With API Gateway acting as the MCP server, it also becomes your enforcement layer for everything agents shouldn't be able to do. That's the right place for that logic, but you have to set it up on purpose.
Agents can be chatty. A model reasoning through a multi-step workflow might call the same tool four times to build context before committing to an action. If your API has per-minute rate limits sized for human-driven traffic, an agentic caller will blow through them without trying. Set agent-specific rate limit profiles at the gateway before you go anywhere near production.
Auth scope matters too. If your existing API uses OAuth scopes, make sure the credential your agent holds is scoped to the minimum surface it needs. The MCP tool definition tells the model what it can call. Your auth config at the gateway controls what it's allowed to call. Don't rely on the model's judgment here. Constrain it at the infrastructure level.
One default to know about: tools/list isn't authenticated out of the box, so anyone who can reach the gateway can read your tool catalog. In an enterprise that's usually a problem, and the fix is JWT auth on the gateway, since API keys aren't supported there. tools/call goes through whatever auth the underlying REST operation already has.
If the services behind API Gateway run in a Kubernetes cluster, watch for the kind of bug I've hit with file path handling and directory creation: code that works fine locally on Windows and fails in the Linux container, but only under certain call patterns. Agents are good at finding those, because their call sequences are unpredictable and your integration tests never exercised them.
Start With Your Admin and Utility APIs
If I were rolling this out in a real enterprise system, I wouldn't start by annotating my core business APIs. I'd start with admin tooling and read-heavy utility endpoints like lookup tables, status checks, and configuration reads. The blast radius is lower, agents still get a lot out of them, and you find out where your spec descriptions are too vague before you've handed an agent the keys to anything that matters.
One practical move: before you annotate anything, run your existing OpenAPI spec through an LLM and ask it to describe what each endpoint does based only on the spec. Where the description comes back vague or wrong, your tool description will mislead the agent too. Fix the spec first.
The infrastructure side of this is solid. Custom MCP middleware is exactly the kind of undifferentiated heavy lifting that belongs in the gateway layer. Whether your agent behaves correctly, though, comes down to the API design work you do before you add that annotation, and that part doesn't have a managed service yet.