feat(desktop): show MCP connection and agent-tool availability in the UI

[matthewdonsemail-lab]

User experience

A Buzz Desktop user can configure an MCP server or Project connection and restart the app, but the agent session gives no reliable, user-visible answer to two basic questions: did the server load, and are its tools available to this agent? In the Playwright case, the server can run successfully while the agent exposes zero Playwright tools.

Reproduction

1. Configure a stdio MCP server such as @playwright/mcp in the project/agent configuration.
2. Restart Buzz Desktop and start an agent session.
3. Ask the agent which tools are available, or attempt to call a tool from the configured server.
4. Observe that the UI does not show a per-server state, discovered tool list, binding to the current agent, or actionable startup error.

Expected behavior

The Project or agent UI should show each configured MCP connection with a clear state such as configured, starting, ready, or failed. A ready connection should show the discovered tool names and the agents/projects to which it is bound. A failure should include an actionable diagnostic and a retry/test action. The active agent view should expose which external tools were injected at session launch.

Actual behavior

The user receives no authoritative UI feedback. A configured server may be healthy when launched manually, yet its tools are absent from the agent session. The only practical detection is asking the agent or inspecting logs, and the current workaround requires planning all browser operations into one shell invocation.

Impact

This makes MCP setup appear broken even when the server process is healthy, increases setup time, and causes users to fall back to fragile shell workflows for browser automation and other long-running integrations.

Source references

• desktop/src-tauri/src/managed_agents/agent_snapshot.rs - documents machine-local runtime fields while portable agent snapshots omit MCP configuration details.
• desktop/src-tauri/src/managed_agents/agent_snapshot_tests.rs - regression assertions explicitly require MCP toolset/command fields to be absent from snapshots.
• desktop/src-tauri/src/managed_agents/runtime.rs - derives and injects the built-in MCP command into the spawned runtime but does not provide a user-facing discovered-tool state.
• desktop/tests/e2e/config-bridge-screenshots.spec.ts - tests MCP server rendering in configuration discovery, but not readiness, agent binding, or session-level tool visibility.

Suggested acceptance criteria

• Project/agent configuration displays every MCP connection and its current lifecycle state.
• The UI can test or retry a connection and surfaces stderr/startup failures without exposing secrets.
• Successful tools/list discovery is visible, with tool names and the active agent binding.
• The active agent/session view indicates which MCP tools were injected.
• E2E coverage verifies ready, failed, empty-tool, and unbound states.

Related

• feat(desktop): MCP servers defined in .mcp.json are not visible to agent sessions #4852 - configured MCP servers are not visible to agent sessions.
• feat(desktop): child processes spawned by agent shell commands are killed when the shell exits — need configurable keep-alive toggle #4853 - shell child processes are killed when the shell exits.
• feat(desktop): add Project connection setup #4588 - Project-owned MCP connection setup.

[wolfyy970]

I am treating this as the observability half of the binding work. The UI needs to separate connection health from agent-session attachment.

#4588 already exposes Project connection test state and discovered tools. A connection can pass initialize and tools/list and still not have been included in a particular agent launch. The agent view therefore needs to show whether the current connection generation is unbound, requires restart, was injected, or failed at launch. I will use this issue for the ready, failed, empty-tool and unbound acceptance states so a green Project probe never implies that the agent received the tools.