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:
- 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
- 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.
Summary
The
mcp://channel is specified in prose, andAhpMcpUiHostCapabilitiesadvertises which MCP methods/notifications a host serves on it — but there is no schematized carrier for the traffic itself. The namesmcpMethodCallandmcpNotificationappear only inside capability descriptions; they are not defined as commands, notifications, or types inschema/or theahp-typescrate. 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-levelchannel: URI."AhpMcpUiHostCapabilitiesfield docs (schema/state.schema.json,schema/notifications.schema.json,clients/rust/crates/ahp-types/src/state.rs) — e.g. "host servessampling/createMessageviamcpMethodCall", "forwards them viamcpNotification", "host proxiestools/listandtools/call."Defined: nothing. Grepping
mcpMethodCall/mcpNotificationacrossschema/andclients/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. Themcp://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 byparams.channel, with the stated invariant: "route every incoming message … by inspectingparams.channelwithout needing to know the per-method param shape." Butmcp-channel.mdrequires a top-levelchannel(sibling ofmethod/params) precisely because the body is verbatim MCP — and verbatim MCP params ({ name, arguments }fortools/call, etc.) can't carry an AHPparams.channelwithout ceasing to be verbatim.So the two descriptions don't compose:
channelinsideparams;channelat the message top level and keepsparamsverbatim-MCP.Neither a top-level
channelenvelope 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:
mcpMethodCall/mcpNotificationthe 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 MCPidride insidemessage, or is the AHP request id authoritative?) and the-32601Method not found rejection for un-advertised methods. orchannelset to themcp://URI — in which case theparams.channelrouting invariant inCommandParamsBaseneeds 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
AhpMcpUiHostCapabilitiesis 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 themcp://channel"). A host can't honor — or even honestly advertise — those capabilities until the carrier is defined. Today the state surface (themcpApp.capabilitiesadvertisement and thechannelURI field) is fully specified, but the channel it points at has no implementable message contract.