Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở Phù hợp với người mới
  • Có gì không ổn?
#634 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
1/5
Thời gian dự kiến
Dưới một giờ
Mức phù hợp với người mới
88/100
Loại issue
Tài liệu
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
javascript, typescript
Lĩnh vực
documentation

Hướng nghiên cứu

Chỉnh sửa specification/2026-01-26/apps.mdx trong phần Transport Layer, khoảng dòng 455–465, và đối chiếu với App Capabilities trong phần ui/initialize cũng như specification/draft/apps.mdx. Cập nhật ví dụ để sử dụng ui/initialize, appInfo và appCapabilities, đồng thời thêm phần làm rõ về tầng giao thức; hoàn tất khi ví dụ khớp với Apps handshake được ghi trong tài liệu.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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).
Ngôn ngữ chính
TypeScript
Star
2.9k
Fork
401
Merge trung bình
5 giờ 37 phút
Pull request đã merge (30 ngày)
7

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của modelcontextprotocol/ext-apps

Tất cả issue của modelcontextprotocol/ext-apps

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.