MCP Is the New REST. Google Cloud Just Made It Enterprise-Ready.

MCP adoption moved faster than anyone expected. What started as an Anthropic open standard is now the de facto protocol for agent-to-tool communication. OpenAI, Google, Microsoft, and most major frameworks have adopted it. The question is shifted from “should we support MCP” to “how do we run it at enterprise scale.”

Google Cloud launched managed remote MCP servers in December 2025. Apigee handles the governance layer.

The Tool Problem for AI Agents

An AI agent that can only reason without acting is not very useful in enterprise applications. To do anything meaningful, an agent needs to call external systems. That means looking up customer records, triggering workflows, querying databases, and sending notifications. These are tool calls. The agent needs to know what tools exist, what each one does, what parameters it takes, and what it returns.

Before MCP, every agent framework handled this differently. OpenAI had its function-calling format. Anthropic had tool use. LangChain had its own abstraction. Developers had to write integration code for each framework separately, and when they switched models, they rewrote it.

MCP standardizes all of that. An MCP-compatible agent discovers available tools from any MCP server, reads their schemas, and calls them without hardcoding every integration. It’s the same standardization moment REST was for web APIs two decades ago, and it’s happening fast.

What Google Cloud Actually Built

The managed MCP server offering does something concrete. It takes existing REST APIs and surfaces them as MCP tools without requiring any API changes. Apigee handles the REST-to-MCP transcoding automatically. You configure an Apigee MCP proxy and point it at your existing APIs. They become tools that any MCP-compatible agent can discover and call.

The governance layer is what makes this enterprise-ready. Every MCP tool call routes through Apigee. It applies the same policies as any other API: OAuth 2.0 authorization, rate limiting, token quotas, and full audit logging. An agent can’t call a tool it’s not authorized to call. A runaway agent hitting the same tool call repeatedly will hit rate limits and stop. Every call logs to Cloud Logging, and compliance documentation generates automatically.

On top of that, Apigee API Hub registers all MCP proxies as a searchable tool catalog. Agents discover available tools at runtime rather than from a fixed hardcoded list. As the catalog grows, dynamic discovery scales in ways that static configuration simply can’t.

Why the Open Standard Part Matters

Building on MCP rather than a proprietary format gives you portability. AWS Bedrock uses its own tool-use format. Integrations built for Bedrock don’t work with Claude, Gemini, or open-source agents without a rewrite. By contrast, MCP integrations built on Google Cloud work across any MCP-compatible agent: Claude, Gemini, GPT-4, LangChain, AutoGen, and whatever comes next.

For ISVs integrating with customers’ AI workflows, that matters. A customer running Anthropic agents and a customer running Google agents can both call the same MCP tools. They route through the same Apigee-governed endpoint. The ISV writes the integration once.

That said, MCP doesn’t solve everything. It handles how agents talk to tools, not how agents talk to each other. Discovering what other agents exist, what they can do, and how to delegate tasks between them’s a separate problem, one that A2A’s designed to address. The two protocols are complementary, and serious agentic architectures will need both.

The Practical Implication

If you have an existing REST API catalog and you’re thinking about agentic features, the path’s shorter than it was. Your existing APIs become the tool library that agents call. Enterprise governance sits at the infrastructure layer. No new servers to build. The question is no longer “how do we build MCP tooling.” It’s “which of our existing APIs do we want agents to use, and at what access tiers.”

The ISV Opportunity

For ISVs, the governed MCP catalog is worth thinking about as a product surface. If your APIs are in Apigee and accessible as MCP tools, customers building agentic workflows can discover and call your product without a custom integration. You become part of their tool catalog automatically. That changes the sales motion for API-first products. Instead of convincing a developer to build an integration, you’re already in the catalog they’re browsing.

It also changes the support conversation. Because every call routes through Apigee, you have full visibility into how agents are using your APIs. Volume spikes, unusual call patterns, and authorization failures all surface in the same audit logs you already maintain. Debugging an agentic integration is no harder than debugging a human-built one.

A few things worth considering: Are your customers already asking whether their AI agents can call into your product? If MCP becomes the default integration protocol for enterprise agentic AI, what’s your API catalog look like as a competitive asset? And if a competitor surfaces their APIs as governed MCP tools before you do, how does that change the conversation?

Want to go deeper?