MCP client
Cursor — a three-line mcp.json that carries no secret
Install the Attensira MCP server in Cursor with a one-click link or a three-line project config, then authenticate in the browser.
Karl-Gustav Kallasmaa, Founder & CEOLast updated What you configure
The exact settings, as our documentation publishes them.
// .cursor/mcp.json
{
"mcpServers": {
"attensira": {
"url": "https://mcp.attensira.com/mcp"
}
}
}
Connecting it
In order, with the reason each step exists rather than only the instruction.
- 1
Add the server, by link or by file
Attensira publishes a one-click install link that opens Cursor and prompts you to add the server. It writes the URL and nothing else — no key, and nothing is read or transmitted. By hand, create .cursor/mcp.json in the project or the same file under your home directory for every project.
- 2
Reload and authenticate
Reload Cursor and open Settings, then MCP. The entry shows as needing authentication. Click through it, sign in, pick a workspace, and the tool count fills in.
- 3
Keep the file secret-free
With OAuth there is no secret in the file, which is what makes the in-repo path safe. A key pasted into a committed config is a leaked key — assume it is public the moment it is pushed, revoke it, and mint a new one.
- 4
Verify the workspace
Ask Cursor to call get_account. It answers with the organisation, project and plan bound to the credential, without a workspace id appearing anywhere in the request.
What it lets you do
- Gives the editor the workspace's tracking data while somebody is editing the page the data is about.
- Puts a project-scoped configuration in the repository safely, because with OAuth the file contains only a URL.
- Supports both project-level and global configuration, so a server can be added once for every project rather than per checkout.
What it cannot do
An integration page that lists only capabilities is an advertisement. This is the half you are evaluating.
- The configuration file lives inside a repository, so anything secret placed in it is shared with everyone who can read the repository. That is a property of the file, not of the client, and OAuth is the way around it.
- A connection reaches exactly one workspace and cannot be retargeted. Two workspaces mean two server entries, each authenticated separately.
- Scope is set when you approve the connection. A write tool refused for insufficient scope needs the connection revoked and re-approved with wider access rather than retried.
Cursor is a config-file client, which makes it the clearest illustration of why OAuth matters for this integration: the file that holds the server entry usually lives inside a repository, and what you put in it is shared with everyone who can read that repository.
Two ways to add it
There is a one-click install link that opens Cursor and prompts you to add the server. Cursor has to be installed already for it to do anything, and what it writes is the URL — nothing else. No key is involved, and the link itself reads and transmits nothing.
By hand, it is a small JSON file. Put it at .cursor/mcp.json for one project or at the same filename under your home directory for every project. Under OAuth the whole entry is a name and a URL, which is the entire content of the file.
Reload, then authenticate
After adding it, reload Cursor and open the MCP section of Settings. The entry appears marked as needing authentication, which is the expected state rather than a problem. Click through it, sign in, choose a workspace at the consent screen, and the tool count fills in once the connection is live.
If the count stays empty, the useful next check is whether the endpoint is reachable at all — the server publishes an unauthenticated health path for exactly that purpose, and it answers without a credential.
The file is the security story
This is the part worth reading twice. A project-level configuration is a shared file. Under OAuth that is fine, because the file contains a URL and the token lives in the client's own storage rather than on disk next to your source.
Under a static key it is not fine. A key committed to a repository should be treated as public from the moment it is pushed — not "probably fine because the repo is private", but revoked and replaced. Where a key is genuinely necessary, use the environment-variable form in anything repo-visible and keep the literal value out of version control.
The general rule follows from that: if a human with a browser will be present when the client first starts, there is no reason to create a key at all.
One workspace per entry
The credential names the workspace and no tool accepts a workspace id, so a server entry reaches exactly one workspace and cannot be repointed. If you work across two, add two entries and authenticate each — that is the supported shape rather than a workaround, and it has the pleasant side effect that you can see at a glance which one a conversation is talking to.
Scope behaves the same way. What you approve at the consent screen is what the connection can do forever; it cannot be widened afterwards. A write tool refused for insufficient scope is a valid credential doing what it was told, and the fix is to revoke and redo the connection with the access you actually need.
Confirming it landed correctly
Ask Cursor to call get_account. It returns the organisation, project and plan, and it does so without any workspace id being present in the request — which is the cleanest possible confirmation that the credential is bound to the workspace you meant rather than to another one you also have access to.
A word on where the entry lives
The choice between the project file and the one under your home directory is worth making consciously rather than by habit. A project-level entry travels with the repository, which is exactly right for a codebase where Attensira is genuinely part of the workflow — every collaborator gets the server and authenticates as themselves. A home-directory entry follows you instead, which is right when you reach for the same tooling across many checkouts. Both are safe under OAuth, and neither is under a static key.
Questions people ask
- What does the one-click install link actually do?
- It opens Cursor and prompts you to add the server, writing the URL and nothing else. No key is involved and nothing is read or transmitted by the link.
- Is it safe to commit .cursor/mcp.json?
- With OAuth, yes — the file contains a URL and no secret. With a static key it is not: treat a pushed key as public, revoke it and mint a new one.
- Can I add it for every project instead of one?
- Yes. Put the same file at ~/.cursor/mcp.json rather than in the project.
- The entry says it needs authentication. Is something wrong?
- No, that is the expected state after adding it. Click through, sign in, choose a workspace, and the tool count appears.
- How do I use a key if I have to?
- Use the environment-variable form in any repo-visible file, or keep local overrides out of version control. On a machine with a browser, OAuth is the better answer.
Sources
Every factual statement above, with the page it came from and the date that page was read.
Attensira's connect documentation states that its Cursor install link writes the URL and nothing else, with no key, and that nothing is read or transmitted.
docs.attensira.com · retrieved
“It writes the URL and nothing else — no key, and nothing is read or transmitted.”
Attensira's connect documentation states that a key pasted into a configuration file inside a repository is a leaked key and should be assumed public once pushed, revoked, and replaced.
docs.attensira.com · retrieved
“A key pasted into one and committed is a leaked key — assume it is public the moment it is pushed, revoke it, and mint a new one.”
Attensira's MCP overview states that the credential names the workspace, that no tool takes a workspace id, and that working across two workspaces requires connecting twice.
docs.attensira.com · retrieved
“To work across two workspaces, connect twice — one OAuth connection or one key per workspace, as two server entries.”