Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

T16 - server notification publisher and subscriptions/listen

Open
  • Is something wrong?
#254 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
42/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
scala
Domain
api, backend, documentation

Research direction

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.

Written by the indexing model from the issue text.

Description

2026-07-28 version support

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.
Dominant language
Scala
Stars
102
Forks
10
Avg merge
2d 6h
Merged PRs (30d)
19

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

  • No Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from softwaremill/chimp

All issues in softwaremill/chimp

Similar issues

More Scala issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.