The mechanism
Current MCP uses subscriptions/listen for requested change notifications. A client opts into events; a server does not gain permission to push arbitrary work simply because a connection exists. HTTP subscriptions use a long-lived response stream for that request.
Treat an event as a reason to re-evaluate cached knowledge. A resource-change notification does not itself establish the latest complete resource state or grant access to it. Fetch the resource through the usual authorization path and preserve the distinction between event time and observation time.
For ParcelOps, a changed incident should invalidate the relevant cached summary. The user’s task may already be complete, so a host needs a lifecycle policy for subscriptions: who owns them, when they end and how much background work they may cause.
Worked example
This is an application state machine, not a protocol payload. It makes the desired recovery behavior inspectable without inventing a subscription filter schema. Consult the pinned official pattern for the actual request fields supported by your SDK.
IDLE -> subscribe explicitly -> LISTENING
LISTENING + relevant event -> mark cached context STALE
STALE + active user need -> authorized resource read -> FRESH
LISTENING + disconnected stream -> UNKNOWN
UNKNOWN + reconnect policy -> resubscribe and reconcile
ANY + task ended -> close subscription and stop background workPractice: predict, inspect, explain
Offline exercise. Replay three events for the same incident, then simulate a disconnect and an event you did not receive. Decide how to avoid three redundant reads and how to recover after the gap. Keep the latest authorized resource revision as the comparison point.
Expected observation: coalescing can reduce work, but missed notifications require reconciliation. Do not claim a complete event history or exactly-once delivery from a stream alone. A resumed user session should show what was last observed and whether freshness is uncertain.
Troubleshooting and trade-offs
If a stream silently dies behind a proxy, inspect idle timeouts and client lifecycle handling. If reconnects cause a request storm, apply bounded backoff and coalescing. The modern HTTP transport removes the old standalone GET stream and resumability assumptions; do not reuse a legacy Last-Event-ID recipe without verifying the actual protocol era.
Interview practice
Is a change event sufficient evidence of current state?
No. It is a signal to inspect or invalidate. Re-read the authoritative resource through the current authorization context and record the resulting revision.
How should a reconnect handle missed events?
Reconcile current state rather than assuming every event can be replayed. Document delivery and recovery guarantees supplied by the implementation.
Completion check
Draw the disconnect path and explain how your host prevents unbounded background polling.
Sources and version notes
This edition targets MCP 2026-07-28, checked 6 October 2026. SDK examples are version-sensitive and labelled when not executed. Synthetic fixtures are learning material, not protocol conformance evidence.
- Official documentation: Subscriptions
- Official documentation: Streamable http
- Official documentation: Caching
Make the understanding yours.
Use the completion check above. Mark this chapter when you can explain the mechanism and its limits.
Self-assessed reading progress. This does not certify that a lab ran or a system is secure.