Modern era: subscriptions/listen can never be opened against a tools-only server (toolsListChanged unreachable from the UI)

[antoniocasagrande-airia]

Summary

On a modern-era (2026-07-28) connection to a server that advertises only tools: { listChanged: true } — no resources — the Inspector can never open a subscriptions/listen stream, so notifications/tools/list_changed is unreachable from the UI. The filter side is already wired for this case; only the trigger that opens the stream is missing.

Repro

1. Connect (modern era) to a server whose server/discover returns capabilities { "tools": { "listChanged": true } } and no resources capability. (Any tools-only server works — e.g. a gateway whose tool surface mutates via tool calls.)
2. Call a tool that changes the server's tool list; the server publishes notifications/tools/list_changed to its subscriptions/listen subscribers.
3. Expected: some way for the Inspector to receive the notification / refresh the tool list.
4. Actual: no listen stream is ever opened, so the notification never arrives. The Resources screen (the only affordance that opens the stream) isn't available because the server has no resources.

Root cause

In core/mcp/inspectorClient.ts:

• refreshModernSubscription() keeps the stream closed unless at least one resource URI is subscribed:

  // Nothing subscribed → keep the stream closed.
  if (this.subscribedResources.size === 0) {
    this.setModernStreamState(INACTIVE_SUBSCRIPTION_STREAM_STATE);
    return;
  }

• …while buildSubscriptionFilter() already handles the tools case whenever the stream does open:

  if (
    this.listChangedNotifications.tools &&
    this.capabilities?.tools?.listChanged
  ) {
    filter.toolsListChanged = true;
  }

So a tools-only server that correctly advertises tools.listChanged: true has no path to an open stream, and the toolsListChanged filter bit that #1630's design models never gets a chance to ride along. (The SDK itself is fine — Client.listen(filter) is caller-driven and works against such servers; this is purely about what the Inspector UI can trigger.)

Suggested fix

Open (or keep open) the listen stream whenever the built filter is non-empty, not only when resourceSubscriptions is non-empty — e.g. change the bail condition in refreshModernSubscription() from subscribedResources.size === 0 to "the filter from buildSubscriptionFilter() has no fields". That makes the enabled listChangedNotifications bits (gated on the corresponding server capability, as today) sufficient to open the stream on connect.

Happy to send a PR if this direction sounds right.

Environment

• Inspector v2/main (verified present at current HEAD)
• Server: modern era 2026-07-28, capabilities tools: { listChanged: true } only

[antoniocasagrande-airia]

A follow-up that makes the fix direction more concrete: the SDK the Inspector already depends on (@modelcontextprotocol/client 2.0.0-beta.5) ships this exact behavior one layer down.

ClientOptions.listChanged auto-opens a subscriptions/listen stream on a modern connection at connect time — the filter is computed as the intersection of the configured listChanged handlers and the server-advertised listChanged capabilities, the auto-open is silently skipped when that intersection is empty, and the handle is exposed as client.autoOpenedSubscription. So the "when should the stream open" question already has a resolved design in the SDK: whenever the effective filter is non-empty, with no dependency on resource subscriptions.

The Inspector's hand-managed stream (the refreshModernSubscription machinery from #1630, which exists for the re-list-on-filter-change and reconnect-by-re-listen semantics that resource URI subscriptions need) is the only place that condition got narrowed to subscribedResources.size > 0.

That suggests two fix shapes, either of which closes the tools-only gap:

1. Minimal (as in the issue body): change the bail condition in refreshModernSubscription() from "no subscribed URIs" to "the filter from buildSubscriptionFilter() is empty" — the enabled listChanged bits then open the stream on connect, mirroring the SDK's intersection semantics.
2. Structural: let the SDK's ClientOptions.listChanged auto-open own the pure listChanged bits, and keep the hand-managed re-list machinery scoped to resource URI subscriptions only (merging the two filters when both are active).

Option 1 is a few lines and keeps one stream; happy to send that PR.