Opening a stream is easy. Keeping it useful when connections drop and your server runs across multiple instances? That's where things get interesting. 😅
I just published a practical walkthrough of subscriptions/listen in the 2026 Model Context Protocol (MCP) specification.
What you'll learn
How subscriptions work: Open a long-lived stream and request the notification types you care about.
Why acknowledgements matter: The server acknowledges the subscription before sending notifications.
What notifications actually tell you: They're signals that something changed, not the updated resource itself.
How reconnects work: Missed events aren't replayed, so clients need to subscribe again and refresh their state.
What changes when you scale out: Multiple server instances need a shared pub/sub mechanism to keep their subscribers informed.
A little Python, too
The article includes examples using the MCP Python SDK (mcp 2.3.0), including how to notify clients when a resource changes and how to think about implementing a subscription bus across multiple server instances.
I also cover practical details like stream shutdowns, idle timeouts, authentication expiry, and the difference between a clean close and an unexpected disconnect.
The big takeaway
Don't treat a subscription as a durable event log.
If a connection drops, assume you may have missed changes. Reconnect, subscribe again, and refresh whatever state you cached. And if you're running multiple instances, remember that a notification generated on one instance won't automatically reach a stream connected to another.
Distributed systems: finding new ways to remind us that "it works on my machine" is not an architecture. 🙂
👉 Read the full article: [https://pournasserian.com/writing/mcp-2026-subscriptions-listen](https://pournasserian.com/writing/mcp-2026-subscriptions-listen)
If you're building MCP servers, I'd love to hear how you're handling subscription fan-out and reconnect recovery in your own setups.