MCP App View bridge and bootstrap in Goose2

[aharvard]

Parent issue

• Parent issue: Implement MCP Apps in Goose2

Summary

Implement the renderer and sandbox bridge that let Goose2 host a real MCP App inline once the app-backed render path has already been selected.

This work makes McpAppView responsible for rendering, initialization, host context, proxying app requests back through ACP, and handling host interaction requests from the app view.

Out of scope for this issue

• extra display modes beyond inline. See Display Modes
• model context updating as a supported end-to-end feature. See Requests (View → Host). This section includes ui/update-model-context.

These features are explicitly out of scope for this issue, even if partial plumbing already exists.

Sequence diagram

sequenceDiagram
    participant UI as Goose2 UI
    participant Host as McpAppView Renderer
    participant Proxy as Sandbox Proxy
    participant View as MCP App View
    participant Tauri as Tauri ACP Manager
    participant ACP as Goose ACP Server
    participant MCP as MCP Server

    UI->>Host: Mounted McpAppView
    Host->>Proxy: Load sandbox proxy iframe
    Proxy-->>Host: iframe onLoad
    Host->>Proxy: ui/notifications/sandbox-resource-ready
    Proxy->>View: Write app HTML into inner iframe
    View->>Proxy: ui/initialize
    Proxy->>Host: Forward ui/initialize
    Host-->>Proxy: ui/initialize result with hostContext
    Proxy-->>View: Forward ui/initialize result
    View->>Proxy: ui/notifications/initialized
    Proxy->>Host: Forward initialized notification
    Host->>Proxy: ui/notifications/tool-input
    Host->>Proxy: ui/notifications/tool-result
    alt App requests host-proxied MCP methods
        View->>Proxy: MCP request
        Proxy->>Host: Forward MCP request
        Host->>Tauri: ACP invoke
        Tauri->>ACP: goose/... request
        ACP->>MCP: MCP request
        MCP-->>ACP: MCP result
        ACP-->>Tauri: goose/... result
        Tauri-->>Host: ACP result
        Host-->>Proxy: MCP result
        Proxy-->>View: Forward MCP result
    end
    alt App sends host interaction requests
        View->>Proxy: ui/message open-link or download-file request
        Proxy->>Host: Forward host request
        Host-->>Proxy: Result
        Proxy-->>View: Forward result
    end

Loading

This issue covers

• sandbox proxy load
• delivered HTML/CSP/permissions
• ui/initialize
• hostContext
• ui/notifications/initialized
• tool input/result delivery
• host-proxied MCP requests back through ACP
• host interaction requests such as open-link

Key rules

• McpAppView is the renderer/bridge layer
• it should not be responsible for deciding whether a tool is app-backed
• the app should boot from delivered resource HTML and initiate ui/initialize
• preserve the distinction between:
  • McpAppView Renderer = host-side React renderer
  • MCP App View = iframe-side app
• host interaction requests should route through the renderer/bridge path

Acceptance criteria

• McpAppView receives a resolved app-linked catalog entry
• the app resource HTML is loaded via resources/read
• the sandbox proxy writes the HTML into the inner iframe
• the MCP App View sends ui/initialize
• the renderer returns hostInfo, hostCapabilities, and hostContext
• tool input and tool result notifications reach the app
• host-proxied MCP requests route through ACP and back successfully
• host interaction requests route through the bridge and return results to the app view

[aharvard]

taking another route