tinyhumansai/openhuman · error · anyhow::Error

unsupported MCP protocol version negotiated by server: {vers

Error message

unsupported MCP protocol version negotiated by server: {version}

What it means

During HTTP initialize handshake the server negotiated a `protocolVersion` that is not in `SUPPORTED_PROTOCOL_VERSIONS` (accepted: `2024-11-05`, `2025-03-26`, `2025-06-18`, `2025-11-25`), so the client refuses to continue on that session. MCP version negotiation expects the server to echo a supported client version or pick one it supports; an unknown version means the two builds cannot talk safely.

Source

Thrown at src/openhuman/mcp/http_client/client.rs:660

    async fn fetch_authorization_server_metadata(
        &self,
        issuer: &str,
    ) -> anyhow::Result<AuthorizationServerMetadata> {
        let trimmed = issuer.trim_end_matches('/');
        let oidc = format!("{trimmed}/.well-known/openid-configuration");
        if let Ok(metadata) = self.fetch_json::<AuthorizationServerMetadata>(&oidc).await {
            return Ok(metadata);
        }
        let oauth = format!("{trimmed}/.well-known/oauth-authorization-server");
        self.fetch_json::<AuthorizationServerMetadata>(&oauth).await
    }

    fn validate_protocol_version(&self, version: &str) -> anyhow::Result<()> {
        if SUPPORTED_PROTOCOL_VERSIONS.contains(&version) {
            Ok(())
        } else {
            anyhow::bail!("unsupported MCP protocol version negotiated by server: {version}");
        }
    }

    fn reset_session(&self) {
        let mut state = self.state.lock();
        state.initialized = false;
        state.session_id = None;
        state.initialize = None;
        state.cached_tools.clear();
        state.negotiated_protocol_version = LATEST_PROTOCOL_VERSION.to_string();
    }
}

#[derive(Debug, Clone)]
struct RequestOptions {
    initialize: bool,
    method_header: Option<&'static str>,
    name_header: Option<String>,

View on GitHub (pinned to 7491200858)

Solutions

Check the version string in the error against the supported list — if the server is newer, update OpenHuman to a build supporting that revision.
If you control the server, configure/pin it to negotiate one of the supported versions (ideally echo the client's offered `protocolVersion`).
Verify the initialize response is not being mangled by a proxy.
If the server is hopelessly incompatible, use a stdio wrapper or a bridging gateway that translates versions.

Defensive patterns

Strategy: fallback

Try / catch

match client.initialize().await {
    Err(e) if e.to_string().contains("unsupported MCP protocol version") => {
        // mark server incompatible: disable and surface an upgrade hint
        registry.disable(server_name)?;
    }
    other => other,
}

Prevention

Keep the client updated when adopting servers built against newer MCP spec revisions.
Pin server versions in lockstep with the client's supported protocol versions.
Log the negotiated version at initialize so mismatches are diagnosable later.

When it happens

Trigger: Connecting to an MCP server built against a newer (or much older) spec revision than this client supports; a server that ignores the client's offered version and replies with its own unsupported one; a broken gateway rewriting the initialize result.

Common situations: Server updated ahead of the client after a spec revision ships; experimental/custom MCP servers using draft version strings; version strings with different formatting (e.g. a bare date without the `YYYY-MM-DD` shape).

Related errors

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