A client sends subscriptions/listen requesting both toolsListChanged and promptsListChanged. The acknowledgment's notifications field contains only toolsListChanged. How should the client interpret this?
Select an answer to reveal the explanation.
Short Explanation
The acknowledgment is the server telling you exactly which updates it will actually send. If prompts are missing, you won't get prompt updates, so you plan around that. Resending the same request won't change the answer.
Full Explanation
After a client sends subscriptions/listen, the server MUST send notifications/subscriptions/acknowledged as the first message carrying that subscription's id. The notifications field in the acknowledgment reflects the subset of the requested filter the server agreed to honor, and notification types the server does not support are omitted. The client SHOULD check the acknowledged filter against what it requested and handle unsupported types gracefully, for example by refetching prompts/list when it needs it, relying on ttlMs freshness, or treating the prompt list as static. Calling the acknowledgment malformed misreads the specification, since omission is exactly how a server signals that it will not deliver a type; resending the same request would produce the same subset. An acknowledgment does not echo only the first field; it lists every type the server will honor, so a missing type will not arrive. Sending prompt changes on the tools stream with a different subscription id is impossible by design, because every notification on a stream carries the id of the subscriptions/listen request that opened it, and the server MUST NOT send types the client did not request on that subscription. Exam caveat: a server can honor promptsListChanged only if it declared listChanged in its prompts capability. Operational check: compare the acknowledged filter with the request and confirm the client logs the omitted type and switches to a fallback refresh strategy.