MCP

The Model Context Protocol is how an AI assistant reaches this organisation’s data directly, instead of somebody copying it in by hand. There is nothing to switch on and nothing to configure: connecting is something a person does about their own account, and what it can then answer is decided by permissions that already exist.

​

Connecting 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. Paste the address, and the client sends you here to sign in and approve it — the same consent screen whichever client sent you. From then on, every question that client asks is asked as you, until you end the connection or, for most clients, a month passes.

​

What it can ask for, and what it can’t

Separately from that, and true for everybody regardless of role: it reads, and changes nothing. The identity every question runs through can read and never write, so raising a request, changing a record or leaving a comment through an assistant isn’t offered to anyone, however much their own permissions would otherwise allow. The consent screen a person sees when they connect names every tool, tool by tool, and says plainly that nothing on the list can write.

​

Who’s connected

Every app somebody in this organisation has approved: the app’s own name, who allowed it, when, when it was last asked something, and its state. Anybody sees their own connections here and can end one. Somebody who configures integrations sees everybody’s, and can end any of them.

​

What has been asked

Every question a model has asked, answered or refused, with the person it was asked for — kept to whoever configures integrations. Asked for names the person deliberately, not the app: the aim is a log that reads “Ada asked what was overdue” rather than “the integration read 40 work orders.” A refusal here is not a bug report: it means somebody’s own role doesn’t cover what they asked for, which is a conversation about that person’s permissions rather than about this screen. Refusals only filters to just those.

​

The deployment

The MCP server is a container of its own — whoever deployed this product stands it up, gives it a key from API keys, and it reports its own address here the first time it calls. There is nothing else to fill in. The one thing worth correcting by hand is the address itself, and only where something in front of the server changes it — a gateway on another hostname, a path prefix. It has to be exactly what a client will type, because it’s also the name the server signs people in under.

​

What this does not solve

An asset description, a work order comment or a part’s notes can carry text aimed at a model, and this 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’s no tool a caller’s own permissions wouldn’t already have allowed, so the worst an instruction hidden in a record achieves is something that person could have done themselves. Which is why somebody’s roles are the control worth getting right, rather than a second, weaker copy of the permission model living on this screen.

​

Who can configure this

Reading who has connected, the call log, and the deployment’s own address is kept to whoever configures integrations — System Administrator by default, and deliberately not Maintenance Administrator, the same reasoning API keys uses. Connecting your own assistant needs nothing beyond an ordinary sign-in. See roles.