[BUG] Client's elicitation capability is ignored during handshake

[9214]

Issue

In v2.6.1, MCP client elicitation capability is ignored.

How to reproduce

1. Go to 'Clients'
2. Click on 'Client capabilities'
3. Add "elicitation": {}:

{
  "connectionDefaults": {
    "requestTimeout": 10000
  },
  "capabilities": {
    "elicitation": {}
  }
}

4. Click on 'Save host'
5. Go to 'Servers'
6. Connect to any MCP server and start initialization phase
7. Note that capability set earlier in step 3 is absent in req → initalize body:

{
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {},
    "clientInfo": {
      "name": "p17bs44xdd0zay2e4nj67ar47d87hv1a",
      "version": "1.0.0"
    }
  },
  "jsonrpc": "2.0",
  "id": 0
}

Expected Behavior

I should be able to setup elicitation capability for MCP clients.

Platform

Tested with:

• Docker image build from d0f9daf
• Hosted web-app

[dosubot]

Hi @9214! I'm Dosu and I’m helping the inspector team.

This looks like a confirmed issue with how client capabilities are handled in buildCapabilities. There are two contributing factors:

1. Elicitation is conditionally stripped: The buildCapabilities method in MCPClientManager.ts explicitly deletes the elicitation key from capabilities when no elicitation handler is registered for the server [1]. Since the Inspector only registers elicitation handlers per-tool-execution (not at connection time), hasElicitationHandler(serverId) is always false during the initialize handshake — causing elicitation to be stripped.

2. The "exact" path bypasses all defaults: When config.clientCapabilities is set (which it is when you use the "Client capabilities" JSON editor), buildCapabilities takes the "exact replacement" path [2]. This means your provided capabilities completely replace all defaults (including the io.modelcontextprotocol/ui extension). No merging with defaults occurs.

So when you set {"elicitation": {}}:

1. The exact path is taken → no defaults merged
2. elicitation is stripped (no handler registered at connection time)
3. Result: {} — empty capabilities in the initialize request

Workaround: If you include additional capabilities beyond just elicitation, those will survive (only elicitation is specifically stripped). For example:

{
  "elicitation": {},
  "extensions": {
    "io.modelcontextprotocol/ui": {
      "mimeTypes": ["text/html;profile=mcp-app"]
    }
  }
}

The extensions part will be sent, but elicitation will still be stripped due to the handler check.

The underlying issues are:

• The elicitation handler isn't registered before buildCapabilities runs, making it impossible to advertise elicitation during initialization via config
• The exact clientCapabilities path doesn't merge with SDK defaults, which may be unexpected for users who just want to add capabilities

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[9214]

@dosu meanwhile, is there a way to make MCP client advertise elicitation capability during initial handshake? I'm interested in that feature specifically, so your proposed workaround is not applicable.

Without "elicitation": {}, MCP server fails during elicitation/create request with client does not support elicitation error.

[dosubot]

Unfortunately, there's no user-facing workaround to force elicitation to be advertised in v2.6.1. The delete exactCapabilities.elicitation logic in buildCapabilities [1] is unconditional when no elicitation handler is registered — and there's no config, env var, or UI setting to bypass it.

The system does register a global elicitation callback at startup via initElicitationCallback() [2], which should make hasHandler() return true and preserve the capability. However, this only applies to the main MCPClientManager instance used in local/Docker mode. If you're connecting through the hosted web-app, it uses ephemeral per-request MCPClientManager instances [3] that don't have the elicitation callback registered — causing hasHandler() to return false and the capability to be stripped.

For Docker builds: The elicitation capability should be advertised (the main instance has the callback). If it's still empty, the bug may be that setting clientCapabilities: {"elicitation": {}} triggers the "exact replacement" path which doesn't merge with defaults, and something else is interfering.

For the hosted web-app: This appears to be a genuine bug — ephemeral managers don't inherit the elicitation callback, so the capability is always stripped regardless of configuration.

Bottom line: There's no workaround available from the UI. This needs a code fix — either the stripping logic should respect explicit user configuration, or ephemeral managers need to register the elicitation callback.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[9214]

For Docker builds: The elicitation capability should be advertised (the main instance has the callback). If it's still empty, the bug may be that setting clientCapabilities: {"elicitation": {}} triggers the "exact replacement" path which doesn't merge with defaults, and something else is interfering.

Yeah, I'm afraid that's the case. Project's default settings are replaced by client's config with elicitation stripped out.

[9214]

Hey @dosu, what's the nearest version prior to v2.6.1 that has working elicitation callback handler and proper MCP client capability advertisement? Pinpoint the exact commit that started the regression. As far as I know, global elicitation callback works with v2.0.5 image on Docker Hub.

[dosubot]

The regression was introduced by commit 693ff852f in PR #1902 ("Fix capability advertising for elicitation and reconnect checks"), merged on April 23, 2026 .

First affected release: v2.4.0 (April 27, 2026)
Last working release: v2.3.x or earlier (anything before v2.4.0)

That PR refactored buildCapabilities to be "serverId-aware and handler-aware," adding this logic:

if (!hasElicitationHandler) {
  delete exactCapabilities.elicitation;
}

Before that commit, buildCapabilities simply passed through user-configured capabilities and even unconditionally added elicitation: {} if it wasn't already present — so elicitation was always advertised regardless of handler state.

Your observation that v2.0.5 works is consistent with this timeline (v2.0.5 was released March 9, well before the April 23 merge). If you need a working Docker image, anything up through v2.3.x should have the old behavior where elicitation is always advertised.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.