Google is bringing the ability to turn existing APIs into tools that AI agents can discover and call to Apigee's self-managed environment. Teams running APIs in their own data centers or other clouds can now handle agent requests within their own clusters without moving their runtime environments.

1. The approach to turning APIs into tools stays the same

This support is included in Apigee hybrid 1.17.0, released on September 14, 2026. Google previously announced Apigee's MCP support in preview in December 2025. MCP is a communication protocol for AI agents to discover and call tools.

When developers describe an API with an OpenAPI 3.0.x specification and create an MCP Discovery Proxy, each operation in the specification becomes a tool. The proxy converts agent calls into existing API requests. There is no need to write separate MCP server code or operate it as standalone software.

Agents discover tools through tools/list and invoke them through tools/call. As before, Apigee handles the communication protocol and request conversion.

2. Request processing and configuration delivery take separate paths

What changes is the execution location. The component that actually processes MCP requests runs inside the user's Kubernetes cluster. Receiving calls, checking permissions, and forwarding to backends all happen within the user's infrastructure. MCP requests and responses do not pass to Google Cloud during request processing.

Tool configurations, however, are created in Google Cloud's control plane, which manages settings. A helper process inside the cluster fetches them periodically, so no inbound path is needed for Google to initiate connections into the cluster. Requests staying internal does not mean configuration management is disconnected from external systems.

3. Reuse existing access policies and observability systems

MCP endpoints are Apigee proxies, so existing authentication and policies apply. Tools allowed for a client are specified in an access bundle called an API product, with per-tool call limits available if needed. Tool lists also show only the items permitted for that client.

Deployed tools are automatically registered in API hub for discovery. API insights separates agent traffic from regular API traffic and shows performance, errors, and latency by tool. Even when requests share one path, Apigee labels them with tool names, allowing users to distinguish individual tool usage and backend processing times.

4. Check both the activation sequence and operational workload

The feature is disabled by default and requires a cluster running 1.17.0 or later. It is enabled using Helm, a deployment tool.

Set enableMcpServer: true at the top level of the overrides.yaml configuration file.

Upgrade the Helm deployment packages, called charts, in this order: apigee-operator first, then apigee-org. Reversing the order can leave MCP runtime units uncreated even if the upgrade succeeds.

To fetch configurations, grant the existing apigee-watcher identity control plane access once per organization. No new Google service account or IAM role is needed.

The default number of runtime replicas is 2, with automatic scaling up to 10.

The benefit is less work operating a separate MCP server, reuse of existing security policies, and internal request processing. In return, the cluster must accommodate replicas and helper processes. Both activation and deactivation replace running processes in stages, so the source recommends using an approved maintenance window.

5. Call tracing requires instrumentation prerequisites

Distributed tracing attaches the same tag to a request across services to identify where delays occur. Apigee extracts tracing information from _meta in MCP messages and forwards it as standard HTTP headers. Backends that already have tracing instrumentation can join the same trace without code changes.

The following excerpt from the source's call example contains tracing information.

          "_meta": {
            "traceparent": "00-3ad8012d970b3971cb16cda653a1a370-df3047d1d0830dc0-01"
          }

The source example assumes OpenTelemetry-based distributed tracing is enabled in Apigee and services along the call path report to the same Google Cloud Trace. In-cluster execution alone therefore does not automatically provide end-to-end call tracing.

SEP-2028, which seeks to standardize the related propagation mechanism, remains a public proposal.

This support opens agent access while preserving API execution location and existing controls, while adoption decisions must also account for cluster resources and the workload of making changes.