ACP: Surface agent-advertised mcpCapabilities and promptCapabilities in the UI

[julianromli]

Problem or Opportunity

During the ACP initialize handshake, the agent advertises its capabilities in AgentCapabilities. Two of those fields are parsed and typed on the renderer, but never read by any code:

src/renderer/lib/acp-api.ts:74-75:

mcpCapabilities?: { http?: boolean; sse?: boolean } | null
promptCapabilities?: { image?: boolean; audio?: boolean; embeddedContext?: boolean } | null

Grepping the renderer for mcpCapabilities and promptCapabilities outside the type definition returns zero reads. Consequences:

1. MCP transport filtering is impossible. The user cannot tell whether the connected agent accepts http/sse MCP servers (relevant to ACP: User-managed MCP server list injected into agent sessions (session/new) #287, which proposes capability-aware injection). Today an http/sse MCP entry would be sent blindly and either ignored or rejected by the agent with no UI signal.

2. Multimodal prompt support is invisible. promptCapabilities.image/audio/embeddedContext are never surfaced, so the chat input bar always treats input as text-only. If an agent supports image prompts, the user has no way to attach one (related to ACP: Render non-text content blocks (image/audio/resource/resource_link) instead of placeholder #360, which is about rendering inbound non-text content; this issue is about the outbound/prompt side).

Proposed Solution

1. Surface mcpCapabilities in the MCP management UI. When ACP: User-managed MCP server list injected into agent sessions (session/new) #287 lands, the MCP server list/filter should show a badge or icon indicating whether the active agent supports http/sse transports, and skip/disabled-mark entries whose transport isn't supported (with a tooltip explaining why). This is already listed under "Capability-aware injection" in ACP: User-managed MCP server list injected into agent sessions (session/new) #287's success criteria — track it here as the renderer-side read of the capability.

2. Surface promptCapabilities in the chat input bar.

   • Show an attachment affordance (paperclip / image icon) when promptCapabilities.image or .audio is true.
   • Gate the affordance behind the capability so it never appears for text-only agents.
   • When the user attaches media, build the appropriate non-text ContentBlock (image/audio) for session/prompt instead of a plain text block.

3. Reflect capabilities in AgentHeader. Show a compact capability summary (e.g. small icons) so the user knows at a glance what the connected agent supports.

Success Criteria

• mcpCapabilities.http/.sse are read and used to filter/skip MCP server entries per the active agent (ties into ACP: User-managed MCP server list injected into agent sessions (session/new) #287).
• promptCapabilities.image/.audio/.embeddedContext are read and gate the chat input's attachment affordance.
• Attaching media when supported produces a non-text ContentBlock in session/prompt.
• AgentHeader (or equivalent) surfaces the agent's capability profile.

Additional Context

• Type definitions: src/renderer/lib/acp-api.ts:74-75.
• Capability is parsed from AgentCapabilities in InitializeResponse and stored in agents[agentId].capabilities (src/renderer/stores/acp-store.ts).
• Related: ACP: User-managed MCP server list injected into agent sessions (session/new) #287 (MCP UI — this issue supplies the capability-aware read side), ACP: Render non-text content blocks (image/audio/resource/resource_link) instead of placeholder #360 (inbound non-text content rendering — the outbound counterpart).
• Per the latest ACP spec, mcpCapabilities also includes an acp field for MCP-over-ACP native transport (see ACP: Config-based live session resume across app restarts #361).