MCP client
Claude Code — connect Attensira over OAuth with no key to paste
Add the Attensira MCP server to Claude Code with one command, authenticate in the browser, and pick a workspace. No secret ever touches a config file.
Karl-Gustav Kallasmaa, Founder & CEOLast updated What you configure
The exact settings, as our documentation publishes them.
claude mcp add --transport http attensira https://mcp.attensira.com/mcp
Connecting it
In order, with the reason each step exists rather than only the instruction.
- 1
Add the server with no credential
Run claude mcp add with the http transport and the server URL. Nothing secret is supplied at this point, which is the whole reason to prefer OAuth here — there is no key to leak into a committed config file.
- 2
Authenticate from inside Claude Code
Run /mcp, select attensira, and choose to authenticate. A browser opens, you sign in, and the callback returns to a local port Claude Code is listening on. Two instances can authenticate at the same time, because each listens on its own ephemeral loopback port.
- 3
Choose the workspace at the consent screen
The consent screen names the application, the workspace and the access being requested. A connection reaches exactly one workspace and cannot be moved afterwards, so read all three before approving.
- 4
Confirm with get_account
Verify with claude mcp list, then ask Claude to call get_account. A successful reply names your workspace without you having supplied a workspace id, which confirms the credential is bound correctly.
What it lets you do
- Reads your tracking data in the terminal where the work is happening — which prompts are losing, which of your pages get cited, which domains the models lean on.
- Changes the workspace in the same conversation when the connection carries write access, including adding prompts and creating or running automations.
- Answers the awkward question of which workspace a credential points at, because get_account returns it without any workspace id in the request.
What it cannot do
An integration page that lists only capabilities is an advertisement. This is the half you are evaluating.
- An assistant granted write access can delete prompts and automations and can spend credits, so a read-and-write connection is a workspace credential rather than a read token and should be approved with that in mind.
- A connection reaches exactly one workspace and cannot be retargeted afterwards. Working across two means connecting twice as two server entries, not switching one back and forth.
- Scope is fixed when you approve the connection and cannot be widened later. A write tool failing with an insufficient-scope error is not fixed by reconnecting with the same access — the connection has to be revoked and redone.
Claude Code is the client this integration was most obviously built for, because the audience it serves already lives in a terminal next to the repository the fix will land in. Connecting takes one command and a browser prompt, and no secret is created at any point.
Why OAuth rather than a key here
Both credentials work against the same endpoint and neither is being deprecated. On a laptop with a browser, OAuth is straightforwardly better for three reasons that have nothing to do with preference.
There is no key to paste, so there is no key to accidentally commit. The token is managed by the client and refreshed silently, so nothing expires in the middle of a session. And revoking one client leaves every other one working, which a shared key does not.
The case for a key is real and narrow: a build machine, a container, anything where nothing can complete a browser sign-in. That is why keys are supported rather than discouraged, and it is not the situation you are in when you are running Claude Code interactively.
The sequence
Add the server with the http transport and the URL, and supply nothing else. Then run /mcp inside Claude Code, pick the entry, and authenticate. The browser opens, you sign in, you choose a workspace, and the callback comes back to a loopback port the client is already listening on.
Adding --scope user makes the server available across every project instead of the one you happen to be in, which is usually what you want for something you will reach for from wherever you are working.
If you run several instances at once, they do not conflict: each authenticates on its own ephemeral port and both are accepted.
Read the consent screen
Three things are named there — the application, the workspace, and the access being requested — and all three matter.
Read access covers metrics, prompts, pages, sessions, automations and account details. Read and write adds everything that changes the workspace or spends credits: adding prompts, creating and running automations, deleting things, asking the agent. Most clients request read and write, because a client that can only read cannot do half of what people connect it for.
The consequence is worth being blunt about. An assistant with write access can delete a prompt along with its history, delete an automation along with its run history, and spend credits. That is a workspace credential, and it should be approved with the same care you would give one.
One connection, one workspace
The credential names the workspace, and no tool takes a workspace id. A URL that cannot express a workspace cannot be pointed at somebody else's, which is a pleasant security property and also a constraint: a connection cannot be moved, so working across two workspaces means two server entries with two connections.
Scope is decided at approval and cannot be widened afterwards either. If a write tool comes back with an insufficient-scope error, the credential is valid and simply may not do that — reconnecting with the same access changes nothing, and the fix is to revoke and redo it with wider access.
Confirming it worked
The best smoke test is asking Claude to call get_account. It returns the organisation, the project and the plan, and it does so without you having supplied a workspace id anywhere. That single fact confirms the credential is bound to the workspace you think it is, which is the thing most likely to be wrong in a fresh setup.
A habit for repositories
Because Claude Code is usually running inside a checkout, it is worth being deliberate about scope. A server added per project is visible only there; a server added with the user scope follows you everywhere. Neither writes a secret, so the choice is about convenience rather than safety — but adding it per project in a repository you share means every collaborator sees the entry and authenticates as themselves, which is generally the outcome you want.
Questions people ask
- Do I need an API key for Claude Code?
- No, and you should not use one on a machine with a browser. OAuth puts no secret on disk, and revoking one client leaves the others working. A key is for callers that cannot complete a browser sign-in.
- Can I make the server available in every project?
- Yes. Add --scope user when adding it, rather than adding it per project.
- Can two Claude Code instances be authenticated at once?
- Yes. Each listens on its own ephemeral loopback port and both are accepted.
- How do I know the connection reached the right workspace?
- Ask Claude to call get_account. It names the org, project and plan, and it does so without you supplying a workspace id, because the credential names the workspace.
- What happens when the token expires?
- Access tokens last 60 minutes and refresh silently. You re-approve every couple of months, and a connection unused for 60 days or older than 180 days stops refreshing and asks you to sign in again.
Sources
Every factual statement above, with the page it came from and the date that page was read.
Attensira's connect documentation states that two Claude Code instances can authenticate at the same time, each listening on its own ephemeral loopback port.
docs.attensira.com · retrieved
“Two Claude Code instances can authenticate at the same time. Each listens on its own ephemeral loopback port, and both are accepted.”
Attensira's MCP overview states that OAuth access tokens last 60 minutes and refresh silently, with re-approval every couple of months, while static API keys never expire until revoked.
docs.attensira.com · retrieved
“Access tokens last 60 minutes and refresh silently; re-approval every couple of months”
Attensira's MCP overview states that an assistant granted write access can delete prompts and automations and can spend credits, and that either credential should be treated as a workspace credential rather than a read token.
docs.attensira.com · retrieved
“Treat either credential as a workspace credential, not a read token.”