An assistant must react whenever one specific policy document, exposed by an MCP server as a resource, is updated. Which approach does revision 2026-07-28 provide?
Select an answer to reveal the explanation.
Short Explanation
Think of a doorbell for one specific door: you register the address, and the bell rings when that door changes. The trap is resources/subscribe, which was the old doorbell and has been taken out.
Full Explanation
In revision 2026-07-28, change notifications are opt-in through subscriptions/listen, which opens a long-lived stream and replaces both the legacy resources/subscribe method and the HTTP GET stream. The request carries a notifications filter; listing the policy document's URI in resourceSubscriptions asks the server to send notifications/resources/updated for that URI. The server first sends notifications/subscriptions/acknowledged showing which types it agreed to honour, and every notification carries io.modelcontextprotocol/subscriptionId matching the listen request's id. The notification signals a change; the client then calls resources/read to fetch the new content. resources/subscribe and the GET stream are legacy mechanisms removed in this revision. ttlMs is a freshness hint, not a change signal; the spec discourages treating it as a polling interval, and expiry says nothing about whether the document changed. resourcesListChanged reports changes to the list of available resources, such as additions or removals, not edits to the contents of one resource. Exam caveat: the server must not send notification types the client did not request, and on stdio the client must re-send subscriptions/listen after a reconnect. Operational check: open the subscription, confirm the acknowledgement includes the URI, edit the document, and verify a resources/updated notification arrives.