Apigee Hybrid brings MCP tool traffic inside customer Kubernetes clusters

Google [announced MCP support in Apigee Hybrid 1.17.0](https://developers.googleblog.com/announcing‑mcp‑support‑in‑apigee‑hybrid‑agentic‑tools‑that‑run‑in‑your‑own‑cluster/). The MCP data plane runs in the customer’s Kubernetes cluster, while the Google‑managed control plane supplies configuration. Runtime tool traffic does not need an inbound path from Google. The component exposes selected OpenAPI 3.0.x operations as MCP tools and implements JSON‑RPC operations such as `tools/list` and `tools/call`. It also propagates W3C trace context for observability. Keeping the runtime local reduces one network boundary. It does not remove the need to secure the cluster, APIs or agent caller.

The feature is disabled by default. Google’s [enablement guide](https://docs.cloud.google.com/apigee/docs/api‑platform/apigee‑mcp/enable‑mcp) requires the 1.17.0 hybrid software and Helm configuration for the operator and organization charts. The operator chart must be applied before the organization chart. Google warns that reversing the order can leave the change unapplied without an obvious deployment failure. Confirm the resulting MCP data‑plane pods and configuration instead of treating a successful Helm command as acceptance. The default deployment uses two replicas and can autoscale to ten. Set resource and disruption policy from measured load rather than assuming defaults fit every cluster.

The hybrid‑specific documentation describes one‑way TLS between the runtime and MCP data plane. The data plane trusts requests from the Message Processor and does not independently authenticate every caller at that hop. Google therefore recommends restricting TCP 443 ingress to workloads labelled `app=apigee‑runtime`. Without that boundary, another pod that can reach the service could enter a path the component expects to receive only from the runtime. Apply and test the network policy before production exposure. Verify both the intended runtime path and a denied request from an unrelated pod.

MCP must be enabled consistently for environments in the same environment group. A mixed configuration can return HTTP 503 during routing. Google recommends a staged rollout, but the unit of consistency still matters when planning a canary. The [Apigee MCP overview](https://docs.cloud.google.com/apigee/docs/api‑platform/apigee‑mcp/apigee‑mcp‑overview) lists a limit of 1,000 tools per organization and supports OpenAPI 3.0.0 through 3.0.3. Tool discovery and execution also inherit the API proxy’s authentication, quota and policy behavior. Inventory operations before enabling discovery. Publishing every endpoint as a tool can create an unusable catalog and a larger permission surface.

Start with one bounded API proxy and a minimal set of operations. Confirm `tools/list`, call a non‑destructive operation, trace the request through the runtime and verify the result uses the intended credentials and quota policy. Then test an unauthorized tool call, an unrelated pod, an inconsistent environment‑group rollout and a data‑plane replica restart. Record the cluster, chart versions and exact exposed operations. Client‑side MCP startup controls remain a separate concern, as shown in [GitHub Copilot’s JetBrains controls](https://opentools.ai/news/github‑copilot‑jetbrains‑default‑model‑mcp‑startup‑controls‑october‑2026). *Image: Real screenshot of Google Cloud’s official Apigee MCP documentation. OpenTools rejected the generated promotional blog artwork and captured the documentation without generative alteration or artificial upscaling.*