Repository navigation
feat(mcp): surface degraded MCP server status instead of silently reporting 0 tools #154
Description
Activity
I traced this through the current MCP init path. The contradictory log comes from a real error being converted into a zero-tool success before
server_infois written.Relevant path:
crates/aura/src/mcp.rsinitialize_from_config()logs"{server_name} - Connected successfully, {tools_count} tools discovered"for anyOk(tools_count)returned byconnect_and_discover_tools().connect_http_streamable()callstry_connect_http_streamable(). For 401-ish errors it returnsErr(McpInitError(...)), but for other failures it does:warn!(" HTTP Streamable MCP connection failed: {}", e);Ok(0)
- That
Ok(0)is indistinguishable from a valid MCP server that connected and legitimately returned an emptytools/listresponse. Soinitialize_from_config()recordsConnectionStatus::Connected,tools_count: 0, and emits the misleading success line.
I think the smallest safe fix is to stop using
Ok(0)for transport/discovery failures. Lettry_connect_http_streamable()errors bubble asErr(BuilderError::McpInitError(...)), including connection refused, timeout, closed channel, unexpected content type, and non-401 HTTP failures. A real empty server should only be represented byOk(0)afterclient.discover_tools().awaitsucceeds and returns an empty list.Suggested acceptance tests:
- HTTP streamable server returns 401 during initialize/list-tools:
server_info["pagerduty"].statusisFailed(...), notConnected, and noConnected successfully, 0 tools discoveredlog is emitted. - HTTP streamable endpoint is unreachable or closes the transport: same
Failed(...)status, with a reason containing the connection/transport error. - HTTP streamable server initializes and returns an empty
toolsarray: status remainsConnectedwithtools_count == 0. - Summary logs count failed connections separately from successful zero-tool servers.
For the SSE/UI part, Aura already has
ConnectionStatusandserver_info, so the event can be a thin projection of that state rather than a separate health model. A shape likeaura.mcp_statuswith{ server_name, transport, status: "connected" | "failed", tools_count, reason }would cover the user-facing distinction this issue asks for.If useful, I can help turn this into a focused patch or regression-test packet. Contact: jackshao1981@gmail.com. No payment details needed in the issue thread.
- added 7 commits that reference this issue
on Jun 5, 2026 - added a parent issue
on Jun 10, 2026 - added 2 commits that reference this issue
on Jun 11, 2026 - added a commit that references this issue
on Jun 12, 2026 - added 2 commits that reference this issue
on Jun 12, 2026
Summary
When an MCP server connection fails (auth errors, connectivity issues, etc.), Aura currently swallows the failure and reports
Connected successfully, 0 tools discovered. This makes a degraded MCP server indistinguishable from one that simply has no tools, leaving users unaware of the problem.Current Behavior
When an MCP server fails to connect (e.g., 401 auth error), the logs show the error but then contradict it:
The server appears fully functional with no tools to the end user.
Expected Behavior
Connected successfullylog should not be emitted when the connection actually failed — this is a bugaura.mcp_statusSSE event or similar mechanism)