Skip to content

T16 - server notification publisher and subscriptions/listen #254

Description

@kubinio123

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions