stderr output from MCP server confuses Roo's MCP server configuration view

[ksze]

Which version of the app are you using?

v3.7.8

Which API Provider are you using?

OpenRouter

Which Model are you using?

Claude 3.7 Sonnet

What happened?

When an MCP server spits output on stderr, Roo gets confused. It will show both signs that the MCP server is working and signs that the MCP server is not working. Below is an example involving the kagi MCP server. Numbers between parenthesis correspond to marked spots in red in the screenshots.

Signs that the MCP server is not working:

• Roo will display the stderr output (1) in the MCP server configuration view, plus a "Retry Connection" button.
• Roo will not show the panel that lists the tools and resources exposed by the MCP server. Contrast with the panel for the tavily-mcp MCP server (2).

Signs that the MCP server is working:

• Roo will still show a green dot (3) for the MCP server, indicating that it is connected.
• If I check the system prompt, the MCP server's tools are still listed (4).
• I can ask the LLM to use the MCP server in question and it will actually attempt to use the MCP server (5).

Steps to reproduce

1. Configure an MCP server that will output to stderr even totally benign INFO level log message - e.g. kagi (https://github.com/kagisearch/kagimcp);
2. Watch Roo show conflicting signs of whether the MCP server works or not.

Relevant API REQUEST output

**User:**

<task>
Search the web using the `kagi` MCP server to see how to properly configure VS Code for Microsoft C++ using the "C/C++ extention for VS Code".
</task>
<environment_details>
# VSCode Visible Files
../../../../.vscode-server/data/User/globalStorage/rooveterinaryinc.roo-cline/settings/cline_mcp_settings.json

# VSCode Open Tabs
../../../../.vscode-server/data/User/globalStorage/rooveterinaryinc.roo-cline/settings/cline_mcp_settings.json

# Current Time
3/1/2025, 2:23:19 AM (undefined, UTC-7:00)

# Current Context Size (Tokens)
(Not available)

# Current Mode
<slug>ask</slug>
<name>Ask</name>


NOTE: You are currently in 'Ask' mode which only allows read-only operations. To write files or execute commands, the user will need to switch to 'Code' mode. Note that only the user can switch modes.

# Current Working Directory (<censored>) Files
</environment_details>

---

**Assistant:**

<use_mcp_tool>
<server_name>kagi</server_name>
<tool_name>search</tool_name>
<arguments>
{
  "queries": [
    "Configure VS Code for Microsoft C++ with C/C++ extension step by step",
    "C/C++ extension setup guide for Visual Studio Code"
  ]
}
</arguments>
</use_mcp_tool>

---

**User:**

[use_mcp_tool for 'kagi'] Result:
Error: 401 Client Error: Unauthorized for url: https://kagi.com/api/v0/search?q=Configure+VS+Code+for+Microsoft+C%2B%2B+with+C%2FC%2B%2B+extension+step+by+step&limit=10
<environment_details>
# VSCode Visible Files
../../../../.vscode-server/data/User/globalStorage/rooveterinaryinc.roo-cline/settings/cline_mcp_settings.json

# VSCode Open Tabs
../../../../.vscode-server/data/User/globalStorage/rooveterinaryinc.roo-cline/settings/cline_mcp_settings.json

# Current Time
3/1/2025, 2:24:02 AM (undefined, UTC-7:00)

# Current Context Size (Tokens)
12,141 (19%)

# Current Mode
<slug>ask</slug>
<name>Ask</name>


NOTE: You are currently in 'Ask' mode which only allows read-only operations. To write files or execute commands, the user will need to switch to 'Code' mode. Note that only the user can switch modes.
</environment_details>

Additional context

Note that in the API request output, you see the kagi MCP server replying with "Error: 401 Client Error: Unauthorized". That's only because I'm out of search credit on the Kagi API platform. As far as the MCP server itself is concerned, it's actually up and running.

What I wish to see changed

Because the MCP server is actually up and running, and Roo can actually connect to it, Roo should still show the panel that lists the tools and resources of the MCP server. Also, there is no need to display the "Retry Connection" button because, like I said, Roo is actually connected to the MCP server. Regarding the question of whether or not to still display the stderr output in the MCP server configuration view, that's debatable and I have no preference.

[ksze]

BTW, I have created a related issue in the modelcontextprotocol/specifications repo because, frankly, I believe this is a point of ambiguity in the MCP specs: modelcontextprotocol/specification#177