Target branch: 2026-07-28-protocol-support
Requires:
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:
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.
Target branch: 2026-07-28-protocol-support
Requires:
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 andresources/subscribe. A server author publishes these events from application code.Publishing
tools.listChanged,prompts.listChanged,resources.listChangedandresources.subscribeare true only when the server is set up to publish the matching events. The fixedfalseof today goes away.Opening a subscription
subscriptions/listenrequest with a notification filter opens a stream that stays open until one side ends it.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._meta["io.modelcontextprotocol/subscriptionId"]equal to the id of the listen request.resourceSubscriptions.Ending a subscription
notifications/cancelledwith the id of the listen request.subscriptions/listenresult that carries the subscription id, and on stdio it also sendsnotifications/cancelledfor the listen request. Both spec pages are satisfied this way.subscriptions/listenwith-32601. The harness then skips its listen checks.Coverage
resources/subscribeandresources/unsubscribekeep working for legacy clients as they do today.test_trigger_tool_changeandtest_trigger_prompt_change, which publish a list change, and advertiseslistChangedfor tools and prompts.Spec:
Conformance scenarios that must pass after this task:
server-statelesschecks 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 theresourceSubscriptionsfilter replacesresources/subscribe.