Apigee Hybrid MCP: Keep Agent Tool Traffic Inside Your Cluster

Google added Model Context Protocol support to Apigee hybrid on October 14, 2026. The release gives enterprises a way to turn selected API operations into MCP tools while processing agent requests inside a customer-managed Kubernetes cluster.

That local request path is useful for organizations with strict network, residency or operational requirements. It does not make the system disconnected from Google Cloud. The runtime and management responsibilities remain split, and that distinction should shape the security review.

This article turns the release into a practical architecture and rollout checklist for platform, security and AI engineering teams.

What stays inside the cluster

Apigee hybrid separates a Google-managed control plane from a runtime plane that the customer operates on supported Kubernetes infrastructure. With MCP enabled, the in-cluster runtime handles the agent's discovery and execution requests.

The runtime exposes two JSON-RPC operations to the MCP client:

• tools/list returns the tools available to that client.
• tools/call invokes an entitled API operation through the Apigee runtime.

Google's announcement says the MCP request and response do not cross into Google Cloud at request time. The agent request, Apigee policy processing and call to the target API remain on the customer-controlled runtime path.

The control plane still has a role. Apigee generates tool configuration from an OpenAPI 3.0 specification, and the cluster periodically pulls that configuration. The pull model avoids an inbound configuration path from Google Cloud, but the runtime still needs the outbound connectivity required by Apigee hybrid.

The trust boundary is therefore more precise than “MCP is local.”

| Activity | Primary location | Review question | |---|---|---| | MCP tool discovery and execution | Customer-managed Kubernetes cluster | Can the runtime reach only approved targets? | | Authentication and Apigee policy enforcement | Customer-managed runtime | Which identity reaches the proxy and the target API? | | Tool definition and configuration | Google-managed control plane, then pulled by the runtime | Who can publish or change an exposed operation? | | Runtime operations and telemetry | Split across the hybrid architecture | Which records leave the cluster, and how are they retained? |

This is a strong fit when the request path must stay in a controlled network. Teams should still document the configuration and telemetry flows rather than treating the architecture as an air-gapped deployment.

Make the tool catalogue an explicit contract

Apigee can create a Discovery Proxy from an OpenAPI 3.0.x definition. Operations in that specification become MCP tools, so the API contract also becomes an agent capability contract.

That raises the stakes of specification hygiene. Before publishing a proxy, review:

• which operations are present in the OpenAPI document
• whether tool names and descriptions are clear enough for an agent to select correctly
• which parameters are required and how errors are represented
• whether state-changing operations can be separated from read-only operations
• whether deprecated or administrative endpoints have been removed

Avoid exposing a broad specification just because the underlying API already exists. Build a narrow agent-facing surface around a specific workflow. A clean contract improves tool selection and gives reviewers a manageable authorization boundary.

API products provide the next layer of control. Apigee can use product entitlements to filter tools/list, so a client sees only the tools it is permitted to call. This reduces accidental discovery, but it does not replace runtime authorization. The proxy and target service should still verify the identity and permissions attached to each request.

For a different Google Cloud deployment model, compare this approach with our review of MCP support in Google Cloud API Gateway. API Gateway is a managed gateway path. Apigee hybrid is relevant when the runtime boundary and cluster operations need to remain under customer control.

Decide whose identity performs each action

There are at least three identities to model:

1. The human or application asking the agent to perform work.
2. The MCP client connecting to Apigee.
3. The workload identity used by the Apigee runtime and its configuration watcher.

Apigee MCP supports OAuth 2.1 and OpenID Connect. Its authorization model can restrict tools by OAuth client identity. That is helpful, but client identity alone may not preserve the end user's authority. If one shared agent credential represents every user, downstream services may see the agent without knowing who initiated the action.

For higher-risk workflows, carry verified user context through the proxy or require an explicit approval before a state-changing tool call. Google also states that the MCP client is responsible for human oversight of such operations. The gateway can enforce policy; it cannot decide the organization's approval standard.

Enabling MCP in hybrid adds an in-cluster watcher and related Kubernetes resources. Google documents two identity options for that watcher: reuse the existing apigee-watcher identity or create a dedicated Google service account when a separate audit trail is required. Reuse is simpler. Separation is easier to review when MCP configuration access needs its own ownership and logs.

Treat enablement as a platform change

MCP support is optional and disabled by default. Enabling it is more than flipping a feature flag in a console. The documented hybrid sequence updates the operator first, then the organization chart with enableMcpServer: true.

That order matters because enablement adds MCP pods, a Kubernetes Service, horizontal autoscaling and role-based access resources. Apigee also performs a staged canary release of message processors while the previous pod remains until the replacement is ready.

Plan the change in a maintenance window even though the rollout is staged. Capture the current Helm values, resource state and service health before starting. Define the rollback trigger in advance, including what will happen to tool clients if the new endpoint is removed.

Google's defaults start with two MCP replicas and allow scaling to ten at 70 percent CPU utilization. These are deployment defaults, not a capacity guarantee. Test discovery bursts and concurrent tool calls with the policies, target latency and payload sizes expected in production.

The platform constraints belong in the design review too. The current documentation lists a limit of 1,000 MCP tools per organization, accepts OpenAPI 3.0.0 through 3.0.3 and does not support Server-Sent Events. API insights are unavailable for organizations protected by VPC Service Controls. Apigee hybrid itself is not supported on GKE Autopilot, so the cluster choice must be checked before the pilot is scheduled.

Build evidence for discovery and execution

Tool discovery and tool execution answer different operational questions. A successful tools/list call shows that the client can see the intended catalogue. It does not show that tools/call can reach the target, pass authorization and return a correct result.

Instrument both paths separately. Apigee analytics can distinguish discovery from execution and report tool-specific performance. For a production pilot, record at least:

• discovery success rate and response time
• tool-call count, error rate and latency by tool
• proxy processing time versus target service time
• authentication and authorization failures
• rejected or malformed tool arguments
• the initiating client identity and, where appropriate, the verified end-user identity

Apigee can also propagate W3C trace context from MCP JSON-RPC metadata into traceparent and tracestate headers. Use that support to follow one request from the agent through the proxy to the target service. Test the correlation directly; do not assume every client library sends trace metadata correctly.

A focused pilot checklist

Choose one workflow with a small set of well-understood APIs. Read-only operations are a safer starting point than transactions.

1. Draw the runtime, control-plane, target-service and telemetry flows, including required outbound connections.
2. Create a reduced OpenAPI 3.0.x specification containing only the operations the agent needs.
3. Write tool descriptions for unambiguous selection and validate argument handling with malformed and adversarial inputs.
4. Define API products and OAuth clients around job roles, then confirm that tools/list hides tools outside each entitlement.
5. Decide how end-user identity and approval evidence will survive the agent-to-tool handoff.
6. Select the watcher identity model and document who can change MCP configuration.
7. Enable the feature in a maintenance window, verify the staged rollout and run a tested rollback procedure.
8. Load-test discovery and execution independently, then trace representative calls through the target service.
9. Review logs for enough evidence to reconstruct who requested, authorized and executed each consequential action.
10. Expand the tool surface only after the first contract, policy and incident-review process are working.

The practical value of Apigee hybrid MCP is control over the request path. Real control also depends on a narrow tool catalogue, identity continuity, disciplined cluster operations and evidence that survives after an agent session ends.

Bayseian helps enterprise teams design and evaluate AI systems with those production boundaries in place. A focused pilot can test the data path and governance model before more APIs become agent tools.

Sources

• Google Developers Blog, “Announcing MCP support in Apigee Hybrid: Agentic tools that run in your own cluster”, October 14, 2026.
• Google Cloud, Apigee MCP overview, accessed October 19, 2026.
• Google Cloud, Enable MCP with Apigee hybrid, accessed October 19, 2026.
• Google Cloud, What is Apigee hybrid?, accessed October 19, 2026.
• Google Cloud, Apigee hybrid supported platforms, accessed October 19, 2026.