Your REST APIs Can Now Talk to AI Agents, No Extra Server Required

Google Cloud API Gateway now speaks MCP (Model Context Protocol), the standard language AI agents use to discover and call tools. That means an API you already have can be made visible to an AI agent by annotating a config file, with no new server to build or host.

For designers who are vibe-coding their first agent-powered app, this closes a gap that previously required real backend engineering to cross.

The Problem It Solves (and Why It Blocked You Before)

MCP has become the default way AI agents find and use tools. Think of it like a universal plug: if your data or functionality speaks MCP, any compatible agent can pick it up and use it. Gemini Enterprise and Google's Agent Development Kit (ADK) both speak it natively.

The catch, until now, was getting your actual data sources into that format. Most useful functionality lives behind REST APIs. A REST API is essentially a web address your app can call to fetch or send data, like checking an order status or pulling a user profile. But agents cannot see REST APIs directly. They need an MCP "wrapper" around them.

Previously, making that wrapper meant standing up a separate MCP server, which means writing code, hosting it somewhere, keeping it secure, and duplicating all the authentication and quota rules your API gateway already enforced. For a solo designer or a small product team, that is a serious roadblock.

What Google Just Shipped

API Gateway, Google Cloud's lightweight tool for securing and managing APIs, can now act as a remote MCP server. You annotate the OpenAPI spec (the structured description file) you already use to describe your API, add a couple of flags, redeploy, and your REST operations show up as callable agent tools on a /mcp endpoint.

The gateway handles the translation automatically. When an agent calls a tool, the gateway converts that MCP request into the normal REST call your backend already understands, runs it through your existing security rules, and sends the response back in MCP format. Your authentication, rate limits, and logging all keep working exactly as before, because MCP and REST traffic share the same policy path.

This is in Public Preview right now, so it is real and usable, but expect some rough edges as it matures.

How a Designer-Builder Could Actually Use This

Say you are building a customer support agent with Gemini. You want it to look up order statuses from your backend. Here is the practical path with this new feature.

Step 1: Check your OpenAPI spec version. This feature requires OpenAPI 3.0.x or 3.1.x. If your API is described with an older 2.0 spec, Google provides a migration path before you can proceed. This is worth checking early.

Step 2: Annotate the spec. You add a single flag at the top of your spec file (x-google-api-management: mcp: true) to opt the whole API in, and then you can label individual operations with x-google-mcp-tool to give each one a name and, crucially, a description. That description is what the AI model reads to decide when to use the tool, so write it as plain instructions: "Use this when the user asks where an order is or when it will arrive." Treat it like writing a prompt, not a technical label.

Step 3: Deploy as normal. No new infrastructure. The gateway generates MCP support automatically and starts serving it on the /mcp path.

Step 4: Connect your agent. In ADK, you point your agent at the /mcp endpoint with the same API key your gateway already uses. The agent gains access to your tools and can start calling them based on user intent.

One security note worth flagging: by default, the tool discovery endpoint (the list of what tools exist) is publicly visible. For anything beyond local testing, you will want to lock that down with a JWT (a secure token, essentially a digital ID card). The official docs walk through exactly how.

What to Watch For

This feature is genuinely useful for product builders, but a few real limits are worth knowing before you plan around it.

Operations that return an empty response (like a simple "done" confirmation with no data) are not supported yet. Very complex, deeply nested data structures may not show up correctly in the tool list. A single gateway can serve up to 1,000 tools, which is plenty for most projects. And you cannot currently combine MCP support and model routing (a feature for managing which AI model handles a request) in the same API config.

Response streaming and richer MCP features like resources and prompts are on the roadmap but not here yet.

The Grounded Takeaway

If you are building an agent-powered product and your data already lives behind a REST API, this removes one of the most frustrating early obstacles. You do not need a backend engineer to write and maintain a separate MCP server. You annotate a file you already have, redeploy, and your agent can see your data.

The descriptions you write for each tool matter as much as the wiring itself. A vague description means the agent will not know when to reach for that tool. A clear, intent-driven description means it will use it at exactly the right moment. That is a design problem, and it is squarely in your wheelhouse.