MCP explained: connecting AI agents to your systems

The Model Context Protocol (MCP) is an open protocol for connecting AI applications to the tools and data they work with. A system is connected once, through an MCP server, and any AI application that supports MCP can then reach it. What MCP doesn’t decide is what an agent should be allowed to do once it’s connected. Before you connect a server, check four things: how it authorises access, which tools it exposes, which of those can change something, and whether every call is logged where you can see it.

What MCP is

The specification describes three parts.¹ The host is the AI application a person uses, such as an AI-powered code editor or a chat interface. Clients inside the host handle the connections. A server sits in front of a system, such as a ticketing tool, a database or a code repository, and offers what that system can do.

A server can offer three kinds of thing: resources, which are data for the user or the model to use; prompts, which are ready-made instructions and workflows for users; and tools, which are functions the model can run. Tools are what let an agent act rather than only answer, as we describe in what AI agents can do on a business website. They’re also where the risk sits: the specification says tools represent arbitrary code execution and must be treated with caution.

The idea is borrowed from the Language Server Protocol, which lets one integration for a programming language work across many code editors. MCP aims to do the same for tools and data: a system connected once can be reached from any host that supports the protocol.

The specification is open about its limits. It says MCP can’t enforce its own security principles, such as asking for a person’s consent before a tool runs, at the protocol level. Those are left to the hosts and servers that implement it.

Who looks after it now

Anthropic released MCP as open source in November 2024. On 9 December 2025, the Linux Foundation announced the Agentic AI Foundation, with MCP as one of its three founding projects, alongside Block’s goose and OpenAI’s AGENTS.md.² Anthropic said the move would keep MCP open, neutral and community-driven.

The foundation’s platinum members at launch included AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft and OpenAI. That’s broad backing for the standard itself. It doesn’t extend to the servers built on it: whether a particular server is safe to connect is still your call.

What changed in the July 2026 specification

The revision released on 28 July 2026 changes how MCP works underneath.³ Its headline is a stateless core. The start-up handshake and the protocol-level session are gone: every request carries what the server needs to answer it, including the protocol version and what the client supports. Any instance of a server behind an ordinary load balancer can answer any request, with no shared session storage.

All four of the project’s Tier 1 SDKs, for TypeScript, Python, Go and C#, supported the revision on the day it was released. A new policy also sets the pace of change: a deprecated feature stays in the specification for at least 12 months before it can be removed.⁴

None of this changes what a server is allowed to do once it’s connected. It makes servers easier to run, meter and trace, which helps with the checks below, but the decisions are still yours.

What tool annotations can and can’t tell you

A server can describe each tool with annotations: hints about how it behaves.⁵ There are four. A tool may say it only reads, that it may delete or overwrite rather than only add, that calling it twice with the same inputs has no extra effect, and whether it reaches beyond a closed set of systems, such as the public web.

In a tool’s definition they look like this:

{
  "name": "delete_ticket",
  "description": "Delete a support ticket",
  "inputSchema": {
    "type": "object",
    "properties": { "ticketId": { "type": "string" } },
    "required": ["ticketId"]
  },
  "annotations": {
    "readOnlyHint": false,
    "destructiveHint": true,
    "idempotentHint": true,
    "openWorldHint": false
  }
}

A tool with no annotations is assumed to do the worst on every count: it may change things, may destroy them, isn’t safe to repeat and reaches outside. When the post was written in March, coverage was uneven, and many servers shipped without them.

Used well, annotations decide what a person is asked. A client can ask before a destructive call and skip the question for a read-only one, and that’s their most common use. They can also be one input to a policy engine.

What they can’t do matters more:

• They can’t make a model resist prompt injection.
• They can’t stop a server that’s wrong or dishonest. A tool that says it only reads can still delete files. The specification says clients must treat annotations as untrusted unless they come from a trusted server.⁶
• They describe one tool, and the risk belongs to the whole session. One server that searches your email, another that reads web pages and a third that can send messages add up to private data, untrusted content and a way to send data out. The post credits Simon Willison with naming that combination the lethal trifecta, and none of the three tools looks dangerous on its own. It’s the combination we cover in how to limit what a fooled agent can do.

The post draws the line clearly: if your safety depends on a hint being true, it belongs in authorisation, the network or the runtime instead. Its advice to anyone building a client is short:

Before you connect a server

Four checks, in the order that settles the most.

How does it authorise access?

The strongest answer is that your organisation’s identity provider decides. The Enterprise-Managed Authorization extension, stable since June 2026, lets it decide which servers each person can reach, by group and role. People get their approved servers when they sign in, instead of authorising each one, and every access decision sits in one audit trail.⁷ It’s an extension, so the host, the identity provider and the server all have to support it.

Whatever the method, two rules from MCP’s security guidance apply.⁸ A server must accept only tokens issued for it, and must never pass a client’s token straight through to another service: that skips the other service’s rate limits and monitoring, and its logs show the wrong identity. And access should start small: read-only scopes first, more only when a privileged action needs them, no wildcard scopes, and a log entry each time access grows.

Which tools does it expose, and to whom?

Connect only the tools the task needs. A server may list only the tools a caller’s permissions allow, so someone without write access never sees the write tools.⁶ Keep a register of approved servers and who owns each, as you would for any other internal service.

Check where it runs, too. A server on someone’s own machine runs with the same privileges as the host. MCP’s guidance says one-click setup must show the exact command and ask for approval, and that local servers should run in a sandbox with minimal privileges.⁸

A tool that returns data makes a quieter promise: that the data means what the agent assumes. Agree what it means, and who owns it, before an agent comes to depend on it.

Which of its tools can change something?

Read the annotations, then check them. For a server you don’t control, its documentation and code are the evidence, and the hints are a claim. Treat any tool without annotations as able to write, delete and reach outside.

Put a person in front of anything that changes or sends something. The specification says a person should always be able to deny a tool call, and that clients should confirm sensitive operations and show a tool’s inputs before it runs.⁶

If a server keeps state between calls, it now does so with an identifier it issues. The specification puts it plainly: a handle is a name, not a capability. The server should tie each identifier to the user it belongs to and check that user’s rights on every call.

Is every call logged where you can see it?

The specification says clients should log tool use for audit.⁶ Keep a record of each call outside the agent’s reach: the tool, the inputs, the person it acted for and the result. The July revision helps: with the method and tool name in the headers, a gateway can record every call, and the trace-context conventions let one trace follow a request from the agent into your services.

What to ask your team

Connecting an agent to a system isn’t the hard part any more. Knowing what each connection allows, and seeing when it’s used, is.

For each agent that uses MCP, three answers show where you stand:

• which servers it can reach, and who approved each one
• which of their tools can change or send something, and whether a person confirms those calls
• where the record of each call is kept, and who reads it

Then the question that matters: of every MCP server our agents can reach today, which could change something without a person seeing it first?