Google Adds MCP Support to Apigee Hybrid for In-Cluster Tools

Google shipped Model Context Protocol support in Apigee hybrid 1.17.0 on September 14, 2026, running the MCP data plane inside the customer's Kubernetes cluster. Google Developers Blog's report, published October 14, 2026 by software engineers Ayo Salawu and Sundar Ramamoorthy, describes the release. Agent traffic and tool execution stay in that cluster while configuration is pulled from the Apigee control plane. OpenAPI 3.0.x specifications become MCP tools under existing security policies and API products.

This piece is for platform and security teams running Apigee hybrid in a data center, a colocation facility, or another public cloud, and for API owners who want agents calling those APIs. The runtime is there because a regulator requires it, because the systems of record are three racks away, or because the estate is multi-cloud. It covers the tool model, the data plane, governance, Helm enablement, and tools/call tracing.

What Google MCP support in Apigee hybrid shipped

Last December, Google announced a preview of MCP support in Apigee. APIs already secured, governed, and cataloged could become tools AI agents discover and call, without new MCP server code and without an MCP server run as separate software. Customers asked, "can I have this where my runtime actually lives?" Apigee hybrid 1.17.0, released September 14, 2026, keeps that model. A developer describes the API with an OpenAPI 3.0.x specification and creates an MCP Discovery Proxy. Every operation becomes an MCP tool.

Agents use JSON-RPC tools/list to discover tools and tools/call to invoke one. Apigee handles the protocol and the transcoding. The control plane generates MCP tool configuration from the OpenAPI Specification, the cluster fetches it periodically, and traffic never leaves the cluster. A tools/call is received, authorized, and proxied to the backend. No MCP request or response crosses to Google Cloud at request time. A sidecar pulls configuration. The control plane never opens an inbound connection, so MCP needs no path from Google into the network.

What changed for builders in Google MCP support in Apigee hybrid

Agentic endpoints run on the Kubernetes platform that hosts Apigee hybrid. The sidecar reuses the existing apigee-watcher identity. No new Google service account is created, and no new IAM role is granted. One control-plane grant per organization lets that identity do the rest. Subscription and Evaluation organizations qualify, including Data Residency-enabled organizations configured at organization setup. Configuration is fetched from the control plane location, and the request path stays in the cluster. The constraint "the request may not leave this jurisdiction, this facility, or this VPC" is met by that architecture.

MCP endpoints are Apigee proxies. They inherit OAuth 2.0, OpenID Connect, API key verification, and Apigee's built-in policy library. An API product lists the tool operations a client may call, optionally with a per-tool quota, and Apigee enforces it. tools/list returns only the tools in that client's product. An agent cannot call delete_account if it was never allowed to see it. Deployed MCP Discovery Proxies are ingested into Apigee API hub, assigned the MCP API style, with each operation mapped to a tool in a natural-language catalog rather than a spreadsheet of endpoints.

How to install or upgrade Google MCP support in Apigee hybrid

MCP stays off until a Helm change on a cluster running Apigee hybrid 1.17.0 or later. Set enableMcpServer to true in overrides.yaml, then upgrade the apigee-operator chart before the apigee-org chart. The operator chart owns the schema for the new MCP resources. The reverse order yields a successful upgrade with no MCP pods. A one-time grant per organization adds apigee-watcher to control plane access so the sidecar can fetch configuration. Defaults are two MCP replicas, autoscaling to ten. Rollback sets that field to false and upgrades one chart.

Enabling or disabling MCP triggers a staged canary of runtime pods, so the change belongs in an approved maintenance window. Every agent request arrives at the same /mcp path, and Apigee tags it with the tool name. The sample tools/call below is for distributed trace enabled in Apigee with OTEL. It POSTs to placeholder host xxx.xxx.xxx.net at /mcp, with Content-Type application/json and MCP-Protocol-Version 2025-11-25. The body is JSON-RPC 2.0, id 321, method tools/call, name createReward, argument reward 123, and _meta.traceparent 00-3ad8012d970b3971cb16cda653a1a370-df3047d1d0830dc0-01.

enableMcpServer: true

enableMcpServer: false

curl -X POST "https://xxx.xxx.xxx.net/mcp" \
-H "Content-Type: application/json" \
-H "MCP-Protocol-Version: 2025-11-25" \
-d '{
"jsonrpc": "2.0",
"id": 321,
"method": "tools/call",
"params": {
"name": "createReward",
"arguments": {
"reward": "123"
},
"_meta": {
"traceparent": "00-3ad8012d970b3971cb16cda653a1a370-df3047d1d0830dc0-01"
}
}
}'

Gotchas and compatibility in Google MCP support in Apigee hybrid

A reported success can still mean no MCP pods. Upgrading apigee-org before apigee-operator does that, because the new resource schema is on the operator chart. The default also leaves MCP off on 1.17.0 until enableMcpServer is true. Enable and disable both canary runtime pods, so the change belongs in an approved maintenance window. The sidecar cannot fetch configuration until a one-time grant adds apigee-watcher to the organization's control plane access. Rollback sets enableMcpServer to false and upgrades a single chart.

Every tool shares /mcp. Apigee tags each request with the tool name so insights can split that endpoint. The release view shows proxy mcp beside mcp-healthcare, mcp-petstore, and mcp-statuscode, with response time and tps. REST backends cannot read W3C trace context in JSON-RPC _meta. Apigee extracts it and forwards traceparent and tracestate headers. One Cloud Trace view needs every Apigee and non-Apigee service on the same Google Cloud Trace. SEP-2028, an open proposal in the MCP community, aims to standardize that _meta-to-header forwarding of W3C trace context.

What to watch after Google MCP support in Apigee hybrid

An MCP tool call crosses an AI client, Apigee, and the backend. Today each is its own island of logs, so when platform teams ask "where did the time go?" there is no single answer. With distributed trace enabled in Apigee with OTEL, Google Cloud Trace shows the call in one view. One trace ID spans the AI client, the Apigee proxies, and backend execution. Backends join that trace without recoding. Passthrough mode forwards context without its own infrastructure spans, which trims trace ingestion cost.

In API insights, filters for API style and MCP tool name separate agentic traffic from ordinary REST and isolate one tool. That tool appears on the API performance, error analysis, latency, and target performance dashboards. The ratio of discovery to execution sets tools/list against tools/call, and proxy overhead separates from backend time. The tool performance tab shows which tools were called, how often, and over what period. MCP Discovery Proxies in Apigee API hub use the MCP API style. The sample sends MCP-Protocol-Version 2025-11-25.