Problem
When an MCP server fails to connect, the log only shows:
WARN message="server unavailable" key=exodus-mcp type=remote status=failed
The connectRemote function in src/mcp/index.ts stores the actual error in lastStatus.error:
lastStatus={status: "failed"asconst,error: lastError.message}But the logWarning call only logs status.status (always the string "failed"), never status.error (the actual error message, e.g. "401 Unauthorized" or "Streamable HTTP error: ..."):
yield*Effect.logWarning("server unavailable",{ key,type: mcp.type,status: status.status})Impact
This makes debugging MCP connection failures extremely difficult. A token-expired 401, a network timeout, a TLS error, and a server misconfiguration all produce the identical log line status=failed with no distinguishing detail. We spent significant time theorising about SDK transport bugs when the actual cause was an expired bearer token returning 401 — something the error message would have revealed immediately.
Suggested fix
Include status.error in the logWarning call:
yield*Effect.logWarning("server unavailable",{ key,type: mcp.type,status: status.status,error: status.error??"unknown"})This is a one-line change that would have saved a lot of debugging time. The error field is already populated — it just needs to be logged.
Metadata
| Field | Value |
|---|
| CLI Version | 0.9.5 |
| Platform | darwin |
| Architecture | arm64 |
| OS Release | 25.5.0 |
| Category | improvement |
| Working Directory | editorial-intelligence |
| Session ID | ses_fe273aefdffeKVRGOtYcW574qX |
Problem
When an MCP server fails to connect, the log only shows:
The
connectRemotefunction insrc/mcp/index.tsstores the actual error inlastStatus.error:But the logWarning call only logs
status.status(always the string "failed"), neverstatus.error(the actual error message, e.g. "401 Unauthorized" or "Streamable HTTP error: ..."):Impact
This makes debugging MCP connection failures extremely difficult. A token-expired 401, a network timeout, a TLS error, and a server misconfiguration all produce the identical log line
status=failedwith no distinguishing detail. We spent significant time theorising about SDK transport bugs when the actual cause was an expired bearer token returning 401 — something the error message would have revealed immediately.Suggested fix
Include
status.errorin the logWarning call:This is a one-line change that would have saved a lot of debugging time. The
errorfield is already populated — it just needs to be logged.Metadata