宣布 Apigee hybrid 支持 MCP：可在自有集群中运行的 Agent 工具

去年 12 月，我们宣布预览 Apigee 对 MCP 的支持：能够将你现有的、已获保护、治理和编目管理的 API 转换为 AI Agent 可发现和调用的工具，无需编写代码，也无需自行部署 MCP Server。客户的反馈来得很快，而他们随即提出的第一个问题是：“能否让它运行在我的实际运行时所在的位置？”

对于许多 Apigee 客户而言，运行时并非偶然地不在 Google 托管的基础设施上。它部署在自己的数据中心、托管机房或另一家公有云中，原因可能是监管要求、核心记录系统就在三个机架之外，或者多云环境本就是企业现实。这些客户并非在询问是否需要让 Agent 访问其 API，而是在问：能否在不迁移运行时的前提下实现这一点。

现在可以了。随着 Apigee hybrid 1.17.0 于 2026 年 9 月 14 日发布，Apigee hybrid 已提供 Model Context Protocol 支持，MCP 数据平面可运行在你自己的 Kubernetes 集群内。

相同的模型，不同的部署位置

概念模型与我们此前在 Apigee 中发布的版本完全一致。你使用 OpenAPI 3.0.x 规范描述 API，并基于该规范创建 MCP Discovery Proxy。规范中的每一项操作都会成为一个 MCP 工具。Agent 通过 JSON-RPC 与端点通信，使用 tools/list 发现可用工具，使用 tools/call 调用工具；Apigee 则负责协议处理和转码。你无需编写 MCP Server 代码，也无需将 MCP Server 作为具有独立生命周期的软件单独运维。

在 hybrid 中，变化的是工作发生的位置。在 Apigee hybrid 中，MCP 数据平面运行在你自己的 Kubernetes 集群内。Apigee 控制平面根据你的 OpenAPI Specification 生成 MCP 工具配置，集群会定期获取这些配置，MCP 请求流量则始终不会离开集群。 下图展示了 MCP 数据平面在不同部署模型中的运行位置。

这一架构有两项特性值得明确说明，因为它们正是安全审查团队会关注的问题。

MCP 请求流量留在你的集群内。 Agent 的 tools/call 请求将在你自己的基础设施内被接收、授权，并代理至后端。在请求处理期间，没有任何 MCP 请求或响应会跨越边界进入 Google Cloud。

配置由集群拉取，而不是由控制平面推送。 与 MCP 数据平面并置的 sidecar 会从你的集群内部发起请求，以获取由规范生成的工具配置。Apigee 控制平面位于 Google Cloud 中，绝不会主动向你的集群发起连接，这意味着 MCP 不需要从 Google 到你网络的入站通路。

这对多云和本地部署意味着什么

1. Agent 端点运行在 API 已经运行的位置。 Apigee hybrid 已允许你在自行选择的 Kubernetes 平台上托管运行时，MCP 同样继承了这一能力。MCP sidecar 会复用现有的 apigee-watcher 身份。无需创建新的 Google 服务账号，也无需授予新的 IAM 角色。每个组织只需进行一次控制平面授权，现有身份即可完成其余工作。
2. 数据驻留与数据主权策略得以延续。 Apigee hybrid 中的 MCP 可用于 Subscription 和 Evaluation 组织，包括启用了 Data Residency 的组织（在组织创建时配置）。在 hybrid 架构中，配置从控制平面所在位置获取，而运行时请求路径则天然保留在集群中。对于要求“请求不得离开这一司法辖区、这一设施或这一 VPC”的团队而言，该约束由架构提供支持，而非依赖某项配置开关。
3. 你已经编写的治理规则同样适用于 Agent。 MCP 端点属于 Apigee 代理，因此可继承平台能力，包括 OAuth 2.0、OpenID Connect、API 密钥验证以及 Apigee 内置策略库。工具级控制来自你已经使用的概念：API product。你可以列出某个客户端有权使用的具体工具操作，并可选择为每个工具设置配额，由 Apigee 负责执行。Apigee 还会自动过滤发现结果：当客户端调用 tools/list 时，响应中仅包含该客户端 API product 内的工具。如果 Agent 从未被允许看到 delete_account，它就无法调用该工具。
4. 你的 Agent 流量会出现在 API 流量所在的地方。 已部署的 MCP Discovery Proxies 会自动导入 Apigee API hub，被分配 MCP API 风格，其操作会映射为单独的工具，形成可搜索的目录；开发者可用自然语言查询，而不必面对端点电子表格。在 API insights 中，借助 API style 和 MCP tool name 两项筛选条件，你可以将 Agent 流量与普通 REST 流量分离，并在 API 性能、错误分析、延迟和目标性能仪表板中查看单个工具。你可以看到发现与执行的比例，并区分代理开销与后端处理时间。

启用 MCP

MCP 是 Apigee hybrid 的一项可选功能，默认未启用。在已运行 Apigee hybrid 1.17.0 或更高版本的集群中，启用它需要执行 Helm 操作。具体步骤如下。

在 overrides.yaml 中设置顶层键 enableMcpServer: true，然后先升级 apigee-operator chart，再升级 apigee-org chart。这个顺序很重要：operator chart 负责新 MCP 资源的 schema；如果以错误顺序升级，升级操作虽然会显示成功，但不会产生 MCP Pod。每个组织还需要进行一次性授权，将 apigee-watcher 身份加入组织的控制平面访问权限，以便 sidecar 获取配置。默认设置已较为合理：两个 MCP 副本，并可自动扩缩容至十个副本。回滚时，只需将同一字段设为 false 并执行一次 chart 升级。

在安排变更前，还有几项事项需要规划。启用或停用 MCP 会触发运行时 Pod 的分阶段金丝雀发布，因此应在获批准的维护窗口内执行。公共文档在此介绍了如何在现有 Apigee hybrid 集群中启用 MCP。

在 Apigee 中观测 MCP 流量

你的 MCP 代理以单一端点暴露。无论 Agent 调用了什么工具，每个 Agent 请求都会到达同一条 /mcp 路径。Apigee 会为每个请求标注被调用工具的名称，因此 API insights 可以按工具拆分这一端点，展示 Agent 实际使用了哪些工具、使用频率及使用时段。下方截图展示了 API insights，包括对 MCP 代理（mcp）的请求，以及各个工具（作为 API 代理 mcp-healthcare、mcp-petstore、mcp-statuscode）的响应时间和 TPS。有关如何通过 Apigee API insights 监控和分析 MCP 流量，请参阅公共文档此处，以及有关如何使用 API insights 仪表板的此处。

我们还在下方 API insights 的工具性能标签页中提供了工具调用视图。

下一步：端到端追踪一次 Agent 调用

一次 MCP 工具调用会跨越 AI 客户端、Apigee 和你的后端。如今，这些环节各自是独立的日志孤岛，因此平台团队真正关心的问题——“时间究竟花在了哪里？”——没有统一答案。

以下代码片段展示了来自 AI 客户端的一次 MCP 工具调用请求示例。当 Apigee 启用 OTEL 分布式追踪后，下面的 curl 请求可实现请求的端到端追踪。

shell 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" } } }'

同一次调用在 Google Cloud Trace 中通过分布式追踪编排后，可在一个全局视图中完整展示调用链路。（前提是链路中的所有服务，包括 Apigee 和非 Apigee 服务，均向同一个 Google Cloud Trace 报告数据。）

MCP 客户端会在 JSON-RPC 的 _meta 字段中携带 W3C 追踪上下文，而传统 REST 后端并不知道如何读取它。Apigee 会提取这些信息，并将其作为普通的 traceparent 和 tracestate 请求头转发，因此下游已接入监控的服务无需修改代码即可加入同一追踪链路。这会带来三项结果：一个跨越 AI 客户端、Apigee 代理和后端执行过程的统一 trace ID；无需重新编码即可参与追踪的后端；以及更少的噪声，因为网关可以通过透传模式转发上下文，而不是自行发出基础设施 span，这也能降低追踪数据采集成本。

整个生态系统正朝着同一思路收敛。MCP 社区中的开放提案 SEP-2028 旨在将 W3C 追踪上下文从 _meta 转发至请求头的行为标准化，作为 MCP Server 的标准行为。

在 Apigee 中，承载 W3C 追踪上下文的 OpenTelemetry 路径现已可用。

后续步骤

MCP 支持现已在 Apigee hybrid 1.17.0 中提供。你可以从 Apigee 中的 MCP 概览了解架构，阅读在 Apigee hybrid 中启用 MCP了解 Helm 操作流程，并通过 MCP 快速入门让第一个工具开始响应 Agent 请求。

Last December, we announced preview of MCP support in Apigee: the ability to turn the APIs you already have, secured, governed and cataloged into tools that AI agents can discover and call, without writing code or standing up MCP servers of your own. The response from customers was immediate and so was the first question back: “ can I have this where my runtime actually lives?”

For many Apigee customers, the runtime does not live on Google-managed infrastructure by accident. It lives in their own data center, in a colocation facility, or in another public cloud because a regulator requires it, because the systems of record are three racks away, or because a multi-cloud estate is simply the reality of the business. Those customers were not asking whether they wanted agentic access to their APIs. They were asking whether they could get it without moving the runtime.

And now they can. With Apigee hybrid 1.17.0 , released on September 14, 2026, Model Context Protocol support is available in Apigee hybrid and the MCP data plane runs inside your own Kubernetes cluster.

The same model, in a different place

The conceptual model is the one we shipped on Apigee, unchanged. You describe your API with an OpenAPI 3.0.x specification and create an MCP Discovery Proxy from it. Every operation in that spec becomes an MCP tool. Agents talk to the endpoint over JSON-RPC using tools/list to discover what is available and tools/call to invoke it and Apigee handles the protocol and the transcoding. You do not write MCP server code and you do not operate an MCP server as a separate piece of software with its own lifecycle.

What changes in hybrid is where the work happens. In Apigee hybrid, the MCP data plane runs inside your own Kubernetes cluster. The Apigee control plane generates MCP tool configuration from your OpenAPI Specification, your cluster fetches that configuration periodically and MCP request traffic never leaves the cluster. The diagram below shows where the MCP data plane runs in each deployment model.

Two properties of that architecture are worth stating plainly because they are the ones your security review team will ask about.

MCP request traffic stays inside your cluster. An agent's tools/call request is received, authorized and proxied to your backend entirely within your own infrastructure. No MCP request or response crosses the boundary to Google Cloud at request time.

Configuration is pulled, not pushed. A sidecar alongside the MCP data plane (from within your cluster) reaches out to fetch the tool configuration derived from your spec. The Apigee control plane (in Google Cloud) never initiates a connection into your cluster, which means MCP requires no inbound path from Google into your network.

What this means for multi-cloud and on-premises

1. Agentic endpoints run where your APIs already run. Apigee hybrid already lets you host the runtime on the Kubernetes platform of your choice and MCP inherits that. The MCP sidecar reuses the existing apigee-watcher identity. There is no new Google service account to create and no new IAM role to grant. One control-plane grant per organization and the identity you already have does the rest.
2. Data residency and sovereignty posture carry over. MCP in Apigee hybrid is available for Subscription and Evaluation organizations, including Data Residency–enabled organizations (configured at organization setup). On hybrid, configuration is fetched from your control plane location and the runtime request path stays in your cluster by construction. For teams whose constraint is "the request may not leave this jurisdiction, this facility, or this VPC," that constraint is supported by the architecture rather than by a setting.
3. The governance you already wrote applies to agents. MCP endpoints are Apigee proxies, so they inherit the platform: OAuth 2.0 and OpenID Connect, API key verification as well as Apigee's built-in policy library. Tool-level control comes from a concept you already use, the API product. You list the specific tool operations a client is entitled to, optionally with a per-tool quota and Apigee enforces it. It also filters discovery automatically. When a client calls tools/list, the response contains only the tools in that client's API product. An agent cannot call delete_account if it was never allowed to see it.
4. Your agentic traffic shows up where your API traffic does. Deployed MCP Discovery Proxies are automatically ingested into Apigee API hub, assigned the MCP API style and their operations mapped to individual tools a searchable catalog that developers can query in natural language rather than a spreadsheet of endpoints. In API insights, two filters, API style and MCP tool name let you isolate agentic traffic from ordinary REST traffic and look at a single tool across the API performance, error analysis, latency and target performance dashboards. You can see the ratio of discovery to execution and you can tell proxy overhead apart from backend time.

Turning it on

MCP is an optional feature in Apigee hybrid and is not enabled by default. Enabling it is a Helm operation on a cluster already running Apigee hybrid 1.17.0 or later. Steps to do this are as follows.

Set the top-level enableMcpServer: true key in your overrides.yaml, then upgrade the apigee-operator chart first and the apigee-org chart second. The order matters. The operator chart owns the schema for the new MCP resources and upgrading in the wrong order produces a successful upgrade with no MCP pods. There is also a one-time, per-organization grant that adds the apigee-watcher identity to your organization's control plane access, so the sidecar can retrieve configuration. Defaults are sensible out of the box. Two MCP replicas, autoscaling to ten. Rolling back is the same field set to false and a single chart upgrade.

A few things to plan for before you schedule the change. Enabling or disabling MCP triggers a staged canary release of runtime pods, so run it in an approved maintenance window. The public documentation here describes how to enable MCP in an existing Apigee hybrid cluster.

Observing MCP Traffic within Apigee

Your MCP proxy is exposed as a single endpoint. Every agent request, whatever tool it invokes, arrives at the same /mcp path. Apigee tags each of those requests with the name of the tool that was called, so API insights can break that one endpoint out by tool and show which tools your agents actually used, how often and over what period. The screenshot below shows API insights, including requests to the MCP proxy (mcp) and also see individual tools (as API proxies mcp-healthcare, mcp-petstore, mcp-statuscode) response time and tps. See public documentation on monitoring and analyzing mcp traffic with Apigee API insights here and here on how to use the API insights dashboard.

We also have a view of tools being called in the tool performance tab within API insights below.

What's next: tracing an agent's call end to end

An MCP tool call crosses an AI client, Apigee and your backend. Today each of those is its own island of logs, so the question platform teams actually ask “where did the time go?” has no single answer.

The snippet below is an example mcp tools call request from an AI client. The curl request below allows for end to end tracking of the request, when distributed trace is enabled in Apigee with OTEL.

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"
      }
    }
  }'

Shell

The same call as orchestrated by distributed trace in Google CloudTrace shows the calls in its entirety in one global view. (Assumption is all services (Apigee/Non-Apigee) in the chain report to the same Google CloudTrace)

MCP clients carry W3C trace context inside the JSON-RPC _meta field, which a conventional REST backend has no idea how to read. Apigee extracts it and forwards it as ordinary traceparent and tracestate headers, so instrumented services downstream join the trace without code changes. Three things follow: a single trace ID spanning the AI client, the Apigee proxies and backend execution; backends that participate without recoding and less noise, because the gateway can forward context in passthrough mode rather than emitting infrastructure spans of its own which also trims trace ingestion cost.

The ecosystem is converging on the same idea. SEP-2028, an open proposal in the MCP community, aims to standardize _meta-to-header forwarding of W3C trace context standard behavior for MCP servers.

The OpenTelemetry path that carries W3C trace context is available in Apigee today.

Next steps

MCP support is available now in Apigee hybrid 1.17.0. Start with the MCP in Apigee overview for the architecture, Enable MCP in Apigee hybrid for the Helm procedure and the MCP quickstart to get a first tool answering an agent.