> ## Documentation Index
> Fetch the complete documentation index at: https://docs.attensira.com/llms.txt
> Use this file to discover all available pages before exploring further.

# MCP troubleshooting

> Fix 401s, missing tools, revoked keys, empty model results, and timeouts on the Attensira MCP server.

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:

```json 401 response theme={null}
{"error":"missing or malformed Authorization: Bearer atn_live_<32 hex>"}
```

with the header:

```http Response header theme={null}
WWW-Authenticate: Bearer realm="attensira", error="invalid_token"
```

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:

```bash Shell theme={null}
npx -y mcp-remote https://mcp.attensira.com/mcp \
  --header "Authorization: Bearer ${ATTENSIRA_API_KEY}"
```

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](/mcp/connect).

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](https://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.

<Warning>
  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.
</Warning>

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](/measure/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.

<Note>
  Still stuck? Start from [Connect a client](/mcp/connect) and reproduce with the exact block for your client, then check `https://mcp.attensira.com/healthz` to rule out reachability.
</Note>