What Is MCP? The Model Context Protocol, Explained

Published: October 25, 2026 · 8 min read

If you have used an AI assistant in the last year, you have probably hit the same wall: the model can write, reason, and brainstorm, but the moment you ask it to check your calendar, query a database, or open a file in your project, it reaches the edge of what it can see. The Model Context Protocol, usually shortened to MCP, is an open standard designed to remove that wall. It gives AI applications a single, agreed way to connect to external tools and data sources, so developers do not have to build a fresh integration for every pairing of assistant and service.

What MCP is

MCP is an open protocol introduced by Anthropic in November 2024. It standardises how an AI application exchanges information with the systems around it: files, databases, development tools, business software, and other services. The analogy Anthropic used at launch was USB-C — just as one connector standard lets many devices plug into many computers, MCP aims to let many AI applications work with many tools through one protocol instead of a maze of one-off connectors.

Before MCP, connecting a model to a new tool usually meant writing custom glue code for that specific combination: one integration for this assistant and that database, another for a different assistant and the same database. With MCP, the tool provider builds one server that speaks the protocol, and any application that supports MCP can use it. The protocol itself is open and its specification is publicly maintained, which matters because no single vendor controls who can implement it.

How it works: hosts, clients, and servers

An MCP setup has three parts. The host is the application the user interacts with — a desktop AI app, a code editor with AI features, or a chat interface. Inside the host, an MCP client manages the connection to one particular server. The MCP server is a separate, usually small program that exposes some capability: access to a file system, a database, a code repository, a calendar, or a web service. One host can run several clients at once, each talking to a different server, so a single assistant can draw on many tools in one conversation.

The communication between client and server uses structured messages. When a session starts, the two sides negotiate which capabilities are available. After that, the host application can ask the server what it offers, and the model can decide — within the permissions the user has granted — which of those offerings to use while answering a request.

The three building blocks: tools, resources, and prompts

MCP servers expose their capabilities through three main primitives:

• Tools — actions the model can invoke, such as searching a database, creating a calendar event, running a query, or posting a message. Each tool has a name, a description, and a defined input format, so the model knows how to call it and what will come back.
• Resources — data the server makes available for the application to read into context, such as the contents of a file, a database record, or documentation. Resources are closer to reading material than to actions.
• Prompts — reusable templates or workflows the server offers, which a user or application can select to set up a particular kind of interaction, like a guided review of a document.

This division keeps things tidy. Tools change the world, resources inform the model, and prompts shape the interaction. A well-built server describes each primitive clearly, which helps the model use them appropriately and helps the host application show the user what is about to happen.

A concrete example

Imagine a developer working in an AI-enabled code editor. The editor is the host. Connected to it is an MCP server for a code-hosting service. When the developer asks the assistant, "Why is the login page failing in production?", the assistant can use the server's tools to list recent commits, read the error log attached to the latest deployment, and pull up the relevant issue reports — all through the same protocol. The developer did not paste anything into the chat; the assistant fetched what it needed, with the editor showing which tools were called. The same server could also be connected to a different AI application tomorrow, with no new integration work, because both sides speak MCP.

The pattern generalises well beyond coding. A server for a customer database lets a support assistant look up an order. A server for a design tool lets an assistant inspect a mock-up. Each server is narrow and understandable on its own, and the value compounds as more of them exist.

Why it matters

The practical effect is a shift from bespoke integrations to an ecosystem. Tool builders write one server and reach every MCP-compatible application; application builders add MCP support once and inherit every server. That lowers the cost of connecting AI to real work, which is where most of the usefulness lives — models are far more helpful when they can see current data and take permitted actions rather than answering from memory alone.

Adoption through 2025 was broad: major AI providers and tool makers announced MCP support or shipped their own servers, and a large public registry of community and vendor servers grew up around the protocol. In December 2025, Anthropic donated MCP to the Agentic AI Foundation, a directed fund under the Linux Foundation, placing the project under neutral, multi-stakeholder governance alongside other agent-related projects. That move signalled that MCP is intended as shared infrastructure rather than one company's product feature.

Security: the honest caveats

Giving a model access to tools also gives it new ways to cause harm if things go wrong, and MCP's documentation is candid about this. A few considerations matter most:

• Permissions and consent. The host application should make clear which servers are connected and ask the user to approve sensitive actions, especially anything that writes, deletes, sends, or pays. A tool call that modifies real data should rarely happen invisibly.
• Prompt injection through tools. Data returned by a tool can contain text crafted to manipulate the model — instructions hidden in a document, a web page, or a database field. Because the model reads tool output as part of its context, a malicious resource can try to steer it. Careful server design, output filtering, and human confirmation for consequential actions all reduce this risk.
• Trust in servers. An MCP server runs with real access to something. Installing one from an unknown source is comparable to installing any other software with your credentials: check who made it, what it can reach, and whether it needs everything it asks for.

None of this is unique to MCP — any tool-using AI raises the same questions — but a shared protocol makes the safeguards easier to standardise and audit across applications.

How you will encounter MCP as a non-developer

You do not need to write a server to run into MCP. It increasingly appears as a settings panel or a connections menu in AI apps: a list of services you can link, each described in plain language, with toggles for what the assistant may do. When an app advertises that it "supports MCP," it means third parties can extend what the assistant reaches — a notes app, a project tracker, or your own files — without the app maker building each connection by hand. For most people, MCP will stay invisible plumbing; the visible change is assistants that can actually look things up and do small, approved tasks instead of only chatting about them.

MCP is not the whole story of AI agents, and it does not decide what an assistant should be allowed to do — that remains a product and policy choice in each host application. What it provides is the common language. As with earlier shared standards, its success will be measured less by announcements than by how unremarkable it becomes: connections that simply work, whichever assistant and whichever tool you happen to use.