What causes "MCP official registry returned HTTP {status}: {}" in tinyhumansai/openhuman?

On 429, back off and retry with fewer/longer-interval requests (reduce `limit`, avoid deep pagination).

MCP official registry returned HTTP {status}: {}

Error message

MCP official registry returned HTTP {status}: {}

What it means

A paginated search against the official MCP registry (list/search with `limit` and optional `cursor`) returned a non-2xx; the message includes status plus the first 200 chars of the body, and a `[mcp-official] search HTTP {status}` warn is logged. This is the list/search network call underlying registry browsing.

Source

Thrown at src/openhuman/mcp/registry/registries/mcp_official.rs:272

    let client = http_client()?;
    let url = format!("{}/v0/servers", base_url(config));
    let mut req = client.get(&url).header("Accept", "application/json");
    if !q.is_empty() {
        req = req.query(&[("search", q)]);
    }
    req = req.query(&[("limit", &limit.to_string())]);
    if let Some(c) = cursor {
        req = req.query(&[("cursor", c)]);
    }
    req = apply_auth(config, req);

    let resp = req.send().await.context("MCP official search failed")?;
    let status = resp.status();
    let body = resp.text().await.context("MCP official read failed")?;

    if !status.is_success() {
        tracing::warn!("[mcp-official] search HTTP {status}");
        anyhow::bail!(
            "MCP official registry returned HTTP {status}: {}",
            &body[..body.len().min(200)]
        );
    }
    Ok(body)
}

/// Walk the cursor chain forward starting from page 1 until we have the
/// cursor that, when sent with the next request, produces `target_page`.
///
/// Returns `Some(cursor)` to feed into the request for `target_page`, or
/// `None` if the cursor chain ran out before reaching `target_page`.
///
/// Bails after [`MAX_CURSOR_WALK_PAGES`] iterations to keep a single user
/// request from fanning into hundreds of upstream calls.
async fn walk_cursor_for_page(
    config: &Config,
    q: &str,

View on GitHub (pinned to 7491200858)

Solutions

On 429, back off and retry with fewer/longer-interval requests (reduce `limit`, avoid deep pagination).
On 401/403, refresh or clear the registry auth token.
On 5xx, retry after a delay; check the registry status.
If it persists, reproduce with curl using the same query/limit/cursor to isolate.

Defensive patterns

Strategy: retry

Try / catch

match search_page(q, limit, cursor).await {
    Err(e) if e.to_string().contains("HTTP 429") => {
        backoff_jitter().await;
        search_page(q, limit, cursor).await
    }
    other => other,
}

Prevention

Throttle and space registry searches; avoid crawling all pages rapidly.
Reuse returned cursors instead of re-searching from page 1.
Keep the registry auth token current if authenticated access returns 401/403.

When it happens

Trigger: Registry search when the service is down or rate-limiting (429/5xx), auth failures (401/403) with a configured token, or a malformed cursor supplied by a caller (400).

Common situations: Rate limits during aggressive pagination/crawling of the catalog; temporary registry outages; expired registry API token; query strings with special characters hitting a strict gateway.

Related errors

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