What is the Model Context Protocol?
The Model Context Protocol (MCP) is an open communication standard that defines how AI applications — primarily large language models (LLMs) — connect to external tools, data sources and business systems. It is not an AI model, a library or a product. It is a protocol layer: a set of rules describing the message format, the connection lifecycle and the operation types used by both sides of the conversation.
In documentation and industry discourse, MCP is most often described as "USB-C for AI." Before USB-C standardised the market, every device needed its own connector and driver. Likewise, before MCP, connecting a model to a file repository, a PostgreSQL database or a coding environment required building a dedicated connector for each combination. MCP replaces that chaos with one universal interface: any standard-compliant client can connect to any standard-compliant data server.
The core problem MCP solves is known as the N×M problem. The number of AI applications and agents (N) was growing exponentially, as was the number of tools and data sources (M) they needed to reach — Google Drive, Slack, GitHub, Jira, database systems. Without a shared standard, connecting N models to M tools would require building and maintaining N × M separate integrations. MCP reduces that exponential complexity to a linear one (N + M): you build a single MCP server for a given system, and every compliant client gains access to it immediately.
Who is behind it?
MCP was developed and released as an open-source project under the MIT license by Anthropic on 25 November 2024. The direct inspiration was the frustration of its engineers — chiefly David Soria Parra and Justin Spahr-Summers — who kept rewriting the same data-access logic across successive projects. Conceptually the standard draws on Microsoft's Language Server Protocol (LSP), which had earlier unified programming-language support in code editors. On launch day Anthropic shipped not only the specification but also SDKs for Python and TypeScript and a set of reference servers (including GitHub, Google Drive, Slack and Postgres).
The turning point came in spring 2025. On 12 March 2025 OpenAI announced its adoption of MCP, with support in the Agents SDK, the ChatGPT desktop app and the Responses API — while signalling the wind-down of its own Assistants API. In April 2025 Google DeepMind followed: Demis Hassabis described MCP as a standard rapidly becoming an open foundation for the AI era, and native support in the Gemini API was shown at Google I/O in May 2025. Microsoft (GitHub Copilot, Visual Studio Code), MongoDB, Cloudflare and Amazon joined in turn. In December 2025 Anthropic handed governance of the standard to the Agentic AI Foundation under the Linux Foundation — a move that aligns MCP's governance with the likes of Linux and Kubernetes and is meant to guarantee neutrality toward any single vendor.
How does it work?
MCP rests on a client-server architecture that deliberately separates where the model's logic runs from where an organisation's data lives. The data layer uses the mature JSON-RPC 2.0 standard, providing strongly typed, predictable messages that work regardless of programming language.
Communication is bidirectional and stateful — the system remembers session history and keeps an open connection, supporting features such as streaming of partial results. This sets MCP apart from the one-way calls of traditional APIs. A typical connection cycle runs in four steps. The first is initialisation (the handshake), where client and server agree on compatible versions and capabilities. The second is capability discovery, when the client fetches the list of available tools and resources (tools/list, resources/list). The third is model routing, where the LLM picks the right tool based on the descriptions. The fourth is invocation (tools/call), where the server physically performs the operation and returns a structured response.
A key consequence of this architecture is security. The model and host receive only the communication logic layer — the actual API keys to target services (Google Drive, Slack, Jira) stay locked on the MCP server side, reducing the risk of credential leakage.
- Negotiated protocol version & capabilities
What are its key components?
Three actors
MCP’s architecture operates on three actors, each playing a distinct role in the communication chain.
- Host — this is the very application you work in (e.g. Claude Desktop, Cursor or Visual Studio Code with GitHub Copilot), not a separate intermediary layer. The host contains the model (or calls it via an API), provides the user interface, and creates and manages MCP clients — it can handle several connections at once.
- MCP client — a lightweight process embedded in the host, usually in a 1:1 relationship with a server. It translates the model’s intentions into formal JSON-RPC requests and maintains the connection.
- MCP server — an independent service that exposes data and capabilities to models: from files and PostgreSQL databases to external APIs. Importantly, the target service itself (e.g. GitHub, PostgreSQL, Slack) requires no changes or special endpoints — it is the MCP server that acts as an adapter, translating standard MCP calls into the service’s native API. You write such an adapter once, and any MCP-compatible host can use it.
Three protocol primitives
The second axis is the three protocol primitives?Protocol primitives: The basic, indivisible building blocks of interaction from which all communication between the model and the server is composed., distinguished by who initiates the operation.
- Tools — a model-controlled surface: the LLM decides when to invoke an action (for example posting a Slack message), and new annotations allow operations to be marked read-only or destructive.
- Resources — an application-controlled surface: persistent, read-only data identified by URIs (e.g.
file:///repo/logs/apache.md) that trigger no action but enrich the model’s context. - Prompts — a user-controlled surface: reusable query templates stored on the server that standardise complex workflows.
Two transport mechanisms
At the transport level, MCP defines two mechanisms, chosen by whether the server runs locally or remotely.
- stdio — the default local form: the client launches the server as a subprocess and communicates over standard streams (
stdin/stdout?stdin / stdout: The standard input and output streams of a process on Unix-like systems. stdin (standard input) is the channel a program reads incoming data from, and stdout (standard output) is the channel it writes its results to. With the stdio transport the MCP client and server exchange messages over exactly these two streams, with no network sockets or ports.), with no network ports — simple and secure for work within a single machine. In this variant the server is simply a program launched locally by the host — you install and configure it yourself, and API keys stay on your own machine. - HTTP with Server-Sent Events (SSE) — evolving toward “Streamable HTTP?Streamable HTTP: Streamable HTTP is a newer HTTP transport in MCP that replaces the earlier pairing of a plain HTTP channel with a separate SSE endpoint, using a single endpoint instead. The server answers with an ordinary HTTP response and, when it needs to stream data such as partial results, dynamically upgrades that response to a Server-Sent Events stream. This simplifies remote deployments and handling many concurrent clients.” — handles remote scenarios and many concurrent clients, at the cost of requiring rigorous authorisation. Here the server runs as a remote service hosted and maintained by someone: the tool’s vendor, your own infrastructure team, or a third-party platform.
PostgreSQL
Slack
Ready to start
Press "Next step" or "Play the whole cycle" to trace how MCP components exchange information — from creating the client to the streamed response.
💡 Click a primitive (Tools / Resources / Prompts) to see how step 5 changes — each one is initiated by a different party. The stdio / HTTP switch changes the transport in step 2.
MCP and AI agents
This whole architecture only makes full sense in the context of AI agents. An AI agent is a system that does not merely answer questions like an ordinary chatbot, but independently plans and carries out multi-step tasks — making decisions, reaching for data and triggering actions to achieve a given goal. The difference is fundamental: a chatbot talks, an agent acts.
But to act, an agent needs "hands and senses" — a way to read data and perform operations in real systems. That is exactly the role MCP plays: it provides a standard interface through which an agent discovers available tools, reads resources and invokes actions, regardless of which service it connects to. Without such a layer every integration would have to be built by hand, which made autonomous agent behaviour impractical. MCP turns the model from an isolated conversationalist into a system that can act — and for a broader introduction to what agents are and how they work, see our separate insight.
What can it be used for?
The broadest use case is giving AI models real-time access to company data. MCP servers expose databases — MongoDB published an official server that lets you query data in natural language — document repositories, file systems and external APIs. A second area is developer tooling?developer tooling: Developer tooling is the set of tools developers use to write, test and ship software — code editors, version-control systems (e.g. GitHub), CI/CD platforms and cloud services.: GitHub, Visual Studio Code, Cloudflare and Amazon Bedrock integrate MCP so AI agents can read code, run tasks and operate on infrastructure.
MCP is also used in marketing and CMS?CMS: A CMS (Content Management System) is software for creating, editing and publishing website content without hand-coding it (e.g. WordPress, Umbraco). systems (for example Umbraco integrations), where it manages thousands of content items and campaigns through intentions directed at the model. The standard is also gaining trust in finance, where security requirements are especially high — one example being Block (the company behind Cash App), which helps govern the foundation developing MCP. Its involvement shows the standard is fit for deployments where data security is critical. The common denominator across all these use cases is turning the model from an isolated chatbot into a system capable of acting on real resources.
How does it differ from other approaches?
The most common point of comparison is function calling, familiar from the OpenAI platform among others. Function calling lets a model invoke a function, but each integration has to be built separately, from scratch for every platform. MCP raises that idea to the level of an open standard: one server works with every compliant client, regardless of the model provider.
It is also worth distinguishing MCP from Retrieval-Augmented Generation (RAG). RAG supplies the model with context by retrieving fragments from a static vector store. MCP works differently — it is a bridge to live systems, operating on demand, that not only reads data but lets the model perform operations. In practice the two approaches work well together, but MCP covers a far wider range of interaction than context retrieval alone.
Key limitations and challenges
MCP's biggest challenge is security. When a model gains deep access to files, code and databases, the attack surface grows. In early 2025 researchers published audits pointing to many different ways to attack them — according to those analyses a significant share of early, amateur MCP servers were vulnerable to command injection?command injection: Command injection is an attack where the attacker sneaks their own system commands into an application so the server runs them — e.g. executing unwanted programs on the victim’s machine.. Prompt injection?Prompt injection: Prompt injection is an attack where malicious instructions hidden in data (e.g. in a file or web page) hijack the model and make it act against the user’s intent., tool impersonation ("lookalike tools?lookalike tools: Lookalike tools are fake tools that mimic trusted ones — using a deceptively similar name or description to trick the model into using them to steal data or perform a harmful action.") and data exfiltration were also reported. The percentages quoted should be treated as estimates from an early-stage ecosystem rather than hard, settled data.
The specification's response is to base HTTP transport authorisation on OAuth 2.1 with PKCE: the MCP server acts as a protected resource, and tokens are precisely scoped to a specific server and access range — moving away from the weaknesses of static API keys. Authorisation remains optional, however, and does not apply to local connections — when the server runs on the same machine as the application (the stdio transport), trust comes from the process being launched locally in the first place. Remaining challenges include the maturity of long-running asynchronous operations and the lack of settled mechanisms for platform-level attestation of agent identity.
Why does it matter?
The speed at which MCP became an industry standard is unusual even by software standards. In a little over a year the protocol went from one company's internal project to a layer supported by every major model provider and handed to a neutral foundation. It is a rare case of competitors adopting a rival's standard rather than fighting over formats — a signal that the market judged interoperability to be more important than control over a proprietary interface.
MCP's significance goes beyond integration convenience. The standard shifts value away from a model's ability to merely "chat" and toward its embedding in real business processes — it is in the servers, not the chat window, that the logic of access, permissions and security lives. If the forecasts about AI agents operating autonomously in enterprise environments hold, MCP stands a chance of serving as the common bus through which those systems talk to the world. Caution is warranted, though: some adoption figures are early analyst estimates, and key questions about agent security remain open.
MCP is therefore not another buzzword but a carefully designed infrastructure layer — and it is precisely this "boring," protocol-level nature that makes it a potentially durable foundation for the coming years of AI-agent development.