# The MCP subscriptions listen stream and notification delivery

Canonical: https://warmtransfer.net/knowledge/mcp-subscriptions-listen

Last verified: 2026-09-30

The Model Context Protocol defines a subscriptions listen stream that a client opens to receive server notifications[^23]. This subscriptions listen stream replaces the former resources subscribe request, bringing resource subscriptions and tool list notifications into a single filter-based mechanism rather than running them in parallel[^17].

## How it works

The 2026-07-28 message flow diagram shows the server answering a subscriptions listen request with a notification named notifications slash subscriptions slash acknowledged[^1]. The subscriptions page states that a server MUST NOT send notification types that the client has not explicitly requested[^18]. In the 2026-07-28 revision, a server that declared the list changed capability SHOULD send the tool list changed notification to clients that have opened a subscriptions listen stream with the tools list changed filter set to true[^27]. Delivery of a tool list changed notification to a subscribed client is graded as a SHOULD rather than a MUST[^21]. 

WarmTransfer's reading of the sources is that the Tools page depicts a client re-issuing the tools list request after a notification inside an optional fragment of its message flow diagram rather than requiring it[^20]. Furthermore, we infer that Multi Round-Trip Requests do not share the long-lived connection machinery that subscriptions use[^29].

## Filter negotiation and caching

A subscription filter type that 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 graded as a SHOULD[^22]. WarmTransfer's reading of the sources is that 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[^16].

## Transport differences and reconnects

The subscriptions page states a client obligation for the standard input and output transport: a client MUST demultiplex incoming notifications by subscription identifier[^26]. 

For Streamable HTTP, resumable server-sent event streams via the Last-Event-ID header are not supported in the 2026-07-28 revision[^24]. Client reconnection after a dropped stream is graded MAY, and the specification publishes no backoff schedule, no retry cap, and no way to learn what was missed[^25]. 

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[^28]. Similarly, the Resources page does not state what becomes of a notifiable event that occurs while no client holds a matching subscription, as no queueing, retention, or replay language appears in its prose, its code samples, or its diagram[^19].

## See also

- [Model Context Protocol transports compared](https://warmtransfer.net/knowledge/mcp-transport-differences)
- [Tool schema signature monitoring and drift handling](https://warmtransfer.net/knowledge/mcp-tool-signature-drift)
- [Stateful tools in the Model Context Protocol](https://warmtransfer.net/knowledge/mcp-stateful-tools)
- [Webex published MCP servers for external AI clients](https://warmtransfer.net/knowledge/webex-mcp-servers)
- [Fidelity of the corpus text extraction pipeline](https://warmtransfer.net/knowledge/corpus-extraction-fidelity)
- [Model Context Protocol resources and the caching utility](https://warmtransfer.net/knowledge/mcp-resources-and-caching)
- [Whether a cached tool list defeats a change notification](https://warmtransfer.net/knowledge/mcp-cache-versus-notification)
- [Webex Contact Center AI agent assist and virtual agents](https://warmtransfer.net/knowledge/webex-cc-ai-features)
- [Contact center transcription and redaction](https://warmtransfer.net/knowledge/ai-transcription-accuracy)
- [Agent assist and real-time guidance](https://warmtransfer.net/knowledge/ai-agent-assist)
- [Virtual agents and conversational IVR design](https://warmtransfer.net/knowledge/ai-virtual-agents)
- [Automated call summarization and wrap-up](https://warmtransfer.net/knowledge/ai-call-summarization)
- [AI quality management and auto scoring](https://warmtransfer.net/knowledge/ai-quality-management)
- [Webex AI Agent Studio scripted and autonomous agents](https://warmtransfer.net/knowledge/webex-ai-agent-studio)
- [AI transparency technical notes](https://warmtransfer.net/knowledge/webex-ai-transparency-notes)
- [Model Context Protocol actions in Webex contact centre AI](https://warmtransfer.net/knowledge/webex-cc-mcp-tool-calling)
- [Supported languages and voices for Webex AI agents](https://warmtransfer.net/knowledge/webex-ai-agent-languages-voices)
- [Unified CCX Webex AI Agent integration](https://warmtransfer.net/knowledge/unified-ccx-webex-ai-agent)
- [Agentic apps registration approval and identity badges](https://warmtransfer.net/knowledge/webex-agentic-apps-governance)
- [Third-party model and speech vendors behind Webex contact centre AI](https://warmtransfer.net/knowledge/webex-cc-ai-model-vendors)

## Applicability

Applies to: Model Context Protocol project and Model Context Protocol specification. Sources checked 2026-09-05. In the 2026-07-28 revision, a server that declared the list changed capability SHOULD send the tool list changed notification to clients that have opened a subscriptions listen stream with the tools list changed filter set to true[^27]. Resumable server-sent event streams via the Last-Event-ID header are not supported in the 2026-07-28 revision[^24].

## What remains uncertain

Whether the corpus extractor drops diagrams entirely is not covered by the sources below. What becomes of an event with no subscriber is not covered by the sources below beyond the documented absence of queueing, retention, or replay language in the specification[^28][^19]. Whether any Webex MCP server implements subscriptions is not covered by the sources below. Whether a client can discover supported filters before subscribing is not covered by the sources below. The Discovery page new in this revision is not covered by the sources below. The specification Resources page is not covered by the sources below beyond the absence of retention, queueing, or replay rules for unheld subscriptions[^19]. The full list of subscribable event types is not covered by the sources below. How subscriptions differ between stdio and streamable HTTP is not covered by the sources below.

## Sources

[^1]: The 2026-07-28 message flow diagram shows the server answering a subscriptions listen request with a notification named notifications slash subscriptions slash acknowledged. Source: [Model Context Protocol specification 2026-07-28, Server Features: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools), Tools > Message Flow diagram. Checked 2026-09-05.
[^2]: The 2026-07-28 Resources page Message Flow section is a mermaid sequenceDiagram with no prose, and it shows subscriptions/listen (resourceSubscriptions) followed by notifications/subscriptions/acknowledged and then notifications/resources/updated. Source: [Model Context Protocol specification 2026-07-28, Resources](https://modelcontextprotocol.io/specification/2026-07-28/server/resources), Message Flow. Checked 2026-09-30.
[^3]: 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. Source: [Model Context Protocol specification 2026-07-28, Subscriptions](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/subscriptions), Acknowledgment, first paragraph. Checked 2026-09-30.
[^4]: The repository source file for the 2026-07-28 Subscriptions page was reported to contain no mermaid block and four JSON code blocks, the same inventory as the published page. Source: [docs/specification/2026-07-28/basic/patterns/subscriptions.mdx](https://github.com/modelcontextprotocol/modelcontextprotocol/blob/main/docs/specification/2026-07-28/basic/patterns/subscriptions.mdx), whole file. Checked 2026-09-30.
[^5]: 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. Source: [Model Context Protocol specification 2026-07-28, Subscriptions](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/subscriptions), whole page. Checked 2026-09-30.
[^6]: The 2026-07-28 Tools Message Flow diagram places the update steps inside an 'opt listChanged' block in which the client first sends subscriptions/listen (toolsListChanged: true) and the server sends notifications/subscriptions/acknowledged before notifications/tools/list_changed. Source: [Model Context Protocol specification 2026-07-28, Server Features: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools), Message Flow, mermaid block, 'opt listChanged' group. Checked 2026-09-30.
[^7]: On the 2026-07-28 Tools page the string notifications/subscriptions/acknowledged appears only inside the Message Flow mermaid block; the page's prose does not mention the acknowledgement. Source: [Model Context Protocol specification 2026-07-28, Server Features: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools), whole page; sole occurrence under Message Flow. Checked 2026-09-30.
[^8]: MCP revision 2026-07-28 replaced the Streamable HTTP GET endpoint and the resources/subscribe and resources/unsubscribe methods with subscriptions/listen, a single long-lived POST-response stream for opted-in server-to-client change notifications. Source: [Model Context Protocol specification 2026-07-28, Key Changes](https://modelcontextprotocol.io/specification/2026-07-28/changelog), section Major changes, item 4. Checked 2026-09-30.
[^9]: In Streamable HTTP under MCP revision 2026-07-28, long-lived change notifications are delivered on the SSE response stream of a subscriptions/listen POST, while request-scoped notifications such as notifications/progress and notifications/message flow only on the response stream of the request they relate to. Source: [Model Context Protocol specification 2026-07-28, Streamable HTTP](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http), section Receiving Messages, paragraph beginning Long-lived notification streams. Checked 2026-09-30.
[^10]: 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. Source: [Model Context Protocol specification 2026-07-28, Subscriptions](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/subscriptions), section Cancellation, first bullet. Checked 2026-09-30.
[^11]: 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. Source: [Model Context Protocol specification 2026-07-28, Subscriptions](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/subscriptions), section Acknowledgment, first paragraph. Checked 2026-09-30.
[^12]: 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. Source: [Model Context Protocol specification 2026-07-28, Subscriptions](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/subscriptions), section Cancellation, subsection Graceful Closure, paragraph beginning On stdio. Checked 2026-09-30.
[^13]: On stdio in MCP revision 2026-07-28 clients MUST correlate notifications delivered for an active subscriptions/listen request using the io.modelcontextprotocol/subscriptionId field in _meta. Source: [stdio](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/stdio.md), section Receiving Messages, numbered item 3. Checked 2026-09-30.
[^14]: The MCP 2026-07-28 Cancellation page says a server MUST send notifications/cancelled referencing a subscriptions/listen request ID when it tears down that subscription stream, and MUST NOT send notifications/cancelled for any other purpose (disputed). Source: [Cancellation - MCP specification revision 2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/cancellation), introduction, second paragraph; section Behavior Requirements item 2. Checked 2026-09-30.
[^15]: 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). Source: [Model Context Protocol specification 2026-07-28, Subscriptions](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/subscriptions), section Cancellation, second bullet, and subsection Graceful Closure. Checked 2026-09-30.
[^16]: 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). Source: [Model Context Protocol specification 2026-07-28, Subscriptions](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/subscriptions), Acknowledgment section combined with the caching page's Interaction with Notifications. Checked 2026-09-05.
[^17]: 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. Source: [Model Context Protocol specification 2026-07-28, Subscriptions](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/subscriptions), Subscriptions. Checked 2026-09-05.
[^18]: The subscriptions page states that a server MUST NOT send notification types the client has not explicitly requested. Source: [Model Context Protocol specification 2026-07-28, Subscriptions](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/subscriptions), Subscriptions. Checked 2026-09-05.
[^19]: The Resources page does not state what becomes of a notifiable event that occurs while no client holds a matching subscription; no queueing, retention or replay language appears in its prose, its code samples or its diagram. Source: [Model Context Protocol specification 2026-07-28, Resources](https://modelcontextprotocol.io/specification/2026-07-28/server/resources), whole page. Checked 2026-09-05.
[^20]: The Tools page depicts a client re-issuing the tools list request after a notification inside an optional fragment of its message flow diagram rather than requiring it (inferred). Source: [Model Context Protocol specification 2026-07-28, Server Features: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools), Tools > Message Flow diagram. Checked 2026-09-05.
[^21]: Delivery of a tool list changed notification to a subscribed client is a SHOULD rather than a MUST. Source: [Model Context Protocol specification 2026-07-28, Server Features: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools), Tools > List Changed Notification. Checked 2026-09-05.
[^22]: 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. Source: [Model Context Protocol specification 2026-07-28, Subscriptions](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/subscriptions), Subscriptions, filter negotiation. Checked 2026-09-05.
[^23]: The Model Context Protocol defines a subscriptions listen stream that a client opens to receive server notifications. Source: [Model Context Protocol specification 2026-07-28, Subscriptions](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/subscriptions), Subscriptions. Checked 2026-09-05.
[^24]: Resumable server-sent event streams via the Last-Event-ID header are not supported in the 2026-07-28 revision. Source: [Model Context Protocol specification 2026-07-28, Streamable HTTP](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http), Streamable HTTP. Checked 2026-09-05.
[^25]: Client reconnection after a dropped stream is graded MAY and the specification publishes no backoff schedule no retry cap and no way to learn what was missed. Source: [Model Context Protocol specification 2026-07-28, Streamable HTTP](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http), Streamable HTTP. Checked 2026-09-05.
[^26]: The subscriptions page states a client obligation for the standard input and output transport: a client MUST demultiplex incoming notifications by subscription identifier. Source: [Model Context Protocol specification 2026-07-28, Subscriptions](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/subscriptions), Subscriptions, stdio transport. Checked 2026-09-05.
[^27]: In the 2026-07-28 revision a server that declared the list changed capability SHOULD send the tool list changed notification to clients that have opened a subscriptions listen stream with the tools list changed filter set to true. Source: [Model Context Protocol specification 2026-07-28, Server Features: Tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools), Tools > List Changed Notification. Checked 2026-09-05.
[^28]: 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. Source: [Model Context Protocol specification 2026-07-28, Subscriptions](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/subscriptions), Subscriptions, whole page. Checked 2026-09-05.
[^29]: Multi Round-Trip Requests do not share the long-lived connection machinery that subscriptions use (inferred). Source: [Model Context Protocol specification 2026-07-28, Multi Round-Trip Requests](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/mrtr), Multi Round-Trip Requests. Checked 2026-09-05.