When an edge vendor says it can classify Model Context Protocol sessions crossing its network, the first question is how. If the detection method is not published, the capability is an assertion, and policy written against an assertion fails quietly. What security teams can act on is firm: MCP runs on JSON-RPC 2.0 over two transports, only one of which ever crosses a network boundary a proxy can see. That split, not the marketing, is what should shape your filter policy.
What would MCP classification at the edge actually require?
Any claim to identify and classify MCP sessions traversing an edge should be treated as asserted rather than demonstrated until the classification method is published. That distinction matters because the depth of detection determines the depth of policy you can write. If classification works at the JSON-RPC payload level, you can filter on individual tool names. If it works on TLS fingerprints, ports, or hostname heuristics, you can only filter on destinations.
The structural position for such a claim exists. Cloudflare operates primarily as a reverse proxy sitting between visitors and origin hosts, and it states its services run in 335+ cities within 50ms of 95% of the world’s population. Per W3Techs figures cited by Wikipedia, roughly 21.3% of all websites used Cloudflare as of January 2026, and the company says it powers 45% of the Fortune 500, though that figure is a vendor self-description. An intermediary with that footprint sees a large share of enterprise egress, which is what makes a detection claim plausible in principle.
Context for how hard the company is leaning into agents: Cloudflare’s homepage now leads with the line “Build for the agent era”. The repositioning is corporate strategy, not a side project.
Where does MCP live on the wire?
MCP defines two main transports, and only one of them crosses a boundary an edge proxy can filter. Per Google’s MCP guide, the protocol uses stdio, which suits local resources with fast synchronous message exchange, and server-sent events (SSE), which suits remote resources with real-time streaming.
A stdio MCP server is a local child process. The client spawns it, pipes JSON-RPC messages over stdin and stdout, and nothing touches the network. Your gateway, your CASB, your Cloudflare tunnel: none of them see a single byte of that session. A remote MCP server, by contrast, is an HTTPS endpoint. The client connects, the traffic crosses your egress path, and an inline proxy gets a chance to inspect it.
This is the gap detection claims gloss over. When a vendor says it “detects MCP traffic,” it can only mean the remote subset. Local stdio servers are invisible to network-layer detection by design, not by implementation shortfall.
| Surface | Transport | Crosses a filterable boundary? | What an edge proxy sees | Where policy must live |
|---|---|---|---|---|
| Local tool server (filesystem, git, local DB) | stdio | No | Nothing | Endpoint control, agent config |
| Remote vetted server (internal or SaaS) | HTTPS/SSE | Yes | Host, TLS metadata, possibly JSON-RPC payloads | Edge proxy, allowlist |
| Remote unvetted server (random public MCP host) | HTTPS/SSE | Yes | Same as above | Edge egress rules, block by default |
The table is the whole story. One column of it is empty, and that column is where a large share of real developer MCP usage lives.
Why is MCP classifiable at all?
MCP is classifiable at the payload level, in principle, because every session speaks the same protocol: JSON-RPC 2.0. Per the protocol’s reference documentation, clients and servers exchange structured messages with predictable method names (tools/list, tools/call, resources/read) and predictable field shapes. A proxy that terminates TLS and parses the body can, in theory, enumerate which tools a client asked about and which ones it invoked, for any conforming server, without per-vendor parsers.
That uniformity is a direct consequence of the protocol’s governance and adoption path. Anthropic introduced MCP in November 2024 as an open standard for connecting AI systems to external tools and data sources, then in December 2025 donated it to the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI. The official GitHub organization maintains the open reference implementations. When one protocol wins, one parser suffices, which is exactly the property an edge vendor would build on.
Contrast this with the pre-MCP world. Tool access meant bespoke REST integrations: different auth headers, different URL schemes, different payload shapes per vendor. Classifying “the agent is calling the delete endpoint” required a rule per API. With MCP, the delete call is a tools/call with a tool name in a JSON field, identical in structure whether the server is GitHub’s, an internal one, or a stranger’s.
Whether any vendor has actually shipped payload parsing is unknown. JSON-RPC uniformity makes tool-name filtering possible at a proxy. It does not make it shipped.
What should an MCP filter policy actually gate?
A workable MCP filter policy has three layers: server endpoint allowlists, egress blocks toward unvetted servers, and tool-name matching where payload inspection genuinely exists. Order matters, because the layers degrade gracefully. If the deepest layer turns out to be unavailable, the outer two still stand.
Layer 1: server endpoint allowlists. Enumerate the remote MCP servers your organization has vetted, by hostname, and permit MCP sessions only to those. Everything else that pattern-matches to MCP gets blocked or quarantined. This works even with shallow detection: if the proxy can only identify “this is an MCP-ish session to host X,” host allowlisting is still fully enforceable. This is the layer to trust first because it depends on the least vendor magic.
Layer 2: egress control toward unvetted servers. The adoption curve makes this urgent. In just over a year, MCP moved from one vendor’s announcement to governance by a Linux Foundation-directed fund co-founded by Anthropic, Block, and OpenAI. The population of public MCP servers your developers can paste into a config file far exceeds what any security team has reviewed, and it grows with every quickstart. Default-deny on unrecognized MCP egress is the only posture that scales.
Layer 3: tool-name patterns inside JSON-RPC payloads. Where inspection depth exists, gate the dangerous verbs. An allowlisted server can still expose tools you do not want agents calling unsupervised: anything matching delete, execute, transfer, deploy, or raw shell and SQL entry points. JSON-RPC 2.0’s fixed structure makes tool names cheap to match once you can read the body. The caveat from the previous section applies in full: this layer is only as real as the payload inspection underneath it, and that inspection is, today, a vendor assertion.
What does policy compression actually change?
MCP collapses hundreds of per-endpoint API rules into a single allowlist, and that compression moves the vetting authority from the network team to whoever owns the list. Before protocol convergence, egress policy for agent tool use looked like firewall archaeology: one rule set for the GitHub API, another for Slack, another for Jira, each with its own auth model and its own idea of what “read-only” means. When the agent reaches all of those through MCP servers speaking one protocol, the policy surface shrinks to one question: which MCP servers are on the list, and who approved them.
The second-order effect is organizational. The network team used to be the de facto gatekeeper of tool access because they owned the egress rules. Under a compressed MCP policy, the effective permission grant happens when someone adds a server to the allowlist. If that someone is a platform engineer responding to a ticket, tool vetting has quietly become a config edit. If it is a named owner with a review process, it is an access-control decision. The protocol does not choose between those two outcomes. Your process does.
This is also where Cloudflare’s market position cuts both ways. With 21.3% of websites behind it per W3Techs figures and a self-reported 45% of the Fortune 500 as customers, a working MCP classifier at that edge would give a lot of enterprises their first MCP visibility for free, as a byproduct of a proxy they already run. That convenience is precisely why the allowlist ownership question matters: the easier the network layer makes detection look, the easier it is to mistake detection for governance.
What can edge detection never see?
Edge detection can never see stdio MCP servers, and stdio is the default transport for local tools, which are the tools with the most direct access to the machine that matters. A developer running an agent with a local filesystem server, a shell server, or a database server over stdio generates zero network traffic for those tool calls. Per Google’s transport guide, stdio exists precisely for local resources where fast synchronous exchange matters. It is not a legacy mode; it is the recommended pattern for a large class of servers.
The consequences are concrete. Your edge logs can show a clean bill of health, every MCP session going to allowlisted remote servers, while an agent on a developer laptop invokes a local tool that reads ~/.ssh or writes to a production kubeconfig. The network layer is not lying to you. It is answering a different question than the one you asked.
The ecosystem momentum behind MCP makes this blind spot bigger over time, not smaller. A protocol co-governed by Anthropic, Block, and OpenAI under a Linux Foundation-directed fund is past the niche stage, and the official docs keep lowering the barrier to wiring a local server into a client. Each new developer who adopts the path of least resistance, a local stdio server from a quickstart, adds coverage to the column of the table that no edge product will ever fill.
What should an MCP server onboarding checklist look like?
Treat every MCP server onboarding as an access-control decision with a named approver, and gate it before the server reaches either the allowlist or a developer’s config. A checklist that works regardless of how any detection claim resolves:
- Identify the transport first. Remote HTTPS/SSE servers go through the edge review path. Local stdio servers go through endpoint review. Never let a server skip review because it “doesn’t touch the network.”
- Enumerate the tools the server exposes. Request
tools/listoutput before approval. A server exposing shell execution or credential-file reads is a different risk class than one exposing search. - Assign a named owner to the allowlist entry. Every entry has an approver and a review date. An allowlist without owners is a list of accidents.
- Default-deny egress to unvetted MCP endpoints. New remote servers are blocked until onboarded, not permitted until noticed.
- Apply tool-name filtering where it verifiably exists. Test the control with a known
tools/callbefore relying on it. Vendor claims about payload inspection should survive one synthetic test transaction. - Audit the local path separately. Client configs, spawned processes, and local server binaries belong to endpoint tooling, reviewed on the same cadence as the edge allowlist.
The verdict is the same one the transport table dictated from the start. Gate MCP at onboarding, not at the packet. Allowlist vetted remote servers, block egress toward unvetted ones, filter tool names only where inspection depth is demonstrated rather than asserted, and hand stdio to endpoint control because the network structurally cannot help you there. Whoever owns the allowlist owns tool vetting; make sure that person knows it.
The strongest limitation bears repeating plainly. Payload-level MCP detection at an edge is, today, a vendor assertion with no published method behind it. If classification turns out to be fingerprint heuristics, tool-name filtering is not available and layer 3 of the policy is fiction until proven otherwise. And even in the best case, where payload inspection is real and accurate, “MCP visibility” at the edge excludes every stdio session on every host, which may be the larger share of actual enterprise usage. Detection claims are a reason to write the policy. They are not a reason to believe the policy is already enforced.
Frequently Asked Questions
Does Cloudflare’s MCP detection cover local stdio servers?
No. Stdio servers run as local child processes communicating via stdin/stdout, so they generate zero network traffic. Edge proxies like Cloudflare cannot inspect these sessions, meaning local tool usage remains invisible to network-layer controls and must be managed via endpoint security or MDM policies.
How does MCP filtering differ from traditional API egress rules?
Traditional API filtering requires unique rules for each vendor’s distinct auth headers and payload structures. MCP standardizes on JSON-RPC 2.0, allowing a single allowlist to cover multiple tools. This compresses hundreds of per-endpoint firewall rules into one policy, shifting the vetting burden from network teams to the owners of the MCP allowlist.
What is the primary risk if payload-level inspection is not actually implemented?
If detection relies on TLS fingerprints or hostname heuristics rather than JSON-RPC parsing, tool-name filtering becomes impossible. Teams might believe they are blocking dangerous verbs like ‘delete’ or ‘execute’ when the proxy is only blocking entire server endpoints, leaving specific high-risk tools on allowlisted servers unmonitored.
Who should own the MCP server allowlist in an enterprise?
The allowlist owner becomes the de facto tool-vetting authority. If a platform engineer adds servers via config edits, vetting is informal. If a named security owner with a review process manages the list, onboarding becomes an access-control decision. Assigning a specific approver with a review date prevents the allowlist from becoming a collection of unvetted accidents.
