Google Cloud API Gateway MCP architecture showing existing REST APIs exposed as AI agent tools through MCP without rewriting backend services.

Cloud & DevOps

Your REST APIs Are Becoming AI Tools: Why Google Cloud API Gateway’s MCP Support Matters

By / September 22, 2026

For years, enterprise APIs were designed primarily for one purpose:

software talking to software.

A mobile app calls an API.

A web application calls an API.

A backend service calls another backend service.

The pattern is familiar:

Application

↓

API Gateway

↓

REST API

↓

Business System

AI agents are now changing that architecture.

On September 11, 2026, Google Cloud added Model Context Protocol support to API Gateway in Public Preview.

The feature allows API Gateway to act as a remote MCP server and expose existing REST API operations as tools that AI agents can discover and call.

Most importantly, the backend application itself does not necessarily need to be rewritten.

Developers can annotate an existing OpenAPI 3.x definition, deploy it through API Gateway, and allow selected API operations to appear as MCP tools. API Gateway then translates MCP requests into the REST calls the backend already understands.

That may sound like another integration feature.

It represents something much bigger.

The API economy was built around:

applications consuming APIs.

The emerging agent economy needs:

AI agents consuming tools.

And MCP could become the translation layer between those two worlds.

The Short Answer

Google Cloud API Gateway MCP support can turn existing REST operations into tools that AI agents can discover and invoke.

Instead of building a separate MCP server around every existing backend, developers can potentially reuse:

  • existing API endpoints
  • OpenAPI specifications
  • authentication policies
  • gateways
  • logging
  • monitoring
  • backend infrastructure

The architecture becomes:

AI Agent

↓

MCP Client

↓

Google Cloud API Gateway

↓

MCP-to-REST Translation

↓

Existing REST API

↓

Business System

Google’s gateway converts MCP tools/list and tools/call interactions into the API operations already defined in the OpenAPI specification. For tool invocation, Google says the underlying REST operation’s API-key or JWT authentication rules continue to apply.

This could significantly reduce the amount of custom integration code required to make existing enterprise systems usable by agents.

But it also creates a new security question:

Just because an API can become an AI tool, should it?

That may prove to be the more important question.

What Google Actually Announced

Google Cloud released MCP support for API Gateway on September 11, 2026.

The capability is currently Public Preview, which means it is covered by Google’s Pre-GA terms and should not automatically be treated like a mature generally available production capability.

Google describes the purpose simply:

existing REST APIs can be exposed to AI agents as MCP tools without requiring changes to backend services.

The process relies on:

OpenAPI 3.x

plus:

Google API Gateway MCP extensions.

The gateway performs the protocol translation.

Before MCP: Every Agent Integration Was Potentially Custom

Imagine an enterprise has these APIs:

Customer API

GET /customers/{id}

Orders API

GET /orders/{id}

Refund API

POST /refunds

Inventory API

GET /inventory/{sku}

Ticket API

POST /support/tickets

Traditional applications already know how to call these APIs.

Now an organization wants an AI support agent.

Without a standard tool protocol, developers might build custom functions around each endpoint.

For example:

get_customer()

get_order()

issue_refund()

check_inventory()

create_ticket()

Each function needs:

  • parameter mapping
  • authentication
  • error handling
  • descriptions
  • serialization
  • maintenance

Multiply this across hundreds of APIs and dozens of agents.

Integration becomes a major engineering project.

MCP Changes the Integration Boundary

Model Context Protocol introduces a standardized way for agents and AI applications to discover and invoke tools.

Instead of every agent framework inventing its own tool interface, an MCP-compatible client can interact with an MCP server through standardized methods such as:

tools/list

and

tools/call.

Google’s API Gateway can now sit between MCP clients and existing REST backends, translating the agent-facing MCP requests into normal HTTP requests.

Conceptually:

Before

Agent

↓

Custom tool wrapper

↓

Custom integration code

↓

REST API

After

Agent

↓

MCP

↓

API Gateway

↓

REST API

This is why API Gateway’s role is becoming strategically more important.

It is no longer only:

the gateway between applications and APIs.

It can also become:

the gateway between agents and enterprise capabilities.

Digital Stackroom Framework: From API Era to Agent Tool Era

A useful way to understand this transition is through four stages.

Stage 1 — Backend Functions

Software functionality lived inside applications.

Example:

createOrder()

Only the application itself could use it.

Stage 2 — REST APIs

Organizations exposed functionality through APIs.

Example:

POST /orders

Now other applications could use it.

Stage 3 — API Gateways

Organizations centralized:

  • authentication
  • routing
  • quotas
  • policies
  • monitoring

The gateway became the controlled front door to APIs.

Stage 4 — Agent Tools

The same capabilities can be presented to AI agents through standardized tool interfaces.

Example:

create_order

The agent does not need to understand the backend architecture.

It needs:

  • tool name
  • description
  • input schema
  • authorization

The progression becomes:

Function

→

API

→

Managed API

→

Agent Tool

That could be one of the most important infrastructure transitions of the agentic AI era.

Evolution from application functions to REST APIs, managed APIs, and MCP tools that can be used by AI agents.
Digital Stackroom framework showing how software capabilities evolve from internal functions to REST APIs, managed APIs, and MCP tools for AI agents.

How Google Cloud API Gateway MCP Works

Google’s model relies heavily on OpenAPI.

The process can be simplified into five steps.

1. Start With an Existing REST API

The backend can already exist.

For example:

POST /orders

or:

GET /customers/{customerId}

2. Describe It Using OpenAPI 3.x

Google requires a valid OpenAPI 3.x definition.

OpenAPI 2.0 is not supported for the MCP preview.

The specification describes things such as:

  • paths
  • methods
  • parameters
  • request bodies
  • responses
  • authentication
  • operation IDs
  • descriptions

3. Mark Operations as MCP Tools

Developers can enable MCP globally for eligible operations or configure it at the individual operation level using Google’s custom extensions.

Google uses:

x-google-api-management

and:

x-google-mcp-tool

to control the MCP exposure.

That means teams do not necessarily have to expose every REST operation.

They can decide:

This endpoint is appropriate for AI agents.

while leaving another endpoint inaccessible.

That selective exposure is critical.

Tool Names Come From the API Specification

When MCP is enabled globally, Google says the default MCP tool name is derived from the API operation’s operationId.

The tool description comes from the operation’s description or summary unless it is explicitly overridden.

This means API documentation suddenly has a much more important role.

Historically, an API description was mainly for:

developers reading documentation.

In the agent era, the description can influence:

whether an AI agent chooses the tool.

That changes the importance of API metadata dramatically.

API Documentation Is Becoming AI Behavior Configuration

Consider two tool descriptions.

Poor description

delete_customer

Deletes customer.

Better description

delete_customer

Permanently deletes a customer account and associated profile records. Use only after explicit deletion authorization has been confirmed.

Both may call the exact same backend endpoint.

But the second description gives an AI agent far more useful context about:

  • consequence
  • intended use
  • risk

Google currently requires exposed MCP tools to resolve to a non-empty description. Operations without a usable description are rejected.

That tells us something important:

API documentation is becoming part of the agent-control surface.

Tool Descriptions Are No Longer Just Documentation

An AI model uses descriptions to decide which tool is appropriate.

So poorly written tool metadata could cause agents to:

  • choose the wrong operation
  • misunderstand consequences
  • send incorrect parameters
  • perform overly broad actions

In traditional API development:

bad documentation frustrates developers.

In agentic systems:

bad documentation can influence autonomous behavior.

That is a much higher-stakes problem.

How MCP Arguments Become REST Requests

Google maps MCP tool arguments back into the underlying API operation based on the OpenAPI definition.

Google documents that:

  • path parameters become tool arguments
  • query parameters become tool arguments
  • headers can become arguments
  • request-body content is nested under a body argument

The resulting backend request looks like a standard REST call to the backend service. Google notes that the backend does not inherently know whether that REST request originated from an MCP tool call or a direct REST call.

This is an important architecture detail.

The backend remains REST-native.

The gateway absorbs the agent protocol.

Why That Matters for Legacy Systems

Large organizations may have thousands of APIs.

Many are years old.

Some serve:

  • finance
  • logistics
  • HR
  • operations
  • customer support
  • inventory
  • payments

Rewriting those systems for AI agents would be extremely expensive.

Gateway-based MCP support creates another option:

keep the backend

adapt the interface at the gateway.

That could accelerate enterprise agent adoption significantly.

REST APIs Are Becoming the Agent Tool Catalog

Imagine an enterprise with:

2,000 managed API operations.

Historically those represented:

application capabilities.

In an agentic architecture, a carefully selected subset could become:

agent capabilities.

Examples:

REST operation:

GET /inventory/{sku}

becomes:

check_inventory

REST operation:

POST /ticket

becomes:

create_support_ticket

REST operation:

GET /customer/{id}

becomes:

get_customer_profile

REST operation:

POST /shipment/reschedule

becomes:

reschedule_delivery

Suddenly the API catalog starts looking like an enterprise tool catalog for AI agents.

The API Gateway Becomes the Agent Control Plane

API gateways already solve problems such as:

  • routing
  • authentication
  • quotas
  • rate limiting
  • logging
  • traffic policies

Agents need almost exactly the same controls.

But they need them at greater scale and with greater context.

That means existing API-management infrastructure is well positioned to become part of the AI agent control plane.

The architecture could look like:

AI Agents

↓

Agent Gateway / API Gateway

Controls:

  • tool discovery
  • authentication
  • authorization
  • quotas
  • rate limits
  • audit logs

↓

Enterprise APIs

↓

Business Systems

This is much more manageable than allowing every agent to connect directly to every internal system.

Tool Discovery Creates a New Security Surface

MCP clients commonly discover capabilities using:

tools/list

This may expose information about available tools.

Google’s current Public Preview behavior is important here.

Google says tools/list is unauthenticated by default, although it strongly recommends protecting tool discovery with authentication.

If authentication is enabled for tools/list, the preview requires a JWT security scheme; API-key authentication is not supported for that method.

That means teams should not simply enable MCP globally and assume tool discovery is automatically private.

Security configuration matters.

Do Not Expose Every API Operation

Google allows MCP to be enabled globally for eligible operations.

That is convenient.

It may not always be wise.

Imagine an internal administrative API contains:

  • get_customer
  • update_customer
  • refund_payment
  • delete_customer
  • reset_account
  • disable_user

An agent may only need:

  • get_customer
  • update_customer

Globally exposing all eligible operations could unnecessarily increase the tool surface.

A safer principle is:

Expose the minimum set of operations an agent genuinely needs.

This is the API equivalent of least privilege.

Agent Tool Least Privilege

Blog #8 discussed least privilege for AI agent identities.

MCP introduces another layer:

tool least privilege.

An agent may have valid identity credentials.

But it should still not automatically see or call every available tool.

So agent security becomes:

Who are you?

Which tools can you discover?

Which tools can you call?

Which resources can those tools access?

That is a much more complete security model.

Authentication Still Matters at the Underlying API

For actual tools/call operations, Google says API Gateway reuses the security rules defined for the corresponding REST operation.

That can include API key or JWT-based authentication depending on the API configuration.

This is useful because enterprises do not necessarily have to invent an entirely new authentication stack for agent tools.

Their existing API security can remain relevant.

But authentication alone is not enough.

Authentication Is Not Authorization

Suppose an AI agent successfully authenticates.

Should it be allowed to call:

refund_customer($10)

and:

refund_customer($10,000)?

Those may use the same API endpoint.

Yet their risk is very different.

This suggests agentic APIs need richer policies around:

  • amount
  • resource
  • user
  • environment
  • business context
  • task

The future API gateway may increasingly combine:

authentication

with:

contextual authorization.

Human Approval Still Matters

Consider this request:

“Resolve this customer’s billing issue.”

The agent may determine:

Issue a $1,200 refund.

Should the call execute automatically?

Maybe not.

A safer architecture:

Agent requests refund

↓

Gateway/policy engine checks value

↓

Amount exceeds threshold

↓

Human approval required

↓

Approved

↓

REST API executes

MCP makes tool execution easier.

It does not remove the need for business controls.

The New MCP Specification Makes Gateways More Relevant

The MCP project released specification version 2026-07-28 in July.

One of its biggest changes was a move to a stateless protocol core.

The specification also added header-based routing information such as Mcp-Method and Mcp-Name, allowing ordinary infrastructure like gateways, load balancers and rate limiters to understand MCP traffic without deep inspection of every request body.

This matters because earlier agent protocols often required more specialized state management.

The newer architecture looks much more like ordinary web infrastructure.

Conceptually:

MCP is becoming easier to operate like HTTP infrastructure.

That makes API gateways a natural place for MCP governance.

Stateless MCP Is Important for Scale

Stateful protocols can require:

  • sticky sessions
  • shared session storage
  • persistent connections

Those complicate horizontal scaling.

The 2026-07-28 MCP specification removed protocol-level sessions so individual requests can be handled independently by different server instances.

That makes architectures such as:

Load Balancer

↓

MCP Server 1

MCP Server 2

MCP Server 3

much easier to operate.

This is one reason MCP is increasingly looking less like an experimental developer protocol and more like enterprise infrastructure.

But Google’s Preview Documentation Shows an Earlier MCP Version

There is an important detail developers should notice.

Google’s current API Gateway MCP configuration examples use protocol version:

2025-11-25

and describe the initialization handshake associated with that version.

The official MCP project has since released the newer 2026-07-28 stateless specification.

Google’s current API Gateway MCP documentation does not explicitly document 2026-07-28 support.

So developers should test protocol compatibility rather than assume that every capability in the latest MCP specification is already available through Google’s Public Preview.

That is especially important for production architecture decisions.

Google Cloud vs AWS vs Azure

The three major cloud platforms are approaching the same problem from slightly different directions.

PlatformMain approachExisting REST API reuseMain gateway layer
Google CloudAPI Gateway itself acts as remote MCP serverYesGoogle API Gateway
AWSREST API becomes target behind AgentCore GatewayYesBedrock AgentCore Gateway
AzureAPI Management exposes REST APIs or existing MCP serversYesAzure API Management

All three approaches point toward the same larger architecture:

existing APIs

↓

managed gateway

↓

MCP

↓

AI agents

How AWS Approaches It

AWS allows API Gateway REST APIs to become targets for Amazon Bedrock AgentCore Gateway.

AgentCore Gateway can expose a single MCP URL and translate incoming MCP tool calls into HTTP requests against the selected API Gateway resources.

AWS says developers can expose:

  • an entire API Gateway stage
  • selected resources

The gateway converts MCP tools/list and tools/call operations into the corresponding API interactions.

Conceptually:

Agent

↓

AgentCore Gateway

↓

API Gateway

↓

REST Backend

AWS therefore places a dedicated agent gateway layer in front of API Gateway.

How Azure Approaches It

Azure API Management supports two major MCP patterns.

Existing REST API → MCP Server

A REST API already managed in API Management can expose selected operations as MCP tools.

Existing MCP Server → Managed Gateway

An externally hosted MCP server can be placed behind API Management for centralized governance.

Azure also supports:

  • authentication
  • authorization policies
  • monitoring
  • rate controls
  • API Center discovery

and can package MCP servers into API Management products for subscription and quota management.

That makes Azure’s strategy strongly oriented toward enterprise governance.

What the Cloud Vendors Agree On

Despite implementation differences, Google, AWS, and Microsoft appear to agree on something important:

Existing APIs should not have to be rebuilt from scratch for the agent era.

Instead, gateways can translate between:

agent protocols

and:

traditional APIs.

That is a strong signal about where enterprise architecture is heading.

OpenAPI Becomes More Valuable

OpenAPI has traditionally been useful for:

  • documentation
  • SDK generation
  • validation
  • API management

MCP adds another use:

agent tool generation.

A high-quality OpenAPI specification can now potentially help determine:

  • tool names
  • tool descriptions
  • arguments
  • authentication
  • agent discoverability

That makes API specifications more strategically important.

Bad OpenAPI Will Produce Bad Agent Tools

Suppose an OpenAPI operation looks like:

operationId: proc1

Description:

Process request.

That may have been acceptable internally when developers already knew the API.

For an agent, it is nearly useless.

Compare:

operationId: createCustomerRefund

Description:

Create a refund against an existing customer payment. Requires order ID, refund amount and reason. Do not use for chargebacks.

Now the tool has meaningful semantics.

Agent-ready API design therefore requires:

machine-understandable documentation.

The New Developer Skill: Designing Tools for Models

Backend developers traditionally ask:

Is this endpoint technically correct?

They may increasingly also ask:

Can an AI agent understand when and how to use this safely?

That requires new attention to:

  • names
  • descriptions
  • schemas
  • examples
  • constraints
  • side effects

An API can be technically perfect for human developers but poorly designed for AI agents.

Read Tools and Write Tools Should Be Treated Differently

One simple security classification is:

Read tools

Examples:

  • get_customer
  • search_inventory
  • list_orders

Lower risk.

Write tools

Examples:

  • update_customer
  • issue_refund
  • create_order

Higher risk.

Destructive tools

Examples:

  • delete_customer
  • cancel_account
  • terminate_instance

Very high risk.

The gateway should not treat all three classes identically.

Digital Stackroom Agent Tool Risk Matrix

Tool typeExampleRiskRecommended control
ReadGet product infoLowStandard auth + logging
SearchSearch customer recordsMediumScoped access
CreateCreate support ticketMediumValidation + audit
UpdateModify CRM accountHighStrong authorization
FinancialIssue refundHighAmount limits / approval
DestructiveDelete accountVery highExplicit human approval
InfrastructureDeploy productionVery highPrivileged identity + approval

The core principle:

Tool exposure should increase only as control maturity increases.

Tool Poisoning and Misleading Descriptions

Agent-tool ecosystems introduce another risk.

What if a tool description is incorrect or malicious?

For example:

Tool:

safe_data_export

Description:

Generates a harmless customer summary.

But internally it exports a much broader dataset.

Agents often use metadata to decide which tools to invoke.

Therefore tool definitions themselves become security-sensitive artifacts.

Organizations should review:

  • tool names
  • tool descriptions
  • argument schemas
  • backend mappings

with the same seriousness as API code.

Treat Tool Metadata Like Code

A tool description change could alter agent behavior even if the backend code remains unchanged.

That means organizations may eventually need:

  • code review
  • version control
  • change approval
  • automated validation

for MCP tool definitions.

This is another reason OpenAPI specs should live inside proper software-development workflows rather than being edited casually.

Observability Becomes Essential

Google says MCP requests generate normal API Gateway logs and metrics.

MCP traffic can be distinguished through the MCP request path, typically ending in /mcp, or through custom metrics.

This allows teams to ask:

  • Which agents call which tools?
  • Which operations fail?
  • Which tool is used most?
  • Which tools generate unusual latency?
  • Are destructive tools called unexpectedly?

That makes API observability a key part of agent governance.

The Future API Dashboard May Include Agents

Traditional API observability:

Application A called API B 50,000 times.

Agent-era observability may need:

Agent: Procurement Agent
User: Finance Team
Tool: create_purchase_order
Requests: 482
Approvals: 37
Failures: 5
Average latency: 740 ms
Cost: $X

This combines:

identity + tool usage + API telemetry + business activity.

That is much richer than ordinary API logs.

MCP Does Not Eliminate API Governance

Some developers may look at MCP and think:

“Now agents can call everything.”

That is exactly the wrong conclusion.

MCP standardizes connectivity.

It does not automatically provide:

  • correct authorization
  • safe tool design
  • governance
  • business validation
  • human approval

Those remain architecture responsibilities.

A standardized door is still a door that needs access control.

Should Every REST Endpoint Become an MCP Tool?

No.

This may be the single most important architectural principle in this article.

Suppose an API has 300 operations.

An agent might need only 12.

Exposing all 300:

  • increases confusion
  • increases context size
  • increases attack surface
  • increases accidental action risk

Tool catalogs should be curated.

Fewer, Better Tools Are Often Safer

Imagine an agent sees:

update_customer

modify_customer

patch_customer

edit_customer

update_customer_v2

Which should it call?

Humans may understand historical API differences.

The agent may not.

A curated MCP layer can present:

one clear tool

instead of exposing the backend’s entire technical history.

That creates a useful principle:

Your agent interface does not have to mirror your backend interface one-to-one.

The Agent Tool Layer Should Be a Product

Organizations may eventually manage tools like internal products.

Each tool should have:

  • owner
  • description
  • API
  • permissions
  • SLA
  • risk level
  • version
  • audit trail

That allows enterprises to build an internal:

Agent Tool Catalog.

Agents could then use only approved enterprise capabilities.

Digital Stackroom Agent-Ready API Checklist

Before exposing a REST operation as an MCP tool, ask:

Purpose

  • Is there a clear agent use case?
  • Is the tool name understandable?

Description

  • Does the description explain when to use it?
  • Does it explain dangerous side effects?

Inputs

  • Are argument names clear?
  • Are required fields explicit?
  • Are allowed values constrained?

Identity

  • Does every call have a traceable identity?
  • Can we identify the user or system behind the agent?

Authorization

  • Does the agent get minimum required access?
  • Are resource-level permissions enforced?

Risk

  • Is this read-only or state-changing?
  • Is it reversible?

Approval

  • Do high-risk operations require human confirmation?

Observability

  • Are calls logged?
  • Can we correlate agent → tool → backend action?

Limits

  • Are quotas and rate limits configured?

Lifecycle

  • Who owns the tool?
  • How is it deprecated or removed?

If several of these answers are unclear, the API probably is not ready to become an agent tool.

A Practical Adoption Model

Organizations should not expose their entire API estate at once.

Phase 1 — Read-Only Tools

Start with operations such as:

  • lookups
  • searches
  • status checks

Low risk.

Phase 2 — Low-Risk Writes

Add:

  • create ticket
  • add comment
  • create draft

Actions remain reversible.

Phase 3 — Controlled Business Actions

Examples:

  • modify CRM
  • schedule workflow
  • update order

Add stronger authorization.

Phase 4 — Financial and Privileged Actions

Examples:

  • refunds
  • payments
  • production changes

Require:

  • strong identity
  • policy checks
  • human approval

This staged approach reduces risk while teams learn how agents behave.

What This Means for Backend Developers

Backend developers will increasingly build for two consumers:

Human-written applications

and

AI agents

The API may remain identical.

But its metadata and governance become more important.

Developers should invest in:

  • high-quality OpenAPI
  • consistent operation IDs
  • clear descriptions
  • predictable schemas
  • error handling
  • idempotency

Agentic systems punish ambiguity.

Idempotency Becomes Especially Important

Agents may retry operations.

Network failures happen.

Models may repeat steps.

Imagine:

POST /payment

is called twice.

If the API is not designed safely, one agent error could create two payments.

Agent-ready APIs should think carefully about:

  • idempotency keys
  • duplicate detection
  • transaction boundaries

These were already API best practices.

Agents make them more important.

What This Means for DevOps Teams

DevOps responsibilities may expand from:

API uptime

toward:

agent-tool reliability.

Teams may need dashboards showing:

  • MCP latency
  • tool-call errors
  • tool discovery failures
  • authorization failures
  • abnormal usage

The infrastructure supporting AI agents starts looking increasingly similar to production API infrastructure.

What This Means for Security Teams

Security teams will need to answer:

  • Which agents exist?
  • Which MCP servers can they connect to?
  • Which tools can they discover?
  • Which tools can they invoke?
  • Which credentials are used?
  • Which high-risk actions require approval?

This directly connects to the AI agent identity security problem we covered in Blog #8.

Identity without tool governance is incomplete.

Tool governance without identity is incomplete.

What This Means for API Teams

API teams may become much more important in the AI era.

For years, enterprise API programs focused on:

application integration.

Now APIs can become the controlled capability layer underneath AI agents.

That creates a new strategic role:

API teams become the builders of enterprise agent capabilities.

Internal APIs Could Become More Valuable Than Public APIs

Public API ecosystems received enormous attention during the SaaS era.

But enterprise agents may create even more value from internal APIs.

For example:

  • internal employee directory
  • logistics systems
  • finance workflows
  • operational databases
  • support systems
  • inventory platforms

These APIs expose the capabilities agents need to perform real work.

MCP could make these internal assets much easier to consume.

This Is Also a Modernization Strategy

Imagine an old business system from 2014.

It has:

  • stable REST API
  • outdated UI
  • important business logic

Rewriting the entire application might take years.

An AI agent could potentially interact through:

MCP Gateway

↓

existing REST API

↓

legacy system

The user gets a modern natural-language interaction layer without replacing the backend immediately.

That creates a possible modernization pattern:

modernize the interface before modernizing the system.

But MCP Is Not Magic

If the existing API is badly designed, MCP does not fix it.

Problems remain:

  • poor authentication
  • vague schemas
  • unstable endpoints
  • missing documentation
  • dangerous side effects
  • inconsistent errors

MCP can expose those problems more widely.

So the first step toward agentic APIs may actually be:

improve the APIs themselves.

Why API Quality Becomes an AI Quality Problem

Suppose an API returns:

error_code: 42

with no useful explanation.

A developer may look up documentation.

An AI agent may struggle to determine what happened.

Better APIs provide:

  • structured errors
  • meaningful messages
  • predictable status codes
  • retry guidance

Agent reliability therefore depends partly on API reliability.

The Future Enterprise Architecture

A mature architecture may look like:

Employees / Business Systems

↓

AI Agents

↓

Agent Identity Layer

↓

MCP / Tool Gateway

Controls:

  • discovery
  • authorization
  • quotas
  • approvals

↓

API Gateway

↓

Enterprise APIs

↓

Business Systems

↓

Audit + Observability

That architecture combines several trends we have already covered on Digital Stackroom:

These are starting to converge.

MCP Could Become the USB-C of Agent Tools

A common analogy is useful.

Before standardized device connectors, every hardware vendor needed different cables.

A standardized interface reduces integration friction.

MCP attempts something similar for AI tools:

Different agents

↓

Standard protocol

↓

Many tools

The value is not that every backend becomes identical.

The value is that agents gain a common way to discover and call capabilities.

However, standards only create interoperability.

They do not automatically create security or quality.

The Real Competitive Advantage May Be the Tool Ecosystem

AI models are becoming increasingly capable.

If multiple models can reason well, competitive advantage may shift toward:

what they can access and safely do.

An AI agent connected to:

  • CRM
  • billing
  • inventory
  • analytics
  • support
  • deployment tools

can accomplish far more than one limited to text generation.

That means enterprise tool ecosystems may become strategically valuable.

APIs are the raw material for those ecosystems.

Frequently Asked Questions

What is Google Cloud API Gateway MCP support?

It is a Public Preview capability that lets Google Cloud API Gateway act as a remote Model Context Protocol server and expose eligible existing REST API operations as tools for AI agents.

When did Google add MCP support to API Gateway?

Google Cloud announced the feature on September 11, 2026.

Do I need to rewrite my REST backend?

Not necessarily.

Google says API Gateway can translate MCP requests into ordinary REST calls without requiring backend-service changes.

Does Google Cloud API Gateway MCP require OpenAPI?

Yes.

The current preview requires a valid OpenAPI 3.x specification. OpenAPI 2.0 is not supported.

Which HTTP methods can become MCP tools?

Google currently supports eligible:

  • GET
  • POST
  • PUT
  • PATCH
  • DELETE

operations in the Public Preview.

Can I choose which operations become tools?

Yes.

Google supports global MCP enablement as well as per-operation configuration through x-google-mcp-tool, including opting specific operations out.

Does API authentication still apply?

For MCP tools/call, Google says the gateway reuses authentication policies defined for the underlying REST operation.

Is tools/list protected automatically?

Not necessarily.

Google’s current preview documentation says tools/list is unauthenticated by default and recommends protecting it. When authentication is enabled for tools/list, the preview requires JWT; API keys are not supported for that method.

Does AWS support REST APIs as MCP tools?

Yes.

AWS supports exposing API Gateway REST API stages or selected resources through Amazon Bedrock AgentCore Gateway, which translates MCP requests into HTTP API calls.

Does Azure support REST APIs as MCP servers?

Yes.

Azure API Management can expose existing managed REST API operations as MCP tools and can also govern externally hosted MCP servers.

What is the latest MCP specification?

The MCP project released specification version 2026-07-28 on July 28, 2026. Major changes include a stateless protocol core, header-based routing, authorization improvements, and an extensions framework.

Does Google API Gateway already support the 2026-07-28 MCP specification?

Google’s current Public Preview documentation does not explicitly state support for that latest protocol version, and its configuration examples use 2025-11-25. Developers should therefore verify compatibility rather than assume full support for every newer protocol feature.

Final Thoughts

The most interesting thing about Google Cloud API Gateway MCP is not that Google added another AI integration feature.

It is that the boundaries between:

APIs

and:

AI tools

are beginning to disappear.

For decades, organizations invested heavily in creating REST APIs so applications could interact with business systems.

Those investments may now become the foundation of enterprise agent architectures.

Instead of rebuilding every backend:

existing REST API

↓

gateway

↓

MCP tool

↓

AI agent

That is a powerful modernization path.

But it also changes what good API architecture means.

OpenAPI descriptions become agent instructions.

Operation IDs become tool names.

Authentication becomes agent identity.

API permissions become tool permissions.

Rate limits become agent limits.

API logs become agent audit trails.

And the gateway becomes more than infrastructure for application traffic.

It becomes a control point for machine decision-makers.

That suggests the next generation of API management may no longer ask only:

“Which applications can call this API?”

It may also ask:

“Which AI agents can discover this capability, under what identity, with what permissions, and under what conditions?”

The API economy connected software.

The emerging agent economy needs to connect intelligence to action.

MCP may become one of the standards that makes that possible.

And Google Cloud’s decision to bring MCP directly into API Gateway is another sign that agent infrastructure is beginning to merge with the same gateways, authentication systems, APIs and observability platforms enterprises already rely on today.

Scroll to Top