> ## Documentation Index > Fetch the complete documentation index at: https://docs.assetinfinity.ai/llms.txt > Use this file to discover all available pages before exploring further. # MCP > Connecting Claude, ChatGPT or another AI assistant to this organisation's own data — governed entirely by the permissions of whoever connects it. 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. | Client | Where to add it | | - | - | | **Claude** | Settings → Connectors → Add custom connector | | **ChatGPT** | Settings → Connectors → Advanced → Developer mode → Create | | **Microsoft Copilot** | Copilot Studio → your agent → Tools → Add a tool → Model Context Protocol | | **Claude Code** | `claude mcp add --transport http asset-infinity
`, then `/mcp` to authenticate | | **Cursor or VS Code** | The editor's own MCP settings, or a hand-written config naming the address | Paste the address, and the client sends you here to sign in and approve it — the same [consent screen](#what-it-can-ask-for) 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. This is open to everybody who can reach this screen, not only administrators. Connecting an assistant is a decision a person makes about their own account. ## What it can ask for, and what it can't **Every question is answered against the permissions of the person who connected.** There is nothing on this screen to switch on and no separate tool list to manage: somebody who cannot open the parts register in the product cannot get it out of Claude either, and somebody with a supervisor's reach gets a supervisor's answers. 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. | State | Meaning | | - | - | | **Connected** | Live | | **Never finished** | Reached the consent screen and never came back with its code — the shape a broken redirect leaves | | **Expired** | Its authorisation ran out | | **Ended** | Somebody ended it, or a token was replayed and the connection was cut for it | 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." | Column | Notes | | - | - | | **Asked for** | The person whose connection it was. "Nobody" marks a call made with no session behind it at all — a fact about how a client was configured, not a blank | | **Asked about** | Which tool, and how many rows came back | | **Outcome** | Answered, refused, or failed | | **What they were told** | The message a refusal or failure carried | 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](/config/api-keys), and it reports its own address here the first time it calls. There is nothing else to fill in. Standing up the server in the first place is a one-time, administrative act — issuing it a read-only identity and a key, exactly the way any other machine caller is issued one. It isn't part of connecting a personal assistant above; an organisation only does it once, when nothing is serving it yet. 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](/config/api-keys#who-can-manage-this) uses. Connecting your own assistant needs nothing beyond an ordinary sign-in. See [roles](/setup/roles). Where the MCP server's own credential is issued, rotated and revoked.