Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto Apto para principiantes
  • ¿Algo no está bien?
#634 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@Michael-WhiteCapData ya está trabajando en esto.

Desde el 18/9/2026.

  • #779 de @Michael-WhiteCapData — abierto

Evaluación

Dificultad
1/5
Tiempo estimado
Menos de una hora
Aptitud para principiantes
88/100
Tipo de issue
Documentación
Claridad
Bien especificado
Estado de actividad
Tranquilo
Stack tecnológico
javascript, typescript
Área
documentation

Línea de trabajo

Edita specification/2026-01-26/apps.mdx en la sección Transport Layer, alrededor de las líneas 455–465, y compáralo con App Capabilities en la sección ui/initialize y con specification/draft/apps.mdx. Actualiza el ejemplo para que use ui/initialize, appInfo y appCapabilities, y añade la aclaración sobre la capa de protocolo; el trabajo estará terminado cuando el ejemplo coincida con el handshake de Apps documentado.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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).
Lenguaje dominante
TypeScript
Estrellas
2.9k
Forks
394
Merge medio
5 h 37 min
PR fusionados (30 d)
7

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de modelcontextprotocol/ext-apps

Todos los issues de modelcontextprotocol/ext-apps

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.