Claude Desktop strips structuredContent from ui/notifications/tool-result — views built per SDK examples render blank

使用提供的服务器结果以及在 ontoolresult 中读取 structuredContent 的应用视图，通过 Claude Desktop 1.18286.2 重现该问题。跟踪 tools/call 和 resources/read 之后 ui/notifications/tool-result 的传递；当 structuredContent 按照指定到达视图，且不需要在 content 中重复时，即视为完成。

Summary

Claude Desktop (macOS 1.18286.2, checked 2026-07-07) delivers the ui/notifications/tool-result notification to the app view without the structuredContent field, even when the server's CallToolResult includes it. Every SDK example and pattern reads the view's data from result.structuredContent in ontoolresult, so an app built exactly per the docs mounts, completes the handshake, receives the result, renders nothing, reports ~zero height via auto-resize and is collapsed to an invisible widget. There is no error anywhere: server logs look healthy and the chat just shows no widget.

Environment

• Claude Desktop 1.18286.2, macOS (Darwin 25.5)
• @modelcontextprotocol/ext-apps 1.7.4, @modelcontextprotocol/sdk 1.29.0
• Local stdio server, pre-bundled with esbuild; view bundled with vite-plugin-singlefile
• Tool registered via registerAppTool with _meta.ui.resourceUri, an inputSchema and an outputSchema; resource registered via registerAppResource with RESOURCE_MIME_TYPE

What the server returns

return {
  content: [{ type: "text", text: "…spec as fenced json…" }],
  structuredContent: { spec },
  _meta: { "weave/spec": spec },
};

tools/list advertises the matching outputSchema (declaring it made no difference, tested both ways).

Evidence

1. Instrumented the view to print its lifecycle into the widget. In Claude Desktop it shows the handshake completing and then:

   tool result received but no structuredContent.spec attached

   So the sandbox runs the view, ui/initialize succeeds, the tool-result notification arrives — with structuredContent missing.

2. The identical built view under an emulated host (iframe + postMessage, responding to ui/initialize and then sending ui/notifications/tool-result with the full CallToolResult) renders correctly and reports its size. The app side follows the protocol; the host delivery differs.

3. Desktop's MCP server log shows the healthy half: tools/call returning normally and resources/read fetching the view HTML. The stripping happens between the host receiving the result and forwarding it to the view.

4. A second app on the same machine (single-tool Mermaid viewer built from the SDK examples, verified working end-to-end in Claude Desktop in May 2026) now shows the same symptom for its structuredContent-dependent path. Its editor still fills via ui/notifications/tool-input, which suggests tool-input is forwarded intact while tool-result is stripped of structuredContent.

Expected

Per the spec's data-delivery section, results forwarded to the view include content and optionally structuredContent, with structuredContent/_meta being the channels that do not enter model context. The view should receive structuredContent when the server provided it.

Workaround

Duplicate the payload into the content text (e.g. a fenced JSON block) and parse it in the view when structuredContent is absent. Ugly, but it renders on current Desktop while staying compatible with spec-following hosts.

Possibly related

• #380 (clarifying content vs structuredContent vs _meta visibility)
• #646 (basic-host not forwarding tool-result _meta)

🤖 Generated with Claude Code