A server declares the resources capability with subscribe set to true and listChanged absent. A client developer wants to know what the client can rely on. Which interpretation is correct?
Select an answer to reveal the explanation.
Short Explanation
Picture two separate doorbells on your door: one rings when a specific resource changes, the other when the whole list changes. This server only wired up the first one. The trap is assuming one feature drags the other along; the spec says they're independent.
Full Explanation
The resources capability has two optional features. listChanged says the server will emit notifications/resources/list_changed when the set of available resources changes. subscribe says the server supports update notifications for specific resources that a client requests through subscriptions/listen using the resourceSubscriptions filter; the server then delivers notifications/resources/updated for each watched URI. The specification states servers may advertise either feature independently, both, or neither. With only subscribe declared, a client can watch particular URIs but has no promise of list-change notices, so it should refresh resources/list on its own schedule, guided by ttlMs. Calling the declaration invalid fails because no rule couples the two features. Assuming subscribe implies listChanged fails for the same reason; each flag stands alone. Polling with resources/subscribe fails because resources/subscribe and resources/unsubscribe are legacy methods; in this revision subscriptions are opened with subscriptions/listen, and the first message on that stream is notifications/subscriptions/acknowledged. Exam caveat: a server supporting neither feature may declare resources as an empty object. Operational check: open subscriptions/listen with resourceSubscriptions for one URI, change that resource, and confirm an updated notification arrives carrying the listen request's subscriptionId.