Agent plugin
Your own MCP server — give the Attensira agent new tools
Register an MCP server you run and the agent can call its tools like built-ins, namespaced so nothing collides and nothing shadows ours.
Karl-Gustav Kallasmaa, Founder & CEOLast updated What you configure
The exact settings, as our documentation publishes them.
Tool naming after discovery:
mcp__<slug>__<tool>
A `search` tool on a server registered as `warehouse`
becomes `mcp__warehouse__search`.
Connecting it
In order, with the reason each step exists rather than only the instruction.
- 1
Add the server
Give it a name and its URL. The name becomes the slug the agent uses to address it, and it is what every discovered tool is namespaced under.
- 2
Choose an auth mode
Either none for an open server, or apiKey for a key Attensira sends on each request. OAuth is refused with an explicit error rather than accepted and failed later, because Attensira has no token store and cannot hold or refresh a credential on your behalf.
- 3
Let discovery run
Attensira calls tools/list on the server and registers what it finds. Discovery and calls are bounded by timeouts and budgets so that one slow server cannot hold up a whole session — a server that exceeds the discovery budget is skipped for that session rather than delaying the answer.
- 4
Grant it, per workspace
A granted plugin is available to the whole workspace rather than to one person or one chat, and until it is granted the agent cannot see its tools at all. Grants are revocable at any time.
What it lets you do
- Extends the agent beyond Attensira's own data — a warehouse, an internal service, a system of record — without any change to the product.
- Namespaces every discovered tool under the server's slug, so two servers can both expose a tool called search and neither can shadow an Attensira built-in.
- Turns an unreachable server into a single tool that explains the problem when called, instead of letting the capability silently disappear from the agent's view.
What it cannot do
An integration page that lists only capabilities is an advertisement. This is the half you are evaluating.
- OAuth is not supported as an auth mode. Attensira has no token store, so it cannot hold or refresh an OAuth credential on your behalf, and registering such a server returns an explicit error rather than failing later with an undiagnosable 401.
- A plugin cannot be forced to re-read its tools on demand. There is no control that refreshes one, because there is no endpoint behind such a control — the product omits the button rather than showing one that spins and does nothing.
- A granted plugin is available to the whole workspace, not to one person or one chat, so granting it is a workspace-level decision.
Every other integration on this list points outward: something you use calls Attensira. This one points the other way. You register an MCP server that you run, and the Attensira agent can call its tools the way it calls its own.
The direction confusion, settled
These two are easy to mix up and share nothing.
Attensira's MCP server is outbound. Your assistant — Claude, Cursor, ChatGPT — calls Attensira. You authenticate with OAuth or an Attensira key.
A plugin or a registered MCP server is inbound. The Attensira agent calls your service. The credential involved is yours, not ours, and it has nothing to do with your Attensira API key.
You can run both at once, and most people who do this eventually do. But no configuration is shared between them, and a problem with one is never a problem with the other.
Registration in three fields
A name, a URL, and an auth mode. The name matters more than it looks, because it becomes the slug every discovered tool is addressed under.
Then discovery runs: Attensira calls tools/list on your server and registers what comes back. Nothing else is required of you — the tool schemas your server publishes are the tool schemas the agent sees.
Namespacing makes collisions impossible
Discovered tools are addressed as the server's slug plus the tool's own name. A search tool on a server registered as warehouse becomes a distinct name from a search tool on any other server, and from Attensira's own.
That is not a convention, it is a guarantee. Two servers can both expose the same tool name without interfering, and a registered tool can never shadow a built-in, because the built-ins are assembled first. It means you can name tools in your own service according to your own service's logic, without checking them against ours.
OAuth is refused, deliberately
The supported modes are an open server, or an API key that Attensira sends on each request. Registering a server that requires OAuth returns an explicit error.
The reason is worth stating because a refusal is easy to read as an omission. Attensira has no token store, so it cannot hold or refresh an OAuth credential on your behalf. A product that accepted the configuration anyway would be creating a setup that appears to work and then fails, later, with a 401 that nobody can trace back to this decision. Refusing at registration is the honest failure.
If your server needs OAuth, put an authenticating proxy in front of it and register the proxy with an API key.
When your server is down
An unreachable server does not disappear. It collapses to a single tool marked unavailable, which explains the problem when it is called.
This is a small design decision with a large effect on how the agent behaves. A tool that vanishes looks, to a model, like a capability that never existed — and it will tell you confidently that it cannot do something it normally does. A tool that answers "this server is unreachable" produces a real diagnosis and an inbox row somebody can act on.
The bounds
Discovery and calls are bounded so that one slow server cannot hold up a session: timeouts on discovery and on individual calls, a cap on tools registered per server, and a total discovery budget across all servers before a session starts. A server that exceeds the budget is skipped for that session rather than delaying the answer, which is the right trade — a late answer helps nobody.
One last thing worth knowing: a granted plugin is available to the whole workspace, not to one person or one chat, and until it is granted the agent cannot see its tools at all. Granting is a workspace-level decision, and it is revocable at any time.
Questions people ask
- How is this different from Attensira's own MCP server?
- Direction. Attensira's server is outbound — your assistant calls Attensira. A plugin or a registered server is inbound — the Attensira agent calls it. They share no configuration and no credentials.
- Why can I not use OAuth?
- Because Attensira has no token store and cannot hold or refresh a credential for you. Registering an OAuth server is refused explicitly instead of being accepted and failing with a 401 nobody can diagnose. Use apiKey, or put an authenticating proxy in front.
- Can a plugin tool shadow a built-in?
- No. Discovered tools are namespaced under the server's slug, and the built-ins are assembled first, so collisions are impossible in either direction.
- What happens when my server is down?
- It becomes a single tool named for the server and marked unavailable, which explains the problem when called. A tool that vanished would make the agent believe the capability never existed.
- Can I force a refresh of the tool list?
- No. There is no endpoint behind such a control, so the product does not offer a button for it.
Sources
Every factual statement above, with the page it came from and the date that page was read.
Attensira's plugin documentation states that OAuth is not supported as an auth mode because Attensira has no token store, and that registering such a server returns an explicit error rather than failing later.
docs.attensira.com · retrieved
“OAuth is not supported as an auth mode. Attensira has no token store, so it cannot hold or refresh an OAuth credential on your behalf.”
Attensira's plugin documentation states that discovered tools are namespaced as mcp__slug__tool, that two servers can both expose the same tool name, and that built-ins cannot be shadowed because they are assembled first.
docs.attensira.com · retrieved
“Attensira's own built-in tools can never be shadowed by a registered one, because the built-ins are assembled first.”
Attensira's plugin documentation states that discovery and calls are bounded by timeouts and a discovery budget, and that a server exceeding the budget is skipped for that session rather than delaying the answer.
docs.attensira.com · retrieved
“A server that exceeds the discovery budget is skipped for that session rather than delaying the answer.”