Cloudflare Introduces Detection and Control Mechanisms for Model Context Protocol Traffic

Cloudflare Introduces Detection and Control Mechanisms for Model Context Protocol Traffic Cloudflare has introduced capabilities across Zero Trust Gateway, MCP Portals, and the Agents SDK to detect and secure Model Context Protocol (MCP) traffic. As AI agents rapidly execute tools over standard HTTPS connections without distinctive hostnames or paths, Cloudflare leverages protocol headers, gateway traffic sources, and server-side controls to mitigate shadow MCP and portal bypass risks. Traditional access controls fail against AI agents that execute tools at machine speed without human judgment, risking rapid compounding of errors. MCP traffic resembles normal HTTPS API calls, meaning standard URL paths or hostnames do not reliably expose MCP transactions. Control and observation can be implemented across client hooks, secure web gateways via TLS inspection, and server-side tool handlers. Cloudflare Zero Trust Gateway introduces an experimental selector based on protocol headers to identify MCP traffic and block direct, unproxied connections. The Agents SDK v0.20.0 implements the stateless MCP 2026-07-28 standard, enabling metadata inspection via headers without parsing request bodies. Agent Execution Risks and MCP Architecture Unlike human users who operate with natural speed and discretion, AI agents make nondeterministic tool-use decisions that can trigger thousands of automated actions before being discovered. MCP servers allow tools to discover and run actions across SaaS platforms, APIs, and internal apps via simple client harness configurations in tools like Claude Code, Cursor, and VS Code. MCP calls exist in three states: a client decision with arguments, a network HTTP request containing a JSON-RPC payload, and a server-side execution of the tool handler. Payloads carry an id, method, and sensitive parameters such as source code, queries, customer records, or infrastructure commands, while lacking guaranteed hostnames or dedicated paths like '/mcp'. Observation Points and Cloudflare WriteGuard Security teams can monitor or enforce MCP traffic at three layers: client hooks, secure web gateways, and server-side handlers. Client hooks intercept calls prior to serialization without requiring TLS decryption, covering local stdio servers but posing cross-organization standardization hurdles. Secure web gateways with TLS decryption inspect protocol headers, run DLP checks on JSON-RPC contents, and block unapproved direct connections, though they cannot see off-network or local stdio calls. Server-side handlers offer the highest context by validating schemas and enforcing caller authorization before execution. Cloudflare's WriteGuard enforces controls at the server tier, setting tool risk levels, emitting audit events for writes, and blocking critical actions prior to execution. Protocol Specifications and Gateway Detection Searching logs purely for 'mcp' hostnames or paths like '/mcp' and '/sse' causes false positives and misses valid endpoints hosted on generic API paths. The MCP 2025-11-25 specification requires Streamable HTTP clients to supply the 'MCP-Protocol-Version' header on requests post-initialization, while the 2026-07-28 specification mandates it on all POST requests. Cloudflare Zero Trust Gateway leverages TLS inspection to expose the 'experimental.is_mcp == true' selector whenever this header appears. However, this detection cannot view traffic on local stdio connections, uninspected connections, or requests from older protocols lacking the header. The newer stateless 2026-07-28 specification drops the initialize handshake and includes 'Mcp-Method' and 'Mcp-Name' headers, letting network proxies inspect operations without opening HTTP request bodies. Defending Against Shadow MCP and Portal Bypass Security policies address two primary deployment risks: Shadow MCP, where personnel connect directly to unvetted external servers, and Portal bypass, where users circumvent an approved MCP Portal by routing directly to the upstream server. Cloudflare Gateway policies leverage an 'mcp_portal' Traffic Source tag to differentiate portal-routed connections from raw connections, allowing administrators to block direct employee calls to upstream targets. Because the 2026-07-28 specification deprecated dynamic client registration (RFC 7591) in favor of fixed credentials, MCP Portals now support pre-registered OAuth clients, storing client secrets strictly for catalog updates while users authorize individual upstream access. Currently, MCP Portals require public network reachability, with private DNS and network routing support under development. SDK Implementation and Forward Roadmap Cloudflare Agents SDK v0.20.0 adds client and server support for the MCP 2026-07-28 specification. SDK clients probe for stateless support via 'server/discover' and fall back to legacy initialize handshakes when necessary, while the server-side 'createMcpHandler' hosts tools, prompts, resources, and elicitation on Workers without needing Durable Objects or persistent transport sessions. Cloudflare advises organizations to inspect Gateway MCP traffic, map targets to approved directories, and route destinations through MCP Portals. Planned updates include granular policies on specific tool usage and new reporting on all recognized and unrecognized MCP servers across an organization.

Cloudflare详解模型上下文协议（MCP）流量检测与安全防护方案 针对AI智能体非确定性决策与高频工具调用的安全风险，Cloudflare发布了检测和保护模型上下文协议（MCP）流量的技术方案，通过协议演进支持、网关策略和MCP Portal代理管控“影子MCP”与绕过行为。 MCP流量因缺乏固定域名和路径标识而类似普通HTTPS API，增加了网络侧检测难度。 安全团队可在客户端Hook、安全Web网关及服务端Handler三个层面实施观测与权限控制。 MCP新版规范引入专用HTTP请求头，使网关层可在TLS解密下直接识别MCP通信与调用方法。 Cloudflare Zero Trust支持基于协议头识别MCP流量，并利用Traffic Source选择器强制流量通过MCP Portal。 AI智能体调用与MCP检测难点 传统权限模型假定操作者具备人类的判断力和执行速度，而AI智能体能够在无停顿的情况下反复调用工具，可能将单次错误决策迅速扩大为数千次错误操作。通过模型上下文协议（MCP），智能体能够接入第三方SaaS、内部系统与API。然而，MCP并未强制绑定特定主机名或URL路径（例如'/mcp'），且载荷被封装在JSON-RPC消息内，直接连接在网络层上与常规HTTPS API极其相似，单凭日志搜索域名或路径极易产生误报或漏报。 三层防护点与WriteGuard服务端控制 针对MCP工具调用，安全防御可在三个位置切入：客户端Hook可免解密提取服务器目标与参数，但面临跨客户端标准化落地难的问题；安全Web网关通过TLS解密支持DLP扫描并阻断未授权直连，但无法覆盖本地stdio调用；MCP服务端则拥有最完备的上下文，能在执行前验证参数Schema并实施限流。Cloudflare通过WriteGuard在服务端设定风险分级和启停状态，在执行处理器动作前拦截关键操作。 协议演进与网关检测机制 早期MCP版本缺乏显著头部特征，而MCP 2025-11-25与2026-07-28规范逐步将'MCP-Protocol-Version'作为强制HTTP请求头。无状态的2026-07-28规范移除了初始化握手，并新增'Mcp-Method'和'Mcp-Name'请求头，使网络基础设施无需深入解析载荷内容即可识别具体操作。Cloudflare Zero Trust Gateway依托TLS解密，引入实验性选择器'experimental.is_mcp == true'匹配相关头部以侦测MCP流量，但该功能目前无法覆盖本地stdio及未开启TLS解密的流量。 应对影子MCP与MCP Portal演进 针对员工擅自连接未经批准服务器的“影子MCP”以及绕过审批网关直接访问后端的“Portal绕过”问题，Cloudflare Gateway新增流量源选择器。经由MCP Portal转发的流量带有'mcp_portal'标签，管理员可配置基准规则阻断受控设备的直连请求。针对MCP 2026-07-28规范弃用动态客户端注册的变化，Portal支持手动配置预注册OAuth凭据，用户独立完成上游数据授权。此外，Cloudflare Agents SDK v0.20.0已双向支持最新无状态协议，私网MCP路由和细粒度工具控制功能也正在推进中。

Most companies designed their resource permissions with a human user in mind. A senior engineer may be able to deploy to production, query a sensitive database, or revoke another user's access. Those privileges come with risk, but that risk has traditionally been bounded by two assumptions: the engineer will use human judgment, and the engineer can only act at human speed. An engineer who sees an unexpected result will usually stop and reconsider their actions. Any human being can only click, type, and review *so much* in a single day. The introduction of AI agents changes both thresholds. Their decisions are nondeterministic, and they can take the same action (or invoke the same tool) indefinitely, without getting tired or stopping for lunch. A plausible — but incorrect — decision can become thousands of incorrect actions before a human notices. Today, we're announcing new [Cloudflare One](https://developers.cloudflare.com/cloudflare-one/) capabilities to identify inspected MCP traffic, show which users and servers are generating it, and control direct connections on managed network paths. Combined with [MCP Server Portals](https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/), these controls help administrators see whether agents are using an approved path, or somehow bypassing it. [Model Context Protocol](https://www.cloudflare.com/learning/ai/what-is-model-context-protocol-mcp/) (MCP) servers give agents a common way to discover and invoke tools backed by third-party SaaS products, internal applications, and APIs. The underlying permissions are likely familiar; what changes is *who* makes each decision, and how quickly a bad decision can spread. Connecting an agent to one of these tools can take a single line of configuration. An employee can point Claude Code, Codex, Cursor, OpenCode, VS Code, or any AI harness at an MCP server without checking whether it is approved. The resulting traffic has no obvious shape. The Model Context Protocol does not use a guaranteed hostname or require /mcp in the path, so a direct connection can look like any other HTTPS API call. To explain how these controls fit together, we'll start with the anatomy of a tool call and the information it exposes. We'll then compare the three places a security team can act: inside the client, on the network, and at the MCP server. From there, we'll show how [Cloudflare Gateway](https://developers.cloudflare.com/cloudflare-one/traffic-policies/) uses protocol signals to find shadow MCP traffic and enforce MCP Portal-only access to trusted MCP servers. The same MCP tool call has three forms as it moves through a system. Inside the client it is a decision to invoke a tool with a set of arguments. On the network it is an HTTP transaction carrying a [JSON-RPC](https://www.jsonrpc.org/specification) message. At the server it becomes a call to a tool handler that may read data, change state, or complete some other action. Consider an agent that wants to know the weather in Austin. A remote MCP request can look like this: There are several useful signals packed into this request. The hostname and path identify the destination. The authorization header carries the credential used to authenticate the caller when the server requires one. The header: `MCP-Protocol-Version` identifies the protocol version, while `Mcp-Method` and `Mcp-Name` expose the operation and tool in the new stateless protocol. The JSON-RPC envelope repeats the method, gives the request an `id` that the client can match with a response, and carries the tool arguments in `params`. The arguments are the most sensitive part. They can contain a search query, source code, customer data, or instructions for an action such as creating a ticket or changing infrastructure. The tool name says what the agent intends to call; the arguments say what data it will send and what action it wants the server to perform. If the call succeeds, the server returns a JSON-RPC response with the same ID and the tool result. That response may also contain sensitive data. Request inspection can stop an unsafe action before execution, while response inspection and logging show what the tool returned to the agent. The request gives security teams three places to observe or control the call. A [client hook](https://code.claude.com/docs/en/hooks) can run after the model selects a tool but before the client serializes the request. From there, it can see the destination server, tool name, and arguments *without* decrypting network traffic. This is the earliest stage in the request chain to exercise control. The client can deny a server that is not on an allowlist, ask the user to confirm a sensitive operation, or remove data from the arguments before it leaves the device. It can also cover local `stdio` (aka local) MCP servers, which never generate network traffic. This presents a standardization challenge. In order for a security team to benefit from this, they would need to reproduce their controls across every client that their employees use. Client-side controls work best when the organization manages both the client and the device, but telemetry from one client is never a complete inventory of MCP use. A [secure web gateway](https://www.cloudflare.com/learning/access-management/what-is-a-secure-web-gateway/) can observe the HTTP request after it leaves the client. With [TLS decryption](https://developers.cloudflare.com/cloudflare-one/traffic-policies/http-policies/tls-decryption/), it can associate the request with a user and device, inspect the destination and protocol headers, and apply policy without depending on a particular MCP client. The network layer has the widest lens to detect remote MCP traffic on managed paths. It can identify direct connections to servers outside an approved Portal and block them before the request reaches the destination. Where [data loss prevention](https://developers.cloudflare.com/cloudflare-one/data-loss-prevention/) scanning is supported, a proxy can also examine the JSON-RPC method and arguments for sensitive data. However, proxies cannot see local `stdio` calls or off-network traffic. The server has the richest execution context. It has authenticated the caller, parsed the MCP message, resolved `get_weather` to a handler, and validated the supplied arguments against the tool's input schema. This is the last point where the request can be denied before the tool runs. An [Agents SDK](https://developers.cloudflare.com/agents/model-context-protocol/) handler or similar server middleware can authorize the caller for the specific tool, apply rate limits, inspect arguments, and record the outcome. A server should perform these checks before invoking the handler, especially for tools that write data or trigger external actions. Logging only after execution can explain what happened, but it cannot prevent it. Cloudflare's [WriteGuard](https://blog.cloudflare.com/mcp-portal-writeguard-private-beta/) uses this pattern across our internal MCP servers. Each tool has a risk tier and an enabled or disabled state. WriteGuard can pass a read through unchanged, add agent attribution and an audit event to an allowed write, or block a critical action before its handler runs. Because the control lives at the server, an end user cannot bypass it by switching clients or disabling a local hook. While server-side controls only protect servers that implement them, the client and server have the best request depth. The network sees the widest set of remote connections. Used together, these controls can stop sensitive data before it leaves a device, find unmanaged MCP traffic, and deny an unauthorized operation before a tool executes. The network control point has the broadest coverage, but it first has to distinguish MCP from ordinary HTTPS traffic, a user must be running a proxy, and the MCP Server (or Portal) must verify that the proxy was used in the connection. Cloudflare One provides the networking pieces of that chain. The [Cloudflare One Client](https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/) sends traffic from managed devices through Gateway. Gateway can classify MCP requests at the protocol layer, and distinguish whether traffic is initiated from an MCP Portal, or is going outside approved controls. Administrators can then report on, or block connections that do not follow the approved path. That process starts with identifying the request reliably. Our first approach to finding MCP traffic used the GraphQL Analytics API to search [Gateway HTTP logs](https://developers.cloudflare.com/cloudflare-one/insights/logs/dashboard-logs/gateway-logs/) for hostnames containing `mcp` and common paths like `/mcp` or `/sse`. Our [MCP traffic detection tutorial](https://developers.cloudflare.com/cloudflare-one/tutorials/detect-mcp-traffic-gateway-logs/#2-build-the-mcp-detection-query) includes the query. It also explains how to create [data loss prevention patterns for MCP JSON-RPC methods](https://developers.cloudflare.com/cloudflare-one/tutorials/detect-mcp-traffic-gateway-logs/#4-create-dlp-profiles-for-mcp-json-rpc-detection) like `initialize`, `tools/call,` and `resources/read` in request bodies. Those signals are still useful for finding traffic from older clients and providing historical visibility, but they're very basic. They miss an MCP server at an ordinary URL like [https://tools.example.com/api](https://tools.example.com/api), which is not uncommon. And they can match an unrelated service that happens to use `mcp` in a hostname or path (unlikely, but we have seen it). For conforming Streamable HTTP clients, the protocol header is a more specific signal. The [MCP 2025-11-25 specification](https://modelcontextprotocol.io/specification/2025-11-25/basic/transports#protocol-version-header) says clients **MUST** include `MCP-Protocol-Version` on every HTTP request after initialization. The [MCP 2026-07-28 specification](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http#protocol-version-header) goes further and requires it on every POST request. That does not make the header a complete detector. The initial request from a legacy client may not contain it, protocol versions earlier than 2025-06-18 did not define it, and local `stdio`, custom transport, or nonconforming traffic may never carry it. Its presence is a strong positive indicator of MCP; its absence does not prove that a request is not MCP. The legacy MCP flow begins with an `initialize` request that does not contain the `MCP-Protocol-Version` HTTP header, so a network control may not classify the first request to a previously unknown endpoint from the header alone. The signal appears after the client and server finish initialization. A later tool call looks like this: The [MCP 2026-07-28 specification](https://modelcontextprotocol.io/specification/2026-07-28) changes this model considerably. The core protocol is stateless; it removes the `initialize` handshake entirely and places the protocol version and operation on each request: The `Mcp-Method` and `Mcp-Name` headers let ordinary HTTP infrastructure identify the operation without parsing the body. Load balancers can route requests, rate limiters can separate `tools/list` from `tools/call`, and security products get more information on every request. These protocol signals give Cloudflare Gateway something concrete to evaluate without relying on a list of MCP-looking URLs. Once Gateway can identify MCP traffic, you can then evaluate what a given connection *means* for your security posture. Shadow MCP is a connection to a server the organization has not approved. An employee finds the server in a repository, a product guide, or a message from a colleague and adds it directly to their MCP client. The security team has no idea which tools it exposes or what data employees send to it. Portal bypass is different: it starts with an approved server that the organization has placed in an MCP Portal, but an employee connects to its upstream URL directly and skips the Portal's Access policy, curated tool catalog, data loss prevention, and tool-level audit trail. Gateway is the primary control for shadow MCP on managed network paths; it identifies TLS-inspected MCP traffic, shows the destination and user, and can apply policy. Portal bypass needs that network control plus an origin that can reject direct requests, whether that means an Access policy, a source IP restriction, or an enterprise authorization mechanism initiated by the MCP server itself. For customers who have already adopted Cloudflare Gateway with TLS inspection, we are adding a detection heuristic that answers a simple question for every inspected request: *Is this MCP traffic?* For session-based Streamable HTTP connections, MCP clients send an `MCP-Protocol-Version` header after initialization. Gateway inspects that header on every TLS-inspected request and classifies the traffic accordingly, using detection built from patterns we observe across the millions of requests that traverse the Cloudflare network every day. The classification identifies MCP negotiation and proxying to a hostname without relying on knowing the specific host or URL ahead of time. **Starting today, all Cloudflare Zero Trust customers see indications of MCP traffic in their Gateway HTTP logs and can explicitly block or allow that traffic with a new Gateway selector:** `experimental.is_mcp == true` The selector is a boolean. If Gateway detects the `MCP-Protocol-Version` header on a TLS-inspected request, the value is `true`, and an administrator can use it in an Allow or Block policy without maintaining their own list of MCP-looking domains. Direct encrypted traffic must pass through [TLS decryption](https://developers.cloudflare.com/cloudflare-one/traffic-policies/http-policies/tls-decryption/) before Gateway can inspect these headers, and local `stdio` servers, off-network connections, [Do Not Inspect](https://developers.cloudflare.com/cloudflare-one/traffic-policies/http-policies/#do-not-inspect) traffic, and requests that never traverse Gateway remain outside this view. Today, we're introducing a dedicated MCP traffic dashboard that shows which hosts are serving MCP traffic within your network, which users are generating that traffic, and whether requests are going through your Cloudflare MCP Portals or bypassing them entirely. The dashboard shows: Administrators can filter by specific servers, users, or on-ramp types, and navigate directly to Gateway HTTP logs filtered by the relevant host or user for deeper investigation. MCP discovery turns unknown traffic into a list an administrator can investigate. When an organization approves one of those servers, it can place the server behind a Cloudflare MCP server portal. The Portal gives employees one managed endpoint and puts [Access](https://developers.cloudflare.com/cloudflare-one/access-controls/) identity, a curated tool catalog, and logging in front of the upstream server. Administrators can [route compatible upstream calls through Gateway](https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/#route-portal-traffic-through-gateway) for HTTP policy, predictable egress, and data loss prevention, either across the Portal or for an individual server. Tool activity can also be [exported through Logpush](https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/#export-logs-with-logpush). The discovery dashboard can then distinguish requests that use the Portal from direct connections to the same server. This creates a path from discovery to governance: find the server, decide whether to approve it, move approved use behind the Portal, and investigate traffic that continues to go around it. That last step matters because unapproved servers and bypasses of approved servers are different problems. We are adding Traffic Source selectors to [Gateway Network](https://developers.cloudflare.com/cloudflare-one/traffic-policies/network-policies/) and [HTTP policies](https://developers.cloudflare.com/cloudflare-one/traffic-policies/http-policies/) to give administrators the fidelity to write rules to control MCP traffic based on whether or not originated from your MCP Portals. When MCP Portal traffic routes through Gateway it carries an `mcp_portal` Traffic Source, which lets policy distinguish Portal-proxied requests from direct employee connections. A baseline enforcement rule looks like this: Any detected MCP traffic that did not arrive through a Portal gets blocked; traffic that came through the Portal is unaffected. For organizations that want to observe before enforcing, Traffic Source and MCP detection now exist in HTTP logs for traffic that has been decrypted, so you can monitor behavior for proxied traffic without the need for a policy. An approved path is only useful if it can connect to a critical mass of the servers employees actually need. Earlier MCP specifications recommended [Dynamic Client Registration](https://datatracker.ietf.org/doc/html/rfc7591), where the client registers itself with an authorization server without an OAuth application. Many common OAuth providers use a different model: they require an administrator to register an application with a fixed client ID, client secret, callback URL, and set of scopes. MCP `2026-07-28` also recently deprecated dynamic registration. To help alleviate this, MCP Portals now support pre-registered OAuth clients. An administrator can [configure manual OAuth credentials](https://developers.cloudflare.com/cloudflare-one/access-controls/ai-controls/mcp-portals/#configure-manual-oauth-credentials), register the callback URL shown in the dashboard with the upstream provider, and enter the client credentials. The Portal discovers standard OAuth metadata when available, and the administrator can provide the authorization, token, revocation, and issuer endpoints when discovery is not possible. Each user still authorizes access to their own upstream data sources, and the stored client secret is used only to fetch updated tool and prompt lists. Manual OAuth support now helps to cover the many permutations of OAuth implementations. Some providers require custom headers, personal access tokens, or an explicit client allowlist, and those are separate compatibility problems. We will continue to expand the OAuth support of MCP portals in the coming months. Public SaaS tools are only part of an enterprise's MCP catalog. Most secure information that businesses rely on is not available from the public Internet; it exists in public or private cloud infrastructure, or is hosted on-premise, and is only reachable through connectivity to private networks. Today, an MCP Portal must be able to resolve and reach an upstream server over the public Internet. This means that servers that are only available on private networks —  via [private DNS](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/cloudflared/private-dns/) or inside private IP space — can’t be reached by Portals. We are working to let MCP Portals connect to private servers through Cloudflare Gateway routing and the same Cloudflare One network that is already used for other private applications. The private server keeps its private hostname; the Portal reaches it through Cloudflare's private routing and presents its tools beside the public upstream servers; and Access policy, Portal logging, and tool controls continue to apply at the same front door. Routing Portal traffic through Gateway also stamps it with the `mcp_portal` Traffic Source, so Gateway policy can distinguish a Portal request from a direct employee connection. Private connectivity for MCP servers is in active development; keep an eye on the [Changelog](https://developers.cloudflare.com/changelog/) for more information. A few weeks ago, the MCP project published the `2026-07-28` specification, a major revision that replaces connection-scoped initialization with a stateless, per-request model. We covered the protocol changes and migration path in [The next generation of MCP](https://blog.cloudflare.com/mcp-v2). [Cloudflare Agents SDK](https://developers.cloudflare.com/agents/model-context-protocol/) v0.20.0 supports MCP `2026-07-28` as both a client and a server. For each connection the client first probes for the new stateless protocol with `server/discover`; if the server does not support it, the client continues with the legacy `initialize` handshake on the same connection. Existing `addMcpServer` calls do not need separate protocol settings or separate clients. On the server side, `createMcpHandler` can serve stateless tools, prompts, resources, and elicitation from a [Worker](https://developers.cloudflare.com/workers/) without creating a transport session or [Durable Object](https://developers.cloudflare.com/durable-objects/): The fallback matters because protocol migrations rarely happen all at once. A new client still needs to reach an existing server, and a new server still needs to handle clients that have not moved yet. The Agents SDK supports both paths while the ecosystem transitions. A workable MCP security program starts with understanding your users’ traffic profiles, MCP usage, and aligning on an approved set of tools and access methodologies. First, inspect the MCP traffic that traverses Gateway and compare its destinations with the servers your organization has approved. Move more approved servers behind MCP Portals. Then, enforce the boundary you can control. Compose Gateway policies which use the MCP detection conditions together with the Traffic Source and Destination conditions to block direct MCP connections from managed devices and sites, and restrict self-hosted upstream servers to Portal traffic where possible. We will soon be adding more granular functionality for visibility and control of MCP traffic, including control over specific tool use and new reporting on tool usage across all MCP servers within your environment — whether they are known or unknown to your security organization. Our [MCP traffic detection tutorial](https://developers.cloudflare.com/cloudflare-one/tutorials/detect-mcp-traffic-gateway-logs/) covers the hostname, path, and JSON-RPC heuristics available for Gateway logs today. We will update the documentation with the protocol selector details as the new signal reaches general availability.