Detect MCP requests that omit the optional transport headers

[akshat-trigunait]

The bug

MarketplaceAbilitiesTracking::is_mcp_request() recognised an MCP call by exactly two headers:

$is_mcp = ( ! empty( $_SERVER['HTTP_MCP_SESSION_ID'] ) || ! empty( $_SERVER['HTTP_MCP_PROTOCOL_VERSION'] ) );

Both are optional. Mcp-Session-Id exists only if the server issued one at initialize; MCP-Protocol-Version only entered the spec in the 2025-06-18 revision, and mcp-adapter's own validator documents that "A missing header is accepted".

ChatGPT's client sends neither. Captured from a real request to an Easy MCP AI endpoint:

"HTTP_ACCEPT":      "application/json, text/event-stream"
"HTTP_USER_AGENT":  "openai-mcp/1.0.0"
"HTTP_X_ORIGINAL_URL": "/wp-json/easy-mcp-ai/v1/mcp"
"HTTP_AUTHORIZATION": "Bearer wpmcp_oat_…"

It uses X-OpenAI-Session in place of Mcp-Session-Id. So record() returned early, the ability executed normally, and no event was ever emitted — silently. Gemini, which does send a header, worked fine, which is what made this look client-specific rather than like a detection bug.

The fix

Detection becomes a union of signals:

Signal	Why
Mcp-Session-Id / MCP-Protocol-Version	Authoritative when present. Unchanged.
Accept: text/event-stream	The streamable-HTTP transport requires clients to accept both application/json and text/event-stream on POST — so it is present exactly where the optional headers are not.
Path resolves to an MCP endpoint	Covers pretty REST permalinks, the ?rest_route= fallback, and X-Original-URL for proxies that rewrite REQUEST_URI (group.one's Varnish tier does).

It still fails closed. This is only consulted from wp_after_execute_ability, so the request is already known to be an ability execution; the only non-MCP callers there are our admin-ajax UI and the plain REST abilities route, and neither sends text/event-stream nor posts to an /mcp path. The onecom_abilities_is_mcp_request filter still overrides everything.

Verified

Exercised against the captured headers plus the paths that must not be treated as MCP:

ChatGPT (openai-mcp/1.0.0, from the log)   => MCP  ✓
Gemini-style (session header)              => MCP  ✓
Client sending only protocol header        => MCP  ✓
MCP via ?rest_route= (no pretty links)     => MCP  ✓
MCP via mcp-adapter pretty route           => MCP  ✓
--- negatives ---
Our admin UI (admin-ajax)                  => not MCP
Our marketplace REST route                 => not MCP
Plain admin page load                      => not MCP
WP-CLI / no headers at all                 => not MCP

Companion MR

Onecom_Abilities_Tracking in the plugin repo (wp-in/one.com-wp-plugin-onecom-themes-plugins) has the byte-identical check and the same bug — in fact the ability in the captured log (onecom/create-post) is one of its abilities, so this PR alone does not fix the reported case. A matching MR is raised there.

Notes

• No version bump, so merging will not publish. A bump to 2.0.8-beta.3 (in both composer.json and Marketplace::VERSION) is needed to ship it.
• CHANGELOG.md will conflict trivially with Capitalise the MCP ability Mixpanel event name #129 depending on merge order — both add to ## [Unreleased].
• CI shows the pre-existing failures already red on master (missing frontend/package-lock.json; pre-existing PHPCS violations), unrelated to this change.