Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta Adatta ai principianti
  • Qualcosa non va?
#634 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
1/5
Tempo stimato
Meno di un'ora
Idoneità per principianti
88/100
Tipo di issue
Documentazione
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
javascript, typescript
Ambito
documentation

Direzione di ricerca

Modifica specification/2026-01-26/apps.mdx nella sezione Transport Layer, intorno alle righe 455–465, e confrontalo con App Capabilities nella sezione ui/initialize e con specification/draft/apps.mdx. Aggiorna l’esempio in modo che utilizzi ui/initialize, appInfo e appCapabilities, e aggiungi il chiarimento sul livello di protocollo; il lavoro è completo quando l’esempio corrisponde all’handshake Apps documentato.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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).
Lingua principale
TypeScript
Stelle
2.9k
Fork
390
Merge medio
4h 35m
PR unite (30g)
13

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di modelcontextprotocol/ext-apps

Tutte le issue di modelcontextprotocol/ext-apps

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.