Capability negotiation for MCP Apps in Goose2

[aharvard]

Parent issue

• Parent issue: Implement MCP Apps in Goose2

Summary

Implement the MCP Apps capability handshake between Goose2, Goose ACP, and the downstream MCP server.

This work makes Goose2 explicitly opt into MCP Apps support and makes Goose ACP advertise the MCP Apps extension downstream only for clients that actually support it.

Sequence diagram

sequenceDiagram
    participant UI as Goose2 UI
    participant Tauri as Tauri ACP Manager
    participant ACP as Goose ACP Server
    participant MCP as MCP Server

    UI->>Tauri: initialize
    Tauri->>ACP: initialize
    ACP->>ACP: Parse Goose2 capability metadata
    ACP->>MCP: initialize
    MCP-->>ACP: initialize result
    ACP-->>Tauri: initialize result
    Tauri-->>UI: ACP transport ready

Loading

This issue covers

• Goose2 ACP initialize
• clientCapabilities.meta["com.block.goose2"]
• Goose ACP parsing of that metadata
• downstream MCP initialize
• conditional advertisement of the MCP Apps extension

Key rules

• Goose2 declares the MCP Apps capability
• Goose ACP translates it
• only then does Goose advertise the MCP Apps extension in its MCP initialize request to the downstream MCP server
• text/TUI clients remain on the non-MCP-App path

Open question

• clientCapabilities.meta is ACP-defined, but com.block.goose2 is our custom namespaced envelope inside it
• we should decide whether com.block.goose2 is the right long-term namespace and payload shape, or whether this should be generalized if multiple desktop clients may eventually declare the same MCP Apps capability

Acceptance criteria

• Goose2 sends clientCapabilities.meta["com.block.goose2"]
• Goose ACP detects the MCP Apps capability only from client-declared metadata
• downstream MCP initialize includes the MCP Apps extension only for that session/client path
• text/TUI clients remain on the non-MCP-App path

[aharvard]

taking another route