What is the Model Context Protocol (MCP)?

A language model only knows what it learned in training and what you paste into the chat. Ask Claude or ChatGPT about a file on your laptop, a ticket in your team's tracker or a row in your company database, and it has no way to look. Every product that wants to bridge that gap has had to build its own connection to each data source, one integration at a time.

On 25 November 2024 Anthropic open-sourced the Model Context Protocol, or MCP, to replace that patchwork with a single standard. Anthropic's announcement frames the problem as models being cut off from data, stuck behind information silos and older systems. MCP offers a shared language: if a data source speaks MCP and an AI application speaks MCP, they can work together without custom glue.

How MCP is put together

A good comparison is a universal power adapter. You don't rewire your laptop for every country; you carry one adapter with a standard shape on each side. MCP plays that role between AI applications and the systems they need to reach.

The documentation describes three roles:

Host: the AI application you use, such as the Claude Desktop app or a code editor.
Client: a connector living inside the host, holding a one-to-one link with a single server.
Server: a small program that offers something to the AI, such as access to files, a database, or an action it can perform.

According to the guide, servers can offer three kinds of things: context, meaning data the model can read, like documents or records; tools, meaning actions the model can ask to perform, like running a search or creating a file; and prompts, reusable templates for common tasks.

Under the hood, the messages follow JSON-RPC 2.0, a long-established format for one program asking another to do something. Two transports are supported at launch: standard input and output for a server running as a local process on your own machine, and HTTP with Server-Sent Events for servers reached over a network. When a connection opens, client and server first exchange their protocol versions and capabilities, so each side knows what the other can do.

What ships with the launch

Anthropic released three pieces together: the specification and software development kits (SDKs) for building servers and clients, support for local MCP servers in the Claude Desktop apps, and an open-source repository of ready-made servers. Those pre-built servers cover Google Drive, Slack, GitHub, Git, Postgres databases and Puppeteer, a tool for controlling a web browser.

Anthropic names Block and Apollo as early adopters, and says four developer-tool makers (Zed, Replit, Codeium and Sourcegraph) are building MCP into their products. All Claude.ai plans can connect MCP servers to the desktop app. The protocol's creators are two Anthropic engineers, David Soria Parra and Justin Spahr-Summers.

Why it matters, and what is still open

For builders, the appeal is reuse. Write a server for your inventory system once, and any MCP-aware assistant can use it. TechCrunch notes that the standard is meant to work with any model, not only Anthropic's.

It is also early. TechCrunch points out that rivals such as OpenAI may prefer their own connection methods, and that Anthropic has not yet published benchmarks showing how much MCP improves results. A standard only becomes a standard when others adopt it, and that will take time to see.

There are practical cautions too. An MCP server can give a model real access to real systems. The architecture guide reminds developers to add authentication where it's needed and to avoid leaking sensitive information. A sensible habit from day one: give each server the narrowest access it needs, and start with read-only data before granting actions.

Try it: If you use the Claude Desktop app, connect one of the ready-made servers, such as the Git server, to a practice repository that holds nothing private. Ask Claude to summarize the last five commits, then check its summary against the real history yourself.

What can you connect an AI assistant to with MCP?

Almost anything a program can reach. The servers released with the launch give a good picture of the range: files on your computer, documents in Google Drive, messages in Slack, code repositories in Git and GitHub, a Postgres database, and a web browser that the assistant can drive through Puppeteer. Because the protocol is open, anyone can write a new server for a system that isn't covered, whether that is a company's internal wiki, a calendar, or a spreadsheet of customer orders.

A useful way to plan is to sort your systems by what the assistant should be allowed to do:

Kind of access	Example	Risk level
Read only	Search last quarter's sales reports	Low
Read and draft	Prepare a Slack reply for you to send	Medium
Act	Create a GitHub pull request	Higher; review each action

Once a server is connected, you can ask in plain language and let the assistant decide which tool to call:

Prompt

Using the Postgres connection, find the ten customers with the most orders this month. Show their names and order counts in a table, and don't change any data.

Start with one low-risk, read-only source, see how the assistant uses it, and widen access only when you trust the setup. The same standard that makes connecting easy also makes it easy to connect too much.