Skip to main content
Most MCP failures are one of five things: a malformed key, a client that cannot speak the transport, a revoked key, a model that was never queried, or a request that ran past the upstream budget. Each has a distinct signature.

​
Why am I getting a 401?

Your Authorization header is missing, misspelled, or does not match the expected key shape. The server checks the format before it makes any upstream call, so a truncated paste fails instantly — the request never reaches your workspace. The response body is exactly:
401 response
with the header:
Response header
A valid key matches ^atn_live_[0-9a-fA-F]{32}$ — the literal prefix atn_live_ followed by exactly 32 hexadecimal characters. Count them. Copying from a terminal that soft-wraps, or from a config file where an editor trimmed the line, is the usual cause of a key that is one or two characters short. Then check the surrounding shape. The header value must be Bearer plus the key, with a single space and no quotes around the key itself. If your config uses an environment variable, confirm the variable is actually set in the environment the client runs in — a GUI app launched from the dock does not inherit a variable exported in your shell profile. Print it with echo ${ATTENSIRA_API_KEY:0:9} to confirm the prefix without exposing the rest. To separate a network problem from an auth problem, hit the unauthenticated health path: curl -i https://mcp.attensira.com/healthz. If that answers and your authenticated call does not, the key is the problem.

​
Why can’t my client see the tools?

The server connected but no tools appeared, or the client reports the server as failed with no detail. This is almost always transport: Attensira speaks Streamable HTTP only, and a client that speaks stdio alone cannot reach an HTTPS endpoint directly. Clients that connect natively include Claude Code, Claude Desktop, Claude.ai, Cursor, VS Code + Copilot, Windsurf, Cline, Codex CLI, ChatGPT and n8n. Zed and older builds of several others launch local processes only, and need the mcp-remote bridge:
Shell
The bridge requires Node.js, and its first run downloads the package, so give it a few seconds before deciding it failed. Full per-client configuration is in Connect a client. If your client does connect natively and still shows nothing, check two more things. Some clients only load servers added before the conversation started — open a new chat. And some cache the tool list, so a restart or an explicit refresh in the MCP panel is needed after editing config. A healthy connection lists 15 tools.

​
Why did my key stop working?

A key that worked yesterday and 401s today has been revoked, either by you or by a workspace admin at app.attensira.com/settings/developer. Revocation takes effect immediately for every client using that key. Keys cannot be recovered. Only a hash is stored, so there is no screen anywhere that will show you the original value again — not for you, and not for support. The fix is always to mint a new key and update every client that used the old one.
When you rotate, update every place the key lives: shell profiles, claude_desktop_config.json, ~/.cursor/mcp.json, ~/.codex/config.toml, VS Code secret storage, n8n credentials, and any connector configured in Claude.ai or ChatGPT. A client left on the old key fails silently in the background.
If nobody revoked anything, re-read the 401 section — a config edit that dropped a character produces the identical error.

​
Why does a model show no data?

Three different states look like “nothing” and mean very different things. Read the fields before concluding the model failed you.
  • tracked: false — this model is not configured for your workspace, so it was never queried. Reporting it as 0% would invent a failure that did not happen. A new workspace tracks two models by default, chatgpt and perplexity; add more in the dashboard.
  • readable: false — no reader exists for that surface, so Attensira cannot collect answers from it at all. google_ai has no API reader, for example.
  • value: null — not measured in this window. Null is not zero.
  • value: 0 with n > 0 — a real, measured zero. The model was asked n times and never named you. That is a finding.
Deltas work the same way. A delta is {value, real} and must pass a two-proportion z-test at 95% before it is reported. Below that noise floor you get {real: false, value: null}, which means “no change we can prove” — never “no change”. Sampling depth also explains thin results: each prompt × model × country runs at most once per workspace-local calendar day, with n=1 on Starter and n=3 on Growth and Business. A prompt added an hour ago may have no readings until the next day’s run. Failed runs are stored but excluded from n. For the full reading guide, see Reading the numbers.

​
Why is my request timing out?

The upstream budget is 35 seconds. A tool call that needs longer than that upstream is cut off, and your client reports a timeout or an aborted stream rather than a partial answer. The usual cause is an over-broad query: a wide date range across every prompt, page and source at once. Narrow it — one area at a time, a shorter window, a filter on a single topic or model — and the same question usually answers in a fraction of the budget. Long-running agent work has its own path. ask may return status: "running" instead of a result; that is not a failure. Poll get_session for the outcome, passing include: ["events"] when you want the intermediate steps. Do not re-issue ask while a session is running — it spends credits again. Other server limits worth knowing when you are debugging a stalled connection: request header timeout 10 seconds, full request read 60 seconds, idle connection 120 seconds, and a maximum response size of 8 MiB. A response that would exceed 8 MiB is a signal to page or filter the query rather than retry it.
Still stuck? Start from Connect a client and reproduce with the exact block for your client, then check https://mcp.attensira.com/healthz to rule out reachability.