`mcp://` channel: no schematized carrier for the verbatim-MCP traffic the spec describes (`mcpMethodCall`/`mcpNotification` named only in prose)

Summary

The mcp:// channel is specified in prose, and AhpMcpUiHostCapabilities advertises which MCP methods/notifications a host serves on it — but there is no schematized carrier for the traffic itself. The names mcpMethodCall and mcpNotification appear only inside capability descriptions; they are not defined as commands, notifications, or types in schema/ or the ahp-types crate. As a result the channel can't be implemented interoperably: a host and a client have no agreed on-the-wire message shape to exchange.

Referenced vs. defined

Referenced (prose only):

• docs/specification/mcp-channel.md — "The channel speaks MCP verbatim … each request, response, and notification carries a top-level channel: URI."
• AhpMcpUiHostCapabilities field docs (schema/state.schema.json, schema/notifications.schema.json, clients/rust/crates/ahp-types/src/state.rs) — e.g. "host serves sampling/createMessage via mcpMethodCall", "forwards them via mcpNotification", "host proxies tools/list and tools/call."

Defined: nothing. Grepping mcpMethodCall / mcpNotification across schema/ and clients/rust/crates/ahp-types/ returns only those description strings — no command, notification, or struct.

Contrast: every other channel's traffic is schematized — terminal, chat, session, telemetry, etc. each have concrete commands/notifications in schema/commands.schema.json / schema/notifications.schema.json. The mcp:// channel — uniquely carrying verbatim MCP JSON-RPC rather than AHP-defined methods — has none.

The modeling tension to resolve

CommandParamsBase (schema/commands.schema.json) routes by params.channel, with the stated invariant: "route every incoming message … by inspecting params.channel without needing to know the per-method param shape." But mcp-channel.md requires a top-level channel (sibling of method/params) precisely because the body is verbatim MCP — and verbatim MCP params ({ name, arguments } for tools/call, etc.) can't carry an AHP params.channel without ceasing to be verbatim.

So the two descriptions don't compose:

• the base-command routing model puts channel inside params;
• the mcp-channel model puts channel at the message top level and keeps params verbatim-MCP.

Neither a top-level channel envelope field nor a verbatim-MCP carrier is present in the schema or the types.

What would close this

Pick and specify one framing, then land schema + types + a reference page so it's implementable:

1. A pair of carrier messages (the mcpMethodCall / mcpNotification the docs already name): an AHP command whose params are { channel: Uri, message: <verbatim MCP JSON-RPC request> }, and a notification { channel: Uri, message: <verbatim MCP JSON-RPC request | response | notification> } — with request/response correlation rules (does the MCP id ride inside message, or is the AHP request id authoritative?) and the -32601 Method not found rejection for un-advertised methods. or
2. A transport-level allowance that a raw MCP JSON-RPC message may ride the AHP transport with a top-level channel set to the mcp:// URI — in which case the params.channel routing invariant in CommandParamsBase needs an explicit carve-out, and the framing/correlation for requests vs. responses vs. notifications needs to be written down.

Either way, two things that mcp-channel.md leaves open need specifying: how a response is delivered (the spec says the host serves the channel and the client originates traffic, but response framing isn't given), and how server→client forwarded notifications/* are framed.

Why it matters

AhpMcpUiHostCapabilities is a host promise that these methods are served on the channel ("An agent host MUST only advertise a capability when it actually accepts the corresponding methods/notifications on the mcp:// channel"). A host can't honor — or even honestly advertise — those capabilities until the carrier is defined. Today the state surface (the mcpApp.capabilities advertisement and the channel URI field) is fully specified, but the channel it points at has no implementable message contract.

Start by reading docs/specification/mcp-channel.md, then compare its framing with schema/commands.schema.json, schema/notifications.schema.json, and the AhpMcpUiHostCapabilities definitions in schema/state.schema.json and clients/rust/crates/ahp-types/src/state.rs. Resolve the carrier and correlation model, then ensure the chosen framing is represented in the schema, Rust types, and a reference page so requests, responses, and forwarded notifications are implementable.