How it works
There is nothing to switch on and nothing to configure. The MCP server belongs to the deployment: whoever looks after this product’s installation stands it up, and it reports its own address to this screen. Connecting an assistant is something a person does about their own account, with the sign-in they already have, and what the assistant can then answer is decided by permissions that already exist. If no MCP server has reported itself yet, a yellow banner at the top says so, and the address in the instructions is a placeholder. Ask whoever looks after your installation.The header
Connect your AI app
One address, and the sign-in you already have. Every client takes the address and nothing else — no key, no header, no file — because the address is where it finds the sign-in, and whoever signs in is who it then asks as. The section has a tab for each supported client, with the exact steps and a copy button for the address or the setup snippet:
After you paste the address, the client sends you to this product to sign in and approve it. The
approval screen names every tool the assistant will be able to use. From then on, every question that
client asks is asked as you, until you end the connection or, for most clients, a month passes.
The address is not a secret: a client that reaches it is refused until somebody signs in and approves
it, and can then ask only what that person could.
What it can ask for
Exactly what you can read. Every tool the server offers is offered to everybody, and every question is answered against the permissions, sites and records of the person whose connection it is — the same ones the app uses. Somebody who cannot open the parts register in the product cannot get it through an assistant either, and somebody with a supervisor’s reach gets a supervisor’s answers. An assistant can also raise a request (a work request) and leave a comment, if the person can — and those are the only two things it can change. They are attributed to the person, exactly as if they had typed them, and appear in the record’s history under their name.What people have connected
Every assistant somebody in this organisation has approved. People who configure integrations see everybody’s; everybody else sees their own.
Anybody can end their own connection; people who configure integrations can end anybody’s. Ending one
stops the next question rather than one already in flight: the token the assistant holds is good for
at most fifteen minutes more.
What has been asked
Every question an assistant has asked, answered or refused, with the person it was asked for. Kept to people who configure integrations; others see a notice instead. The newest hundred are shown, and Refusals only narrows the list to refusals.
The log names the person deliberately, not the app: it reads “Ada asked what was overdue” rather than
“the integration read 40 work orders”. A refusal is not a fault in this screen. It means the person’s
own role does not cover what they asked for, which is a conversation about their permissions on
Access.
What this does not solve
An asset description, a work order comment or a part’s notes can contain text aimed at a model, and the server returns that text as data — nothing strips it, and nothing could. What bounds the damage is that every question is asked as a person: there is no tool a caller’s own permissions would not already allow, so the worst an instruction hidden in a record achieves is something that person could have done themselves. That is why a person’s roles are the control worth getting right, rather than a second, weaker copy of the permission model on this screen.Who can use this
See roles.
Copilot
The AI assistant built into the product itself.