Residual of #638, which closed with PR #685. Two of its three bullets shipped; this is the third.
What is missing
#638's acceptance criterion had three clauses. PR #685 delivered health-vs-connect failure separation (stella-mcp/src/client/health.rs) and the stderr ring (StderrTail), but not "knows when a tool list was truncated".
The signal is exposed and tested in stella-mcp, but nothing consumes it. Verified at 8a6babec:
rg -n "dropped_tool_count|over_advertising_servers" --type rust -g '!stella-mcp/**'
→ no matches
The accessors that exist and are unread:
McpClient::dropped_tool_count — stella-mcp/src/client.rs:468McpToolSet::over_advertising_servers — stella-mcp/src/toolset.rs:352McpToolSet::dropped_tool_count — stella-mcp/src/toolset.rs:371
PR #685's body concedes it: "#638's truncation rendering is a stella-cli/stella-tui change; the signal is exposed and tested in stella-mcp."
Why it matters
The real silent cap is MAX_TOOLS_PER_SERVER = 256 (stella-mcp/src/client.rs). An over-advertising server loses tools past it and nothing tells the operator — the model just silently has fewer tools than the server offers. (MAX_TOOL_PAGES is not the problem; it fails loudly with "cursor never terminated".)
Where to render
- Deck MCP tab —
stella-cli/src/command_deck.rs:1989 builds stella_tui::McpServerInfo; the tab currently surfaces only live/reconnecting/down. Likely a new McpServerInfo field.
- Text mode — next to, but NOT inside, the
failed_servers() loop at stella-cli/src/agent.rs:1485. That path renders as "server unavailable", which would be a lie here: the server is up and healthy, it just advertised more tools than we accept.
Acceptance
An over-advertising server produces a non-fatal, correctly-worded notice in both the deck's MCP tab and text mode, distinguishable from an unavailable server.
Note on #638's original text
#638's bullet C claimed dropped_tool_count/over_advertising_servers "do not exist anywhere in the tree". That was wrong when filed — both have existed since #551. Only the operator surface was ever missing.
Residual of #638, which closed with PR #685. Two of its three bullets shipped; this is the third.
What is missing
#638's acceptance criterion had three clauses. PR #685 delivered health-vs-connect failure separation (
stella-mcp/src/client/health.rs) and the stderr ring (StderrTail), but not "knows when a tool list was truncated".The signal is exposed and tested in
stella-mcp, but nothing consumes it. Verified at8a6babec:The accessors that exist and are unread:
McpClient::dropped_tool_count—stella-mcp/src/client.rs:468McpToolSet::over_advertising_servers—stella-mcp/src/toolset.rs:352McpToolSet::dropped_tool_count—stella-mcp/src/toolset.rs:371PR #685's body concedes it: "#638's truncation rendering is a stella-cli/stella-tui change; the signal is exposed and tested in stella-mcp."
Why it matters
The real silent cap is
MAX_TOOLS_PER_SERVER = 256(stella-mcp/src/client.rs). An over-advertising server loses tools past it and nothing tells the operator — the model just silently has fewer tools than the server offers. (MAX_TOOL_PAGESis not the problem; it fails loudly with "cursor never terminated".)Where to render
stella-cli/src/command_deck.rs:1989buildsstella_tui::McpServerInfo; the tab currently surfaces onlylive/reconnecting/down. Likely a newMcpServerInfofield.failed_servers()loop atstella-cli/src/agent.rs:1485. That path renders as "server unavailable", which would be a lie here: the server is up and healthy, it just advertised more tools than we accept.Acceptance
An over-advertising server produces a non-fatal, correctly-worded notice in both the deck's MCP tab and text mode, distinguishable from an unavailable server.
Note on #638's original text
#638's bullet C claimed
dropped_tool_count/over_advertising_servers"do not exist anywhere in the tree". That was wrong when filed — both have existed since #551. Only the operator surface was ever missing.