Surface per-server MCP Apps capability on McpServersLoadedServer / SessionMcpServerStatusChangedData

[colbylwilliams]

Summary

McpServersLoadedServer (from session.mcp_servers_loaded) and SessionMcpServerStatusChangedData (from session.mcp_server_status_changed) describe each MCP server's name, status, transport, source, plugin info, and error, but carry nothing indicating whether that specific server is MCP Apps (SEP-1865) capable (i.e. exposes UI resources). A consumer that models capability per server has no direct signal at that granularity.

Current state

MCP Apps capability is observable at two other granularities today, just not per-server:

• Session-wide — CapabilitiesChangedUI.mcp_apps ("Whether MCP Apps (SEP-1865) UI passthrough is now supported") and session_has_mcp_apps.
• Per-tool — tool definition metadata ui ("present for MCP tools with MCP Apps support").

The per-server status types, however, expose no equivalent:

pub struct McpServersLoadedServer {
    pub error: Option<String>,
    pub name: String,
    pub plugin_name: Option<String>,
    pub plugin_version: Option<String>,
    pub source: Option<McpServerSource>,
    pub status: McpServerStatus,
    pub transport: Option<McpServerTransport>,
    // no MCP-Apps capability field
}

Consequence

A consumer that wants to advertise, in its own surface, which configured MCP servers offer App/UI experiences has to infer it indirectly — e.g. by scanning every tool of every server for ui metadata — instead of reading a per-server flag. The capability granularity (session / tool) doesn't line up with a per-server model.

Suggested fix

Add an optional per-server MCP-Apps capability flag to McpServersLoadedServer (and ideally SessionMcpServerStatusChangedData), so consumers can read App-capability at the server granularity directly. Alternatively, if the intended model is that App capability is strictly per-tool, documenting that explicitly on these types would resolve the ambiguity.