Stateless HTTP server should not advertise `listChanged` capabilities

[mikekistler]

Description:

When configuring an MCP server with Stateless = true on the HTTP transport, the server still advertises listChanged: true for tools, resources, and prompts in the initialize response.

Server configuration:

builder.Services.AddMcpServer()
    .WithHttpTransport(options =>
        options.Stateless = true
    )
    .WithTools<MyTools>()
    .WithResources<MyResources>()
    .WithPrompts<MyPrompts>();

Actual initialize response:

{
  "result": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "logging": {},
      "prompts": { "listChanged": true },
      "resources": { "listChanged": true },
      "tools": { "listChanged": true }
    },
    "serverInfo": { "name": "Stateless", "version": "1.0.0.0" }
  },
  "id": 1,
  "jsonrpc": "2.0"
}

Expected initialize response:

The listChanged capability should not be advertised (or should be false) for tools, resources, and prompts when the server is configured in stateless mode. In stateless mode, each request creates a new server instance, so there is no persistent session to receive notifications/tools/list_changed, notifications/resources/list_changed, or notifications/prompts/list_changed notifications.

{
  "result": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "logging": {},
      "prompts": {},
      "resources": {},
      "tools": {}
    },
    "serverInfo": { "name": "Stateless", "version": "1.0.0.0" }
  },
  "id": 1,
  "jsonrpc": "2.0"
}

Rationale:

The listChanged capability indicates that the server may send list-changed notifications to the client during a session. In stateless mode, there is no persistent session — each HTTP request creates a new server instance and the server cannot send unsolicited notifications to the client. Advertising listChanged: true is misleading because the server will never actually send these notifications.

Version: ModelContextProtocol.AspNetCore 1.1.0

[halter73]

Good call out. It will never work in stateless. I wonder if this shouldn't be opt-in in general, since the pattern of modifying a tools/prompts/resource list at runtime in general is pretty niche.