You own an API. Forty-odd endpoints, an OpenAPI file that is mostly accurate, and a gateway in front of it all. For the last year people have kept asking when it will have an MCP server, and you have kept saying soon, because building one sounds like a second product to run. So when an APIs.io post says Google Cloud API Gateway now turns a REST API into MCP tools with one flag, you stop what you are doing.
The post sums up Google's announcement, written by Sanjay Pujare, Paul Howell and Geir Sjurseth, and the opening line is your situation exactly: most enterprise capability sits behind REST APIs that agents cannot see. The fix is almost suspiciously small. Set mcp: true under the x-google-api-management extension in your OpenAPI document, deploy, and the gateway starts serving MCP on a /mcp base path, with nothing new to run. Each operation becomes a tool. A per-operation extension lets you rename a tool, rewrite its description or hide it.
You like that the post goes straight to the limits, because limits are what you will hit on a Tuesday afternoon. Operations that return an empty body are not exposed. Deeply nested schemas may not show fully in the tool list. One gateway serves up to 1,000 tools. And MCP and model routing cannot be turned on in the same API config, so if you wanted both, you are running two gateways. There are no adoption numbers, the post notes, only those limits.
The line that would sell it to your security team is this one: MCP and REST traffic share exactly one policy path, and an operation draws on one quota however it is called. Same rules, same rate limits, whether a person's app or an agent makes the call. You mentally cross one meeting off next quarter's calendar.
Then the warning, which you are glad someone put in writing. By default the tools/list call is unauthenticated. That is handy while developing and it also publishes your tool names and input schemas to anyone who asks. You make a note before you have even tried the flag.
The writing advice is the part you keep rereading. A tool's description is the main signal a model uses to decide when to call it, so write when and why to use it, not just what it returns. You open your OpenAPI file. Most of your descriptions say what an endpoint returns. Almost none say when you would want it. The flag will take seconds. Fixing the descriptions will take a week, and it is the week that matters.
Then the post turns the flag around on Google. The catalog lists one API for the gateway itself, its management API, where the config carrying that extension gets created and deployed. An agent can use 11 operations there, 6 of which change something. The MCP server dimension on that record is unlit. As far as the catalog can find, the product that makes any REST API an MCP server with one flag has not flipped the flag on its own API. Its Kin Score is 50.0, developing, with contract governance at 9.8 and Agent Readiness at 19.8. The contract still has no examples and no described errors, the very things the announcement tells you to write.
You do not take that as a reason to skip the feature. You take it as a reminder that the flag is the easy part for everyone, Google included. The descriptions, the examples, the errors an agent can understand: that is the work, and no gateway does it for you.
So your plan for the week changes. Rewrite the descriptions first, saying when and why. Add examples to the operations agents are most likely to call. Lock down tools/list. Then flip the flag. And if someone asks whether you are ready for agents, the answer will no longer depend on whether you have a server, but on whether your contract tells an agent what it needs to know.
Read the original: https://apis.io/2026/10/06/google-turns-rest-into-mcp-tools-with-one-flag-and-its-own-record-has-no-mcp-server/