MCP client
VS Code and Copilot — Attensira in Agent mode, token off disk
A four-line mcp.json in the workspace, started from the editor, with the OAuth token stored in VS Code's own account storage rather than in the file.
Karl-Gustav Kallasmaa, Founder & CEOLast updated What you configure
The exact settings, as our documentation publishes them.
// .vscode/mcp.json
{
"servers": {
"attensira": {
"type": "http",
"url": "https://mcp.attensira.com/mcp"
}
}
}
Connecting it
In order, with the reason each step exists rather than only the instruction.
- 1
Write the server entry
VS Code reads mcp.json at the workspace root or under .vscode. The entry names the server, declares the http type and gives the URL. Under OAuth the whole file carries nothing secret, which is what makes it safe to keep beside the code.
- 2
Start the server from the editor
Use the Start link that appears above the entry. VS Code opens a browser for sign-in and stores the resulting token in its own account storage rather than writing it into the file.
- 3
Choose the workspace at the consent screen
The consent screen names the application, the workspace and the access. Read all three — most clients ask for read and write, because a client that can only read cannot do half of what you connected it for.
- 4
Open Copilot Chat in Agent mode
Tools only appear to an agent. Open Copilot Chat in Agent mode and check the tools picker; if Attensira is not listed there, the server has not started rather than failed to authenticate.
What it lets you do
- Brings the workspace's visibility data into the editor where the page being discussed is open.
- Keeps the credential out of the repository entirely, because the token lives in the editor's account storage and the file holds only a URL.
- Exposes the same eighteen tools any other client sees, so a workflow developed in one client transfers without change.
What it cannot do
An integration page that lists only capabilities is an advertisement. This is the half you are evaluating.
- Tools are only available to an agent. A chat that is not in Agent mode will not show them, and that is a client behaviour rather than a connection failure.
- The file lives in the repository, so a static key placed there is shared with everyone who can read it. OAuth avoids the problem entirely by keeping nothing secret in the file.
- A connection reaches one workspace and cannot be moved. Two workspaces mean two server entries, each authenticated on its own.
VS Code with Copilot connects to the Attensira MCP server the way it connects to any remote server: a short JSON entry, started from the editor, authenticated in the browser. What makes it worth its own page is where the credential ends up.
The file holds a URL, the editor holds the token
The entry declares a name, the http type and the server URL. That is the whole thing. When you press the Start link above it, VS Code opens a browser, you sign in and pick a workspace, and the token that comes back is stored in the editor's own account storage rather than being written into the file.
That is exactly the separation you want for a file that sits in a repository. The committed artefact says where the server is; nothing about who you are is committed alongside it. A colleague who checks out the branch gets the server entry and authenticates as themselves, which is the correct outcome and one that a shared key cannot produce.
Either location works — mcp.json at the workspace root, or .vscode/mcp.json. Pick whichever matches how the rest of the repository is organised.
Agent mode is not optional
The most common "it connected and nothing happened" report has one cause: the chat is not in Agent mode. Tools are surfaced to an agent, and an ordinary chat will not show them however correctly the server is configured.
Open Copilot Chat in Agent mode and look at the tools picker. If Attensira is absent from it, work backwards in this order: is the server started, did the browser sign-in complete, and is the endpoint reachable at all. That last one has a one-request answer, because the MCP host publishes an unauthenticated health path that responds without any credential — which cleanly separates a network problem from an authentication problem when the client is being unhelpfully quiet.
What you are approving
The consent screen names three things: the application, the workspace and the access. Read covers metrics, prompts, pages, sessions, automations and account details. Read and write adds anything that changes the workspace or spends credits.
Most clients ask for read and write for the good reason that a read-only assistant cannot do the half of the job people connect it for — but it is worth being clear that approving it grants an assistant the ability to delete a prompt with its history, delete an automation with its runs, and spend credits. That is a workspace credential.
One entry, one workspace
The credential names the workspace and no tool takes a workspace id, so a server entry cannot be retargeted. Two workspaces mean two entries, authenticated separately. Scope is likewise fixed at approval: a write tool refused for insufficient scope is a valid credential being told no, and widening it means revoking and re-approving rather than retrying.
Where this fits
The reason to have Attensira in the editor rather than in a browser tab is proximity. The page whose citation rate you are reading is open two tabs away, in the repository where the fix will be written, in the editor where you would write it. Asking which prompts cite a page while looking at the file that produces the page is a different activity from reading a dashboard, and it is the one this integration exists to make possible.
Reading the tools picker as a diagnostic
The tools picker in Agent mode is more informative than it looks. An entry present with tools listed means the server started, the sign-in completed and the credential is bound. An entry present with no tools means the connection exists and something downstream is wrong. No entry at all means the server never started, which points at the configuration file rather than at anything to do with authentication. Working through those three states in order resolves nearly every setup problem without any guessing.
Questions people ask
- Where does the file go?
- At the workspace root as mcp.json, or under .vscode as .vscode/mcp.json. Either is read.
- Where does the token end up?
- In VS Code's own account storage, not in the file. That is the reason the OAuth path leaves nothing secret in the repository.
- I connected but Copilot shows no Attensira tools.
- Check that the chat is in Agent mode, and that the server has actually been started from the link above the entry. Tools are surfaced to agents, and a stopped server has none to surface.
- Do I need a key?
- Not on a machine with a browser. Use a key only where nothing can complete a browser sign-in, and keep the literal value out of anything committed.
- How do I check the endpoint is reachable?
- Request the unauthenticated health path on the MCP host. It answers without a credential, which separates a network problem from an authentication one.
Sources
Every factual statement above, with the page it came from and the date that page was read.
Attensira's connect documentation states that VS Code opens a browser for sign-in and stores the resulting token in its own account storage rather than in the configuration file.
docs.attensira.com · retrieved
“VS Code opens a browser for sign-in and stores the resulting token in its own account storage, not in the file.”
Attensira's connect documentation states that VS Code reads mcp.json at the workspace root or at .vscode/mcp.json.
docs.attensira.com · retrieved
“VS Code reads .mcp.json at the workspace root or .vscode/mcp.json.”
Attensira's MCP overview states that the server's health path is unauthenticated and answers without a key, making it a useful reachability check when a client is silent about why it failed.
docs.attensira.com · retrieved
“is unauthenticated and answers without a key, which makes it a useful reachability check when a client is silent about why it failed”