Model Context Protocol specification 2026-07-28, Subscriptions

Publisher

Model Context Protocol project

URL

https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/subscriptions

Published

2026-07-28

Updated

unknown

Accessed

2026-09-05

HTTP status

200

License

MIT license; permitted under the specification license

Source notes citing this source

• The Subscriptions page states in prose that the server MUST send notifications/subscriptions/acknowledged as the first message for a subscription and MUST NOT send any notification on that subscription before it. in context
• The MCP 2026-07-28 Subscriptions page, as served, contains four json code blocks and one table and contains no mermaid block and no image. in context
• In MCP revision 2026-07-28 a client cancels a subscriptions/listen subscription by closing the SSE stream on Streamable HTTP, or by sending notifications/cancelled referencing the subscriptions/listen request ID on stdio. in context
• In MCP revision 2026-07-28 the server MUST send notifications/subscriptions/acknowledged before any other notification on a subscription; on stdio this ordering is defined per subscription ID rather than per channel, so messages belonging to other subscriptions MAY be interleaved before it. in context
• On stdio in MCP revision 2026-07-28, if the connection is terminated and then re-established the client MUST re-send subscriptions/listen to re-establish its subscriptions, because the server holds no subscription state across reconnections. in context
• The MCP 2026-07-28 Subscriptions page says that a server ending a subscription on its own initiative SHOULD send a successful subscriptions/listen response (resultType complete) before closing the stream, and describes no server-sent notifications/cancelled. disputed in context
• A client whose requested toolsListChanged filter is silently dropped from the subscription acknowledgment receives no notification, so the caching page's invalidation scenario never applies to it even though the server advertised listChanged. inferred in context
• The subscriptions listen stream replaces the former resources subscribe request, so resource subscriptions and tool list notifications now share one filter-based mechanism rather than running in parallel. in context
• The subscriptions page states that a server MUST NOT send notification types the client has not explicitly requested. in context
• A subscription filter type the server does not support is omitted from the acknowledgment rather than raising an error and the client side check that would catch the omission is a SHOULD. in context
• The Model Context Protocol defines a subscriptions listen stream that a client opens to receive server notifications. in context
• The subscriptions page states a client obligation for the standard input and output transport: a client MUST demultiplex incoming notifications by subscription identifier. in context
• The specification does not state what becomes of a notifiable event that occurs while no client holds a matching subscription; neither the subscriptions page the streamable transport page the tools page nor the changelog addresses retention queueing or replay. in context

Cite this source record

APA

WarmTransfer. (2026, July 28). Model Context Protocol specification 2026-07-28, Subscriptions. WarmTransfer. https://warmtransfer.net/knowledge/sources/mcp-spec-2026-07-28-subscriptions

BibTeX

@misc{warmtransfer-mcp-spec-2026-07-28-subscriptions,
  title  = {Model Context Protocol specification 2026-07-28, Subscriptions},
  author = {{WarmTransfer}},
  year   = {2026},
  url    = {https://warmtransfer.net/knowledge/sources/mcp-spec-2026-07-28-subscriptions},
  note   = {Model Context Protocol project, accessed 2026-09-05}
}