A client wants change notifications for two specific resource URIs only, and it does not want tool or prompt list changes. How should it subscribe under revision 2026-07-28?
Select an answer to reveal the explanation.
Short Explanation
Subscriptions are opt-in, so you only ask for what you want. Put the two URIs in resourceSubscriptions and leave the list-changed flags off. resources/subscribe is the old way and the trap.
Full Explanation
In this revision, change notifications are opt-in through subscriptions/listen, which replaced the former resources/subscribe RPC and the HTTP GET endpoint. The request carries a notifications filter whose fields are toolsListChanged, promptsListChanged, resourcesListChanged and resourceSubscriptions, the last being an array of resource URIs for which the client wants notifications/resources/updated. All fields are optional, and omitting one is equivalent to not subscribing to that type. The server MUST NOT send notification types the client has not explicitly requested, so listing the two URIs and setting no list-changed flags yields exactly the desired stream. resources/subscribe and the GET stream are legacy mechanisms; a server implementing only 2026-07-28 answers GET with 405. An empty filter requests nothing, so the server would send no notifications at all, and the premise of discarding unwanted types is wrong because they would never be sent. Polling on a timer equal to ttlMs misuses caching; TTL is a freshness hint checked on access, and clients SHOULD NOT treat it as a polling interval. Exam caveat: the server's resources capability must declare subscribe for it to honor resourceSubscriptions, and the acknowledgment shows what it agreed to. Operational check: open the subscription and confirm the acknowledgment lists both URIs and that only notifications/resources/updated for those URIs arrive.