Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Spec 2026-01-26: misleading "View initialize" example uses `initialize` + `clientInfo` instead of `ui/initialize` + `appInfo`

オープン 初心者向け
  • 何か問題がありますか？
#634 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@Michael-WhiteCapData がすでに取り組んでいます。

2026年9月18日 から。

  • #779 @Michael-WhiteCapData による — オープン

評価

難易度
1/5
見積もり時間
1時間未満
初心者へのやさしさ
88/100
issue の種類
ドキュメント
明瞭さ
明確に書かれている
活発さ
静か
技術スタック
javascript, typescript
領域
documentation

調査の方向性

specification/2026-01-26/apps.mdx の Transport Layer セクションを 455–465 行付近で編集し、ui/initialize セクションの App Capabilities および specification/draft/apps.mdx と比較してください。例を ui/initialize、appInfo、appCapabilities を使用するように更新し、プロトコル層に関する補足を追加してください。例が文書化された Apps handshake と一致すれば完了です。

索引モデルが issue の本文から書いたものです。

説明

bug

Describe the bug

The specification/2026-01-26/apps.mdx contains a code example (around lines 455–465, in the "Transport Layer" section) that is framed as the View→Host handshake but uses the
regular MCP initialize method and clientInfo field. The rest of the same spec — and the current draft — define the Apps-dialect handshake as ui/initialize with appInfo /
appCapabilities. The misleading example leads implementers to send a schema-invalid request that compliant hosts (Claude web and Desktop) reject; the iframe container stays at
visibility: hidden and the user only sees the [This tool call rendered an interactive widget…] placeholder.

To Reproduce

Steps to reproduce the behavior:

  1. Register an MCP Apps tool with _meta.ui.resourceUri and its UI resource with mimeType: "text/html;profile=mcp-app".
  2. In the UI HTML, implement the handshake exactly as the 2026-01-26 example shows:
    window.parent.postMessage({
    jsonrpc: "2.0", id: 1, method: "initialize",
    params: {
    protocolVersion: "2026-01-26",
    capabilities: {},
    clientInfo: { name: "My UI", version: "1.0.0" }
    }
    }, "*");
  3. Add the server as a custom connector in Claude (web or Desktop).
  4. Call the tool. No iframe appears.
  5. Try again using the names from the draft spec / the rest of 2026-01-26 (ui/initialize, appInfo, appCapabilities). Handshake succeeds, iframe becomes visible.

Expected behavior

The example in 2026-01-26 should match the method and field names used elsewhere in the same document (and in the current draft):

window.parent.postMessage({
jsonrpc: "2.0", id: 1, method: "ui/initialize",
params: {
protocolVersion: "2026-01-26",
appInfo: { name: "My UI", version: "1.0.0" },
appCapabilities: { availableDisplayModes: ["inline"] }
}
}, "*");

Also worth a one-line note clarifying that regular MCP initialize + clientInfo describes a different protocol layer (server ↔ client), distinct from the Apps-dialect View ↔ Host
handshake.

Logs

Request sent (following the misleading example — note the method and clientInfo):

{
"jsonrpc": "2.0", "id": 1, "method": "ui/initialize",
"params": {
"protocolVersion": "2026-01-26",
"clientInfo": { "name": "ANDY Hello Test", "version": "1.0.0" },
"appCapabilities": { "availableDisplayModes": ["inline"] }
}
}

Host response (Claude web):

{
"jsonrpc": "2.0", "id": 1,
"error": {
"code": -32603,
"message": "[{"expected":"object","code":"invalid_type","path":["params","appInfo"],"message":"Invalid input"}]"
}
}

After renaming clientInfo → appInfo, the host returns a normal McpUiInitializeResult and, after ui/notifications/initialized + ui/notifications/size-changed, the iframe becomes
visible.

Additional context

  • Offending location: specification/2026-01-26/apps.mdx, "Transport Layer" section, the const initializeResult = await sendRequest("initialize", { ... clientInfo ... }) block.
  • Correct shape is already documented elsewhere in the same spec ("App Capabilities in ui/initialize" section, the mermaid lifecycle diagram) and in specification/draft/apps.mdx
    (section "App (Guest UI) Capabilities", line ~2233).
  • Side observation that made this hard to diagnose: @modelcontextprotocol/ext-apps imported via https://esm.sh/@modelcontextprotocol/ext-apps throws TypeError: t.custom is not a
    function in App.connect() (looks like a zod version mismatch in the CDN bundle). That error fires before ui/initialize is sent, masking the real spec/host mismatch. Only a
    hand-rolled ~40-line postMessage handshake surfaces the Zod error above from Claude.
  • Verified against Claude.ai and Claude Desktop custom connector over Streamable HTTP on 2026-04-22.
  • Related downstream symptom reports: anthropics/claude-ai-mcp#61, #165 (different root causes, same visible symptom).
主要言語
TypeScript
スター
2.9k
フォーク
394
平均マージ
5時間 37分
マージ済み PR（30日）
7

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

modelcontextprotocol/ext-apps のほかの issue

modelcontextprotocol/ext-apps の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。