Skip to content

feat(types,spec): add tools field to McpUiHostCapabilities#656

Open
saaage wants to merge 1 commit intomodelcontextprotocol:mainfrom
saaage:feat/host-tools-capability
Open

feat(types,spec): add tools field to McpUiHostCapabilities#656
saaage wants to merge 1 commit intomodelcontextprotocol:mainfrom
saaage:feat/host-tools-capability

Conversation

@saaage
Copy link
Copy Markdown

@saaage saaage commented May 6, 2026

Closes #655.

Problem

McpUiAppCapabilities allows widgets to declare tools: {} signalling they expose oncalltool/onlisttools, but McpUiHostCapabilities has no corresponding field. The handshake is one-sided:

  • Widgets can declare intent (tools: {} in ui/initialize)
  • Hosts have no spec-defined way to advertise they will honor it
  • Widgets cannot gate on getHostCapabilities()?.tools because the field doesn't exist
  • No known host implements bridge.listTools() — the spec gap is likely a contributing factor

Fix

Add tools?: { listChanged?: boolean } to McpUiHostCapabilities in both src/spec.types.ts and specification/draft/apps.mdx, with MUST-level requirements describing what a host advertising this capability is expected to implement:

  1. Call tools/list on the app after connect and surface results to the LLM
  2. Route LLM tool calls matching app-declared tool names back to the app via tools/call
  3. Re-query tools/list on notifications/tools/list_changed from the app (if listChanged: true)

Precedent

This follows the same pattern as PR #653, which added updateModelContext and message to McpUiHostCapabilities — fields that were already in the TypeScript types but missing from the spec document.

McpUiAppCapabilities already allows widgets to declare tools: {}
to signal they expose oncalltool/onlisttools, but McpUiHostCapabilities
had no corresponding field. This left the handshake one-sided: widgets
could declare intent but had no way to check whether the host would
honor it, and hosts had no spec-defined way to advertise support.

Add tools?: { listChanged?: boolean } to McpUiHostCapabilities in both
the TypeScript types and the draft spec, with MUST-level requirements on
what a host advertising this capability is expected to implement:
- Call tools/list on the app after connect and surface results to the LLM
- Route matching LLM tool calls back to the app via tools/call
- Re-query tools/list on notifications/tools/list_changed (if listChanged: true)

Fixes: modelcontextprotocol#655
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

McpUiHostCapabilities missing tools field — widget-declared tools unimplementable by hosts

2 participants