OASIS Advanced Message Queuing Protocol (AMQP) TC

Amazon Web Services are pleased to contribute a draft of an MCP binding spec for AMQP to the AMQP Technical Committee (TC) so that the TC may use this as a basis to develop OASIS work products.

Cheers,
Stefan

Hi All,

The MCP project published a new specification revision, 2026-07-28, on July 28. This changes some assumptions our working-draft binding was built on. The direction is generally favorable for us. MCP has moved toward a stateless, header-routed model that fits AMQP better than the version we drafted against. A few sections of the draft need rework before our next review. Highlights and the specific edits are called out below, 

What changed in the spec:

• MCP is now stateless request/response. The initialize/initialized handshake has been retired and the Mcp-Session-Id header is removed. Every request self-describes its protocol version, client identity, and capabilities, so any request can land on any server instance. This is a natural fit for brokered and routed messaging.
• Server-initiated calls are gone. Sampling, elicitation, and roots were the reason MCP was bidirectional. They have been replaced by Multi Round-Trip Requests: the server returns input_required, the client retries with answers. MCP is now effectively client-initiated request/reply.
• Header-based routing is now canonical. Streamable HTTP mandates Mcp-Method, Mcp-Name, and MCP-Protocol-Version headers so gateways route and meter without parsing the body. This is the advisory hint approach our draft proposed for AMQP properties, now blessed by the core spec.
• Legacy HTTP+SSE transport is deprecated on a twelve-month offramp, alongside a new formal deprecation policy and an extensions framework.

What we need to change in the draft:

• #6 Session Lifecycle - rework for the stateless per-request model. The initialize/initialized ride-along no longer exists.
• mcp-session-id in application-properties (#4, #5, #6, Appendix A) - remove. The source header is gone. Multi-client demux on a shared queue (#5) needs a new basis: per-request reply-to correlation or an application-level handle.
• Bidirectional link-pair rationale (#3, #5) - simplify. With no server-initiated calls, the design collapses toward classic AMQP request/reply. The reply link stays for responses to a dynamic reply-to.
• Advisory properties (#4) - align to the canonical triple: Mcp-Method, Mcp-Name, and MCP-Protocol-Version. This also settles our open question on identifier placement: mirror the canonical routing headers into application-properties as endpoint- and gateway-read hints.
• Normative reference (#1.1) - bump 2025-11-25 to 2026-07-28.

The revision makes the binding simpler and better-justified, but it is not a light edit. The decision axis moved from "how do we carry a stateful session over AMQP" to "how do we carry stateless request/reply," and AMQP already answers the second question. I have submitted a revised draft PR for this.