T16 - server notification publisher and subscriptions/listen

Target branch: 2026-07-28-protocol-support

Requires:

• https://github.com/softwaremill/chimp/issues/244
• https://github.com/softwaremill/chimp/issues/246

A chimp server can tell its clients that the list of tools, prompts or resources changed, and that a given resource was updated. On the 2026-07-28 wire this happens through subscriptions/listen, the one long-lived stream that replaces the GET stream and resources/subscribe. A server author publishes these events from application code.

Publishing

• A server author can publish four kinds of events from anywhere in the application, not only from inside a tool call: tools list changed, prompts list changed, resources list changed, and resource updated for a given URI.
• The capabilities a server advertises match what it can publish. tools.listChanged, prompts.listChanged, resources.listChanged and resources.subscribe are true only when the server is set up to publish the matching events. The fixed false of today goes away.

Opening a subscription

• A subscriptions/listen request with a notification filter opens a stream that stays open until one side ends it.
• The first message on the stream is notifications/subscriptions/acknowledged. Its filter is the subset the server honours. Types the server cannot publish are left out. The server never sends a notification type the client did not ask for or the server did not acknowledge.
• Every message on the stream carries _meta["io.modelcontextprotocol/subscriptionId"] equal to the id of the listen request.
• Resource updates are sent only for the URIs listed in resourceSubscriptions.
• Progress and log notifications never travel on a listen stream. They stay on the response stream of the request they belong to.
• A client can hold several subscriptions at once. On stdio they share one channel and are told apart by the subscription id.

Ending a subscription

• Over HTTP, the subscription ends when the client closes the response stream. The server stops publishing to it.
• Over stdio, the subscription ends when the client sends notifications/cancelled with the id of the listen request.
• When the server shuts down, it ends each subscription with a successful subscriptions/listen result that carries the subscription id, and on stdio it also sends notifications/cancelled for the listen request. Both spec pages are satisfied this way.
• A server on the sync HTTP transport cannot hold a stream open and answers subscriptions/listen with -32601. The harness then skips its listen checks.

Coverage

• The rules above hold for the streaming servers over HTTP and stdio on ZIO, Ox and Pekko.
• Legacy behaviour does not change. resources/subscribe and resources/unsubscribe keep working for legacy clients as they do today.
• The conformance server offers the fixture tools test_trigger_tool_change and test_trigger_prompt_change, which publish a list change, and advertises listChanged for tools and prompts.

Spec:

• Subscriptions - Opening a Stream
• Subscriptions - Acknowledgment
• Subscriptions - Receiving Notifications
• Subscriptions - Multiple Concurrent Subscriptions
• Subscriptions - Cancellation
• Subscriptions - Graceful Closure
• Cancellation - Transport-Specific Cancellation
• Streamable HTTP - Receiving Messages
• stdio - Receiving Messages
• Tools - List Changed Notification
• Prompts - List Changed Notification
• Resources - List Changed Notification
• Resources - Subscriptions

Conformance scenarios that must pass after this task:

• The server-stateless checks that were skipped until now turn to pass: sep-2575-server-sends-subscription-ack, sep-2575-server-tags-subscription-id, sep-2575-server-honors-notification-filter, sep-2575-server-sends-prompts-list-changed-on-subscription, sep-2575-server-sends-tools-list-changed-on-subscription. The scenario stays out of the baseline.

Docs: yes.

• docs/server/capabilities.md: how to publish list changes and resource updates, which capabilities follow from it, and that a streaming transport is required.
• docs/server/resources.md: subscriptions on the 2026-07-28 wire, where the resourceSubscriptions filter replaces resources/subscribe.

Start by reading the 2026-07-28 subscription and transport specifications, then inspect the existing server implementations for ZIO, Ox, and Pekko and the prerequisite issues 244 and 246. Update docs/server/capabilities.md and docs/server/resources.md, and run the named server-stateless conformance scenarios; done means the listed subscription checks pass while legacy behavior remains unchanged.