What MCP is

It standardises how that connection is made. It does not change who is responsible for what.

The problem it was built for

Before a standard, every combination was its own project. Three AI applications wanting access to three internal systems meant nine integrations, each written against a different client’s conventions, each maintained separately.

The specification names its own model for the fix: the Language Server Protocol, which did the same job for programming languages. Before it, every editor needed its own support for every language. After it, a language was described once and every editor could use it. MCP applies that idea to tools and data for AI applications, so a capability is built once and every AI application can use it.

That analogy is the clearest statement of the ambition. Write one server for your ticketing system, and any compliant client can use it.

The three parts

The spec describes participants and a message format, not much more.

The three parts talk to each other in one standard message format (JSON-RPC 2.0), which is the reason any client can work with any server without either side knowing about the other in advance. A server can offer three things, and the list is deliberately short: resources, meaning context and data for the user or the model to use; prompts, meaning templated messages and workflows for users; and tools, meaning functions for the model to execute. Clients can offer elicitation, where a server asks the user for more information.

The protocol also has a defined extension mechanism rather than an open field: extensions are always opt-in, have to be supported by both sides, and are agreed when the connection opens. They currently cover asynchronous long-running tasks, structured skills, and inline interactive UI.

Where the server runs

A server either runs on your own computer or somewhere else on the network. The choice decides who can reach it, and it is a security decision more than a technical one.

On your own computer, the server runs as a program beside the AI application, which the architecture documentation calls the fastest arrangement, because nothing has to cross a network. It usually serves one person, and it can reach whatever that computer can reach: your files, your saved logins, anything on your company network you are already signed in to.

Somewhere else, the server runs as a shared service for many users at once, reached over the internet and protected by an ordinary sign-in. It holds credentials for many people at once.

The specification calls these two arrangements stdio and Streamable HTTP. The names matter less than the consequence: a problem with the server on your laptop exposes your laptop, and a problem with a shared server exposes everyone using it.

What it doesn’t change

The marketing around MCP often implies otherwise.

The model still doesn’t execute anything. A tool exposed over MCP is still a structured request that some code carries out, and the same round trip still applies. MCP standardises how the tool is described and reached, not what happens when it is called.

Tool definitions still cost tokens. Connecting a server with forty tools puts forty descriptions into the request, billed as input, competing for the model’s attention. A protocol that makes it easy to attach many servers makes it easy to build an expensive, less accurate agent.

And permission is still yours. The spec is explicit that it cannot enforce the safety it describes. The protocol has no way to make anyone comply, so the obligation falls on whoever builds the application: they are the ones expected to ask for consent and to make clear what is being authorised.

What the spec says about security

The specification opens its security discussion by noting that MCP “enables powerful capabilities through arbitrary data access and code execution paths”, and its principles put the user first. A user has to consent to and understand every data access and every operation. A host has to get that consent before exposing any of the user’s data to a server, and again before it invokes any tool.

Then the sentence that matters most for anyone connecting third-party servers: “Tools represent arbitrary code execution and must be treated with appropriate caution. In particular, descriptions of tool behavior such as annotations should be considered untrusted, unless obtained from a trusted server.”

Read that alongside how tool calling works and the implication is sharp. The model decides what to call based on tool descriptions, and the descriptions can come from a server somebody else operates. A description is therefore an instruction channel from a third party straight into your agent’s decision-making, which is prompt injection with a supply chain attached.

The security guidance documents specific attack classes as well. Token passthrough, where a server accepts tokens that were not issued to it and forwards them downstream, is named an anti-pattern, because it breaks a boundary the sign-in system depends on. Confused deputy attacks let malicious clients “obtain authorization codes without proper user consent”. And local servers, being binaries downloaded and executed on a user’s machine, are attractive targets, with named attacks including a malicious startup command in a client configuration, a payload inside the server itself, and reaching an insecure local server left listening on localhost.

None of that makes MCP unsafe to use. It makes an MCP server a dependency with the access of the account that runs it, which is worth treating like any other dependency with that power.

The GitHub MCP case

In May 2025 Invariant Labs published an attack against the official GitHub MCP server. A developer keeps a public repository and a private one, and asks their agent to look at the open issues on the public repository. An attacker has already filed one of those issues, and it contains instructions written for the model. The agent reads them, pulls data out of the private repository, and writes it into a pull request on the public repository, where anyone can read it.

Nothing in the server’s code was broken. The token the server holds reaches every repository its owner can reach, so an agent that has been redirected mid-task uses that token exactly as its owner would. Invariant calls the pattern a toxic agent flow: indirect injection used to set off a sequence of legitimate tool calls.

The client does ask the user to approve each call. Invariant notes that many people set it to always allow and stop reading the prompts.

The limits they suggest are both about scope. Give an agent a token that reaches one repository rather than a whole account, and keep a session to one repository at a time.

Common questions