Model Context Protocol (MCP): The shared plug that connects AI agents to tools and data

The Model Context Protocol (MCP) is an open standard that lets an AI application connect to outside systems, such as files, databases, search engines and business tools, in one common way. Its documentation compares it to a USB-C port: one shape of plug that works with many devices.

Without a shared standard, every AI app needs its own custom connection to every tool. MCP replaces that tangle with a single protocol.

One calendar, many assistants, one connector

Imagine you want an AI assistant to check your calendar and book a meeting. Before MCP, the developer of each assistant had to write separate code for each calendar service. A different assistant meant the same work again.

With MCP, the calendar company writes one small program, called an MCP server, that describes what it can do. Any AI app that speaks MCP can then use it. The MCP documentation lists similar examples: agents that reach Google Calendar and Notion, or Claude Code building a web app from a Figma design.

The benefit is a build-once, connect-everywhere model. Tool makers write one server, and AI app makers write one client.

Hosts, clients and servers talking in a common language

The specification names three roles. A host is the AI application the user works in. A client is a connector inside the host. A server is the service that provides context and abilities. They exchange messages in a format called JSON-RPC 2.0, which is a standard way to send a request and get a reply.

A server can offer three kinds of things:

• Resources: context and data, such as a document or database record.
• Prompts: templated messages and workflows for the user.
• Tools: functions the AI model can run, such as “create an event”.

The current specification also lets a server ask the user for more information, a feature called elicitation. The base protocol uses stateless, self-contained requests, and the two sides negotiate which capabilities they support on each request.

The designers say they took inspiration from the Language Server Protocol, which standardized how programming languages plug into code editors.

From an Anthropic open-source release to a Linux Foundation project

Anthropic open-sourced MCP on November 25, 2024. The release included the specification, software development kits (SDKs), support for local servers in the Claude Desktop apps, and ready-made servers for Google Drive, Slack, GitHub, Git, Postgres and Puppeteer. Block and Apollo were named as early adopters. Zed, Replit, Codeium and Sourcegraph were listed as working with it.

On December 9, 2025, Anthropic announced it was donating MCP to the Agentic AI Foundation (AAIF), a fund under the Linux Foundation. Anthropic, Block and OpenAI co-founded it. MCP joined Block’s goose and OpenAI’s AGENTS.md as founding projects. Anthropic said MCP’s governance model would stay unchanged, with maintainers continuing to weigh community input.

In that post, Anthropic reported more than 10,000 active public MCP servers and over 97 million monthly SDK downloads across Python and TypeScript. These are the company’s own figures. It named Google, Microsoft, Amazon Web Services, Cloudflare and Bloomberg as supporters.

Who builds on it today, including Microsoft’s Copilot harness

The MCP site says it is supported by assistants such as Claude and ChatGPT, and by development tools such as Visual Studio Code and Cursor.

It also shows up in agent platforms. When Microsoft opened up the harness behind its Copilot products, it said the harness supports open standards such as MCP and agent skills. Our report on that launch is here: Microsoft is selling the harness behind GitHub Copilot as a managed Foundry service.

That fits the role of MCP. An agent harness, the layer around a model that supplies instructions, context and controls, still needs a way to reach outside systems. MCP is one common answer, so a tool built once can work across many harnesses.

The specification also describes optional extensions. They include Tasks, for long-running operations that can be polled, and MCP Apps, which render interactive elements such as charts and forms inside a conversation. Extensions are opt-in and need support from both sides.

Powerful connections need careful permissions

A standard connector also means a standard way to cause harm if it is misused. The specification states that MCP enables “arbitrary data access and code execution paths” and that tools should be treated with caution. It sets out principles:

• Users must explicitly consent to data access and actions.
• Hosts must get consent before exposing user data to servers.
• Hosts must get consent before calling any tool.
• Tool descriptions and annotations should be treated as untrusted unless they come from a trusted server.

The specification also admits that MCP itself cannot enforce these principles at the protocol level. Builders are expected to create the consent screens and access controls. In practice, an agent that connects to many servers is only as safe as the servers it trusts and the permissions it is given.

Another practical limit is that a protocol only standardizes the connection. It does not make a model use a tool well. The quality of a server’s tool descriptions and the model’s judgment still decide whether a task succeeds.

What to watch as agents multiply

Three things are worth following. The first is governance under the Linux Foundation, where maintainers decide how the specification changes. The second is the extensions, such as Tasks and the work on delivering agent skills through MCP, which show where agent features are heading. The third is security practice: how hosts handle consent, and how users judge which servers to trust.

For readers choosing agent products, a simple question helps: which MCP servers does it connect to, and what can each one do on your behalf?