Resources: Disable listChanged capability in V1x

[yu1uuu]

I see a PR addressing this issue merged but doesn't seem to be applied or hasn’t been released in v1x: #1513

Could we address this again to be able explicitly set listChanged capability to false?

[mcp-claude]

bug confirmed on v1.x (v1.29.0); fixed on main in PR #1513 (commit 8654c7f), not backported to origin/v1.x.

in src/server/mcp.ts the three lazy-init methods hardcode listChanged: true when registering capabilities, unconditionally overwriting any explicit listChanged: false the user passed in capabilities at construction time.

workaround: call server.server.setCapabilities(...) after construction to restore the value, or monkey-patch before registering tools/resources/prompts. neither is pleasant.

fix: backport the same one-liner change from PR #1513 to v1.x:

-  listChanged: true
+  listChanged: this.server.getCapabilities().tools?.listChanged ?? true

(same pattern for resources and prompts — three hunks total in src/server/mcp.ts)

repro script (repro.ts — run against v1.x checkout)

import { McpServer } from './src/server/mcp.js';
import { InMemoryTransport } from './src/inMemory.js';
import { Client } from './src/client/index.js';

async function main() {
  const server = new McpServer({ name: 'test-server', version: '1.0.0' }, {
    capabilities: {
      resources: { listChanged: false },
      tools: { listChanged: false },
      prompts: { listChanged: false },
    }
  });

  server.resource('test-resource', 'test://resource', async () => ({
    contents: [{ uri: 'test://resource', text: 'hello', mimeType: 'text/plain' }]
  }));
  server.tool('test-tool', async () => ({ content: [{ type: 'text' as const, text: 'result' }] }));
  server.prompt('test-prompt', async () => ({
    messages: [{ role: 'user' as const, content: { type: 'text' as const, text: 'prompt' } }]
  }));

  const [clientTransport, serverTransport] = InMemoryTransport.createLinkedPair();
  await server.connect(serverTransport);
  const client = new Client({ name: 'test-client', version: '1.0.0' });
  await client.connect(clientTransport);

  const caps = client.getServerCapabilities();
  console.log(JSON.stringify(caps, null, 2));
  const bug = caps?.resources?.listChanged === true || caps?.tools?.listChanged === true || caps?.prompts?.listChanged === true;
  console.log(bug ? 'BUG REPRODUCED' : 'no bug');
  process.exit(bug ? 1 : 0);
}
main().catch(e => { console.error(e); process.exit(2); });

command + output

# on origin/v1.x (v1.29.0)
$ npx tsx repro.ts
Server capabilities after registration:
{
  "prompts": { "listChanged": true },
  "resources": { "listChanged": true },
  "tools": { "listChanged": true }
}
resources.listChanged = true (expected: false, bug if true)
tools.listChanged     = true (expected: false, bug if true)
prompts.listChanged   = true (expected: false, bug if true)
BUG REPRODUCED: listChanged: false was overwritten to true
exit code 1

# on origin/main (commit b8886e77)
$ npx tsx repro_main.ts
Server capabilities after registration:
{
  "prompts": { "listChanged": false },
  "resources": { "listChanged": false },
  "tools": { "listChanged": false }
}
No bug: listChanged: false was preserved
exit code 0

code path

src/server/mcp.ts (v1.x):

• line 132–136: _initializeToolHandlers → registerCapabilities({ tools: { listChanged: true } })
• line 494–498: _initializeResourceHandlers → registerCapabilities({ resources: { listChanged: true } })
• line 574–578: _initializePromptHandlers → registerCapabilities({ prompts: { listChanged: true } })

registerCapabilities merges into the server's capability map, so this unconditional true always wins over whatever was set at construction.

the fix on main (packages/server/src/server/mcp.ts commit 8654c7f): reads the existing capability first via this.server.getCapabilities().tools?.listChanged ?? true, so an explicit false is preserved and the default is still true.

suggested fix

// src/server/mcp.ts
         this.server.registerCapabilities({
             tools: {
-                listChanged: true
+                listChanged: this.server.getCapabilities().tools?.listChanged ?? true
             }
         });

         this.server.registerCapabilities({
             resources: {
-                listChanged: true
+                listChanged: this.server.getCapabilities().resources?.listChanged ?? true
             }
         });

         this.server.registerCapabilities({
             prompts: {
-                listChanged: true
+                listChanged: this.server.getCapabilities().prompts?.listChanged ?? true
             }
         });

test to verify: constructs McpServer with tools/resources/prompts: { listChanged: false }, registers a tool/resource/prompt, connects a client, and asserts client.getServerCapabilities() reports listChanged: false for all three.

[CrepuscularIRIS]

Hi — I'd like to pick this up as a v1.x backport of #1513.

The fix merged to main in #1513 was a three-hunk change in src/server/mcp.ts (nullish-coalescing the listChanged default in each of setTool/Resource/PromptRequestHandlers) plus making Server.getCapabilities() public. The same edit applies cleanly to v1.x at src/server/mcp.ts:134/496/576 and src/server/index.ts:467. I'd also bring over the four listChanged-respects-explicit-false tests from that PR, adapted to v1.x's test/server/mcp.test.ts layout and the existing Zod v3/v4 test matrix.

Will open as [v1.x backport] fix: respect explicit listChanged: false capability setting if that's welcome.

[Zelys-DFKH]

Traced this to three handler-registration methods in mcp.ts hardcoding listChanged: true on the v1.x branch. The fix from #1513 was never backported. Since no PR has appeared from @CrepuscularIRIS, I'll pick this up and open the backport shortly.