Your AI app has probably grown a connectors menu. Google Drive, Slack, Notion, GitHub, a directory of others, each with a button that says connect or install. The acronym attached to all of it is MCP, and the pitch is that your assistant can now work with your actual files instead of guessing.
That pitch is fair. What nobody puts on the button is that “connect” means two quite different things depending on the connector, and one of them installs a program that runs on your computer with your permissions.
This explainer is built from the Model Context Protocol’s own documentation and specification, checked on 20 September 2026. Nothing here was tested hands-on, and no specific product’s connector flow has been audited — the point is to tell you what the standard requires so you can check your own.
The short version
- MCP is an open standard for plugging AI apps into other systems. It is not a product.
- A remote connector is an account permission, much like any app you have authorised before.
- A local server is software on your machine, running with the same privileges as the app that launched it.
- The specification says a client must show you the exact command before running a local server.
- Connecting gives the model real data. It does not make the model’s answers self-verifying.
What MCP actually is
The documentation puts it in one sentence: MCP is “an open-source standard for connecting AI applications to external systems”. Anthropic open-sourced it on 25 November 2024 as “a new standard for connecting AI assistants to the systems where data lives”, and it has since been adopted well beyond them — the docs list Claude, ChatGPT, VS Code and Cursor among the clients that support it.
The analogy in the official documentation is a USB-C port: “Just as USB-C provides a standardized way to connect electronic devices, MCP provides a standardized way to connect AI applications to external systems.” Before it, every AI app wired up every tool its own way. Now a tool built once can work in any app that speaks the protocol.
Two words are worth pinning down, because the documentation uses them constantly. The client is the AI app you are using. The server is the thing being connected — the Google Drive integration, the database wrapper, the file-system bridge. Confusingly, a “server” here is often not a remote machine at all. It can be a small program sitting on your laptop.
What a server offers the model is some combination of tools (actions it can take), resources (data it can read) and prompts (prepared workflows). This is the plumbing that turns a chatbot into an agent that can take actions rather than only describe them.
The two kinds of connector
The menu shows these side by side. They are not the same kind of decision.
Remote servers
A remote connector runs on someone else’s infrastructure, and connecting means going through an authorisation flow — the familiar screen asking whether you will let this application see your files. The trust decision is the one you already make when you connect any third-party app to your Google or Slack account: you are granting an outside service ongoing access to an account, and you can usually revoke it in that account’s security settings.
The specification’s advice here is least privilege, and it is blunt about why broad permissions are tempting and bad. It warns against “wildcard or omnibus scopes (*, all, full-access)” and “bundling unrelated privileges to preempt future prompts”, noting that a stolen broad token “enables lateral data access” and that revoking it “disrupts all workflows”. It also names the failure mode from the user’s side: consent abandonment, where “users decline dialogs listing excessive scopes”.
Local servers
A local server is different in kind. The specification describes these as “binaries that are downloaded and executed on the same machine as the MCP client”, installed by the user or through a client’s configuration flow.
The risks it lists for local servers from untrusted sources are stated plainly: “Arbitrary code execution. Attackers can execute any command with MCP client privileges.” And: “No visibility. Users have no insight into what commands are being executed.” A one-click install can carry a startup command that does something other than what the connector’s name suggests.
This is not a reason to avoid local servers, which are genuinely useful and often the only way to give a model access to something on your own machine. It is a reason to treat installing one as installing software, because that is what it is — not as ticking a permission box.
Physical infrastructure learned to label this a long time ago. Software connectors are still working out where the sign goes.
What the specification says you are owed
The standard does not leave this to the client’s taste. On one-click local configuration it is normative:
If an MCP client supports one-click local MCP server configuration, it MUST implement proper consent mechanisms prior to executing commands.
Before anything runs, the client must “show the exact command that will be executed, without truncation (include arguments and parameters)”, must “clearly identify it as a potentially dangerous operation that executes code on the user’s system”, must “require explicit user approval before proceeding”, and must let you cancel.
Beyond that floor, the specification says clients should highlight dangerous command patterns, warn when a command touches sensitive locations such as your home directory or SSH keys, “warn that MCP servers run with the same privileges as the client”, and run servers sandboxed with minimal default privileges.
That last one is the sentence worth carrying around. A local MCP server is not confined to the conversation. It has whatever access the app that launched it has.
A short check before you click
| Remote connector | Local server | |
|---|---|---|
| What runs where | On the provider’s servers | On your machine |
| What you are granting | Account access, via an authorisation screen | Execution, with your app’s privileges |
| First thing to read | The scopes on the consent screen | The exact command, in full |
| How to undo it | Revoke in the account’s security settings | Remove the server from the client’s config |
| Main question | Does it need this much access? | Do I trust whoever wrote this? |
Five things worth doing, none of them onerous:
- Read the scopes, not the logo. “See, edit, create and delete all your files” is a different request from read-only access to one folder. If the list looks broader than the job, that is the signal the specification is describing.
- Read the whole command on a local install. The client is supposed to show it untruncated. If it does not show one at all, that is worth noticing.
- Prefer servers published by the service they connect to. A connector for a product, written by that product’s makers, is a shorter trust chain than a third-party bridge with the same name.
- Connect one thing at a time. Easier to attribute odd behaviour, easier to revoke.
- Review the list occasionally. Connectors accumulate. Most people never revisit an authorisation they granted once.
What connecting does not fix
Giving a model real data removes one cause of bad answers: it no longer has to reconstruct an answer about your files from general knowledge. That is a genuine improvement, and it is most of why connectors are worth having.
It does not make answers self-verifying. The model can misread a real document as fluently as it can invent a fake one, so output that matters still needs checking against the source. And there is a quieter cost: the descriptions of every connected tool are sent to the model as text, so tool definitions count against the window alongside your conversation. A dozen connectors left switched on are consuming room before you have typed anything.
The thing worth remembering
MCP is a standard, not a product, and most of the time it is exactly what it looks like: a tidier way to let an assistant reach your tools. The one distinction worth keeping straight is remote versus local. One is a permission you can revoke from an account page. The other is a program on your computer running as you — and the specification says you are owed the exact command, in full, before it does.
Header photo: Gary Langebartels / FortepanIowa via Wikimedia Commons, CC BY-SA 4.0.