Inline MCP App rendering in Goose2

[aharvard]

Parent issue

• Parent issue: Implement MCP Apps in Goose2

Summary

Implement the session-bound catalog hydration and render-decision path that lets Goose2 choose between a normal tool card and an inline MCP App.

This work makes tools/list metadata the authoritative linkage source for app-backed tools and moves the app-render decision out of raw-output heuristics.

Sequence diagram

sequenceDiagram
    participant User
    participant UI as Goose2 UI
    participant Tauri as Tauri ACP Manager
    participant ACP as Goose ACP Server
    participant MCP as MCP Server
    participant Host as McpAppView Renderer

    UI->>Tauri: acp_prepare_session
    Tauri->>ACP: session/new
    ACP-->>Tauri: session/new result
    Tauri-->>UI: acp:session_bound
    UI->>Tauri: goose/tools
    Tauri->>ACP: goose/tools
    ACP->>MCP: tools/list
    MCP-->>ACP: tools/list result
    ACP-->>Tauri: goose/tools result
    UI->>UI: Cache tools/list metadata
    User->>UI: Send prompt
    UI->>Tauri: acp_send_message
    Tauri->>ACP: prompt
    ACP->>MCP: tools/call
    MCP-->>ACP: tools/call result
    ACP-->>Tauri: notifications/session/update
    Tauri-->>UI: acp:tool_result with rawOutput
    UI->>UI: Match tool result to cached tools/list metadata
    alt Matched tool metadata includes _meta.ui.resourceUri
        UI->>Host: Render McpAppView
        Host->>Tauri: acpReadResource
        Tauri->>ACP: goose/resource/read
        ACP->>MCP: resources/read
        MCP-->>ACP: resources/read result
        ACP-->>Tauri: goose/resource/read result
        Tauri-->>Host: HTML resource
        Host-->>UI: Mount sandbox iframe inline
    else No MCP app linkage
        UI->>UI: Render standard tool response
    end

Loading

This issue covers

• ACP session binding
• tools/list hydration after acp:session_bound
• per-session tool catalog caching
• preservation of canonical tool identity via catalogName
• app-render decision based on cached tools/list metadata
• resources/read for app-backed tools

Key rules

• tools/list metadata is the authoritative linkage source
• _meta.ui.resourceUri comes from cached tools/list, not from the tools/call result payload
• the render decision happens after the completed tool result is matched back to cached tools/list metadata for the same tool
• unmatched or non-app-linked tools should fail closed to standard tool rendering
• preserve catalogName as the canonical tool identity carried through UI title rewrites
• preserve rawOutput as structured app data delivered to the app, but not as the thing that decides whether the app path is taken

Acceptance criteria

• tools/list is fetched and cached after session binding
• the completed tool result is matched back to cached tool metadata
• Goose2 renders McpAppView only when cached metadata includes _meta.ui.resourceUri
• missing or unmatched catalog metadata falls back to standard tool rendering
• tool title rewrites do not break catalog matching

[aharvard]

taking another route