MCP servers incorrectly shown as 'failed' when stderr contains non-error output

Description

Claude Code UI shows "X MCP servers failed" message even when the servers are running correctly. The issue is that any output to stderr from an MCP server is interpreted as an error, regardless of whether it's an actual error, a warning, or just informational output.

Steps to Reproduce

1. Install and enable the context7 plugin (from claude-plugins-official)
2. Start Claude Code
3. Observe "2 MCP servers failed" message in the UI

Expected Behavior

MCP servers that successfully connect and respond to tool calls should not be marked as "failed".

Actual Behavior

The UI shows "2 MCP servers failed" even though:

• The servers successfully connected
• The servers are responding to tool calls correctly
• There are no actual errors

Debug Log Evidence

The debug log shows these as [ERROR]:

2026-01-12T09:19:33.356Z [ERROR] MCP server "plugin:context7:context7" Server stderr: WARNING: Using default CLIENT_IP_ENCRYPTION_KEY.
2026-01-12T09:19:33.431Z [ERROR] MCP server "plugin:context7:context7" Server stderr: Context7 Documentation MCP Server v2.1.0 running on stdio

However:

1. The first message is a WARNING (not an error) about an optional encryption key
2. The second message is just the startup banner - completely normal informational output

Root Cause Analysis

Claude Code appears to log ALL stderr output from MCP servers at [ERROR] level, then counts these as "failed" servers in the UI. This is incorrect because:

1. Many programs write informational messages to stderr (startup banners, warnings, progress info)
2. stderr is conventionally used for diagnostic output, not exclusively for errors
3. The MCP server connection was actually successful (verified by subsequent tool calls working)

Suggested Fix

Options to consider:

1. Don't count stderr output as failures - Only mark servers as "failed" if:

• The process exits with non-zero code
• The MCP handshake/initialization fails
• The server stops responding to requests

1. Log stderr at DEBUG/WARN level instead of ERROR level, unless the server actually fails to connect

1. Parse stderr content to determine if it's actually an error (look for "error", "fatal", "failed" keywords)

Environment

• Claude Code version: v2.1.5
• OS: macOS Darwin 25.2.0 (Apple Silicon)
• Plugins affected: context7, potentially others that write to stderr

Screenshots

The UI shows "2 MCP servers failed" with red indicator, but running ps aux | grep mcp confirms all servers are running and tool calls work correctly.

Workaround

This is a cosmetic issue only. The servers work correctly despite the error message. Users can safely ignore the "failed" indicator if their MCP tools are functioning.