Picture this. You run platform security at a company whose API runtime cannot leave your own infrastructure. Your agent team keeps asking for tools their agents can call, and every time the answer has been the same: the traffic has to stay inside, and nobody is opening an inbound path from a vendor into your network. Then you read what Google has just published about Apigee.
In Announcing MCP support in Apigee hybrid, the post explains that last December's preview turned existing APIs "secured, governed and cataloged" into tools agents can call "without writing code or standing up MCP servers of your own." The first question back from customers, it says, was "can I have this where my runtime actually lives?" With Apigee hybrid 1.17.0, released in September, "the MCP data plane runs inside your own Kubernetes cluster." That is the sentence you were waiting for. There are no adoption figures in the post, so you cannot tell how many teams are doing this yet.
The two properties a security review will ask about are stated plainly. First, "MCP request traffic stays inside your cluster": when an agent makes a tools/call, it is received, authorized and proxied entirely within your infrastructure. Second, "configuration is pulled, not pushed." A sidecar fetches the tool configuration from the control plane, so "MCP requires no inbound path from Google into your network." Those are the two answers your reviewers will want in writing.
The model for building tools is otherwise unchanged. You describe an API in OpenAPI 3.0.x, create an MCP Discovery Proxy, and "every operation in that spec becomes an MCP tool." Governance carries over because MCP endpoints are Apigee proxies. OAuth, OpenID Connect, API keys and the policy library apply. The API product lists which tools a client may call, with an optional per-tool quota, so you decide which operations an agent can reach and how often.
The post is honest about the operational edge, which you should plan around. Upgrade the charts in the wrong order and you get "a successful upgrade with no MCP pods." The upgrade will look fine and the tools will not be there.
Now the turn, which comes from the APIs.io catalog looking at Apigee's own record. The catalog holds Apigee's management surface in depth. The provider page lists 45 API pages. The post's design rests on three of them: the API Products API, where tool entitlements and quotas live; the API Proxies API, which MCP Discovery Proxies are built from; and the API Specs API, which holds the OpenAPI they start from. The agentic access profile maps 179 operations, 101 of them acting. The Kin Score is 66.9, in the exemplar band, with discoverability at 85.7 and developer ergonomics at 82.1, against contract governance at 18.2. The Agent Readiness score is 29.8, agent-ready.
But the MCP server dimension is unlit. That is the record of a product whose release is about turning every customer's API into an MCP server. If you used that record to judge Apigee for your agent plans, you would conclude the opposite of what the product does.
The likely reason, the catalog says, is one it has found three times this month, with AWS, Kong and Atlassian. The probe looks for a server at the company's own address, and Apigee's MCP endpoints live at each customer's. The catalog has filed this against itself: it needs a way to credit a company for the MCP servers it runs for others.
What you take away is practical. If your runtime cannot move, Apigee hybrid 1.17.0 now keeps MCP traffic inside your cluster and asks for no inbound path from Google, according to Google's own post. Check your chart upgrade order before you rely on it. And when you read a catalog score for any gateway vendor, remember that a missing MCP server may mean the servers are running in customers' clusters, not that the vendor has none.
Read the original: https://apis.io/2026/10/26/apigee-runs-mcp-inside-your-own-cluster-and-its-record-has-no-mcp-server/