tinyhumansai/openhuman · error · anyhow::Error

MCP stdio error: {err}

Error message

MCP stdio error: {err}

What it means

The stdio MCP server answered the JSON-RPC request with a response containing an `error` object, and the client surfaces it verbatim (`MCP stdio error: {err}` — the serialized JSON-RPC error with code and message). This is a well-formed protocol-level failure from the server itself, not a transport failure: the request reached the server and the server refused/failed it.

Source

Thrown at src/openhuman/mcp/config_servers/stdio.rs:244

                anyhow::bail!("stdio MCP server closed stdout while waiting for `{method}`");
            }
            let trimmed = response.trim();
            if trimmed.is_empty() {
                continue;
            }
            if !trimmed.starts_with('{') && !trimmed.starts_with('[') {
                tracing::debug!(
                    target: "[mcp_client::stdio]",
                    command = %self.command,
                    line = %trimmed,
                    "ignoring non-JSON stdout line from stdio MCP server"
                );
                continue;
            }
            let payload: Value = serde_json::from_str(trimmed)
                .with_context(|| format!("parsing stdio MCP response: {trimmed}"))?;
            if let Some(err) = payload.get("error") {
                anyhow::bail!("MCP stdio error: {err}");
            }
            return payload
                .get("result")
                .cloned()
                .ok_or_else(|| anyhow::anyhow!("stdio MCP response missing `result`: {payload}"));
        }
    }

    async fn send_notification_on_session(
        &self,
        session: &mut StdioSession,
        method: &str,
        params: Value,
    ) -> anyhow::Result<()> {
        let line = serde_json::to_string(&json!({
            "jsonrpc": "2.0",
            "method": method,
            "params": params,

View on GitHub (pinned to 7491200858)

Solutions

  1. Read the embedded JSON-RPC code/message — `-32602` means invalid params (fix the arguments), `-32700`/`-32603` indicate parse/internal errors on the server.
  2. Re-fetch `tools/list` and re-check the tool name and its `inputSchema` before retrying.
  3. If the server wraps an upstream API, fix the credential/rate-limit problem the message names.
  4. Pin the server package version if the error started after an update (e.g. `npx -y pkg@1.2.3`).

Example fix

// before
let result = stdio.call_tool("search", json!({ "query": "rust async" })).await?;

// after — align arguments with the tool's inputSchema from tools/list
let result = stdio.call_tool("search", json!({
    "query": "rust async",
    "max_results": 10, // param previously named "limit" before server update
})).await?;
Defensive patterns

Strategy: try-catch

Validate before calling

null

Try / catch

match stdio_client.call_tool(tool, args).await {
    Err(e) => {
        let msg = e.to_string();
        if msg.contains("-32602") { /* invalid params: fix args against inputSchema */ }
        else if msg.contains("Unknown tool") { /* refresh tools/list */ }
        else { return Err(e); }
    }
    ok => ok,
}

Prevention

When it happens

Trigger: `tools/call` with invalid arguments (server-side validation), calling a tool that does not exist on that server, auth-required tools without credentials, or any server-side internal error returned as a JSON-RPC error.

Common situations: Argument schema drift after a server update (renamed/now-required params); calling a tool with a stale name; upstream API inside the server failing (rate limit, expired token) and being mapped to a JSON-RPC error; protocol misuse like wrong method names.

Related errors

AI-assisted analysis of tinyhumansai/openhuman@7491200858 (2026-08-17). Data as JSON: /api/errors/8f4c166e342d9f3f. Report an issue: GitHub.