CtrlK
The Model Context Protocol (MCP) is an open protocol that standardizes the way artificial intelligence systems, particularly large language models (LLMs), connect to and interact with external data sources, tools, and services. Introduced by Anthropic on November 25, 2024, MCP provides a universal interface that replaces the need for custom, one-off integrations between AI applications and the systems they rely on for context [1]. The protocol uses JSON-RPC 2.0 as its wire format and draws direct inspiration from the Language Server Protocol (LSP) used in software development environments [2]. In December 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation co-founded by Anthropic, Block, and OpenAI, establishing it as a vendor-neutral industry standard [3].
Before MCP existed, connecting AI applications to external tools and data sources required developers to build custom integrations for each combination of AI model and external service. This created what engineers refer to as the "M x N integration problem": if there are M different AI applications and N different tools or data sources, the total number of custom integrations needed is M multiplied by N. Connecting ten AI applications to 100 tools, for example, could require up to 1,000 separate custom connectors [4].
Each of these connectors would have its own authentication logic, data formatting requirements, error handling patterns, and maintenance burden. As the number of AI applications and available tools grew throughout 2023 and 2024, this approach became increasingly unsustainable. Developers spent more time writing and maintaining integration code than building the actual AI features they cared about.
MCP reduces this combinatorial explosion to an M + N problem. Each AI application implements the MCP client protocol once, each tool or data source implements the MCP server protocol once, and any client can communicate with any server. In the example above, instead of 1,000 custom integrations, only 110 implementations (10 clients plus 100 servers) are needed [4].
The design philosophy behind MCP closely mirrors the approach that the Language Server Protocol (LSP) took for code editors and IDEs. Before LSP, every code editor needed a separate plugin for every programming language. LSP introduced a common protocol so that any editor supporting LSP could work with any language server. MCP applies the same principle to AI applications and their data sources [2].
Anthropic announced MCP on November 25, 2024, through a blog post titled "Introducing the Model Context Protocol" [1]. The protocol was released as an open-source project under the MIT License, with the full specification and reference implementations published on GitHub under the modelcontextprotocol organization [5].
At launch, Anthropic provided software development kits (SDKs) in Python and TypeScript, along with pre-built MCP servers for several popular services including GitHub, Google Drive, Slack, Git, PostgreSQL, and Puppeteer [1]. The Claude Desktop application shipped with built-in MCP support, making it the first major AI client to natively support the protocol.
The initial release went largely under the radar. Industry attention in late 2024 was focused on other AI developments, and MCP did not gain widespread attention until early 2025 [6].
MCP follows a client-server architecture with three distinct roles: hosts, clients, and servers.
| Component | Role | Examples |
|---|---|---|
| MCP Host | The AI application that the end user interacts with. It creates and manages MCP client instances. | Claude Desktop, Claude Code, Cursor, VS Code with Copilot |
| MCP Client | A protocol-level component within the host that maintains a one-to-one connection with a specific MCP server. Each client handles session lifecycle, capability negotiation, and message routing for its server connection. | Built into the host application |
| MCP Server | A lightweight program or service that exposes specific capabilities (tools, resources, prompts) to clients through the standardized MCP interface. | GitHub MCP server, PostgreSQL MCP server, filesystem MCP server |
A single host application can run multiple MCP clients simultaneously, each connected to a different MCP server. For instance, Claude Desktop might have one client connected to a GitHub server, another connected to a Slack server, and a third connected to a local filesystem server, all at the same time [2].
An MCP session follows a defined lifecycle. The client initiates a connection to the server and sends an initialize request that includes the protocol version and client capabilities. The server responds with its own capabilities, indicating which features it supports (tools, resources, prompts, etc.). The client then sends an initialized notification to confirm the handshake. From this point, both sides can exchange requests and notifications. Either side can terminate the session by closing the transport or sending a shutdown request [2].
All MCP communication uses JSON-RPC 2.0. This means every message is either a request (which expects a response), a response, or a notification (a one-way message that does not expect a reply). Both clients and servers can initiate requests, enabling bidirectional communication. Messages are serialized as JSON, which provides broad language compatibility and human readability [7].
MCP defines several core primitives that describe the types of capabilities a server can expose. Each primitive has a different control model, reflecting who decides when and how it gets used.
Tools are executable functions that an MCP server makes available. Each tool has a name, a description, and a JSON Schema defining its expected inputs. When the LLM determines that a tool would be useful for answering a query, the host application can invoke that tool on the server. Tools are "model-controlled," meaning the AI model decides when to call them (subject to user approval). Examples include searching a database, creating a GitHub issue, or sending a Slack message [8].
Each tool invocation typically requires explicit user approval before execution, providing a human-in-the-loop safety mechanism.
Resources represent data or content that a server can expose for reading. A resource might be a file on disk, a database record, a live API response, or a screenshot. Resources are identified by URIs and can be either static (with a fixed URI known in advance) or dynamic (discovered through templates). Resources are "application-controlled," meaning the host application decides how and when to fetch and use them, rather than the AI model making that decision autonomously [8].
Prompts are pre-written templates that servers can offer to guide how an AI model should handle specific tasks. A prompt might include system instructions, structured message sequences, or contextual framing tailored to a particular use case. Prompts are "user-controlled": the user explicitly selects which prompt to apply. For example, a code review server might offer a prompt template that instructs the model to focus on security vulnerabilities [8].
Sampling is a capability that allows servers to request LLM completions through the client. Rather than the server directly calling an LLM API, it sends a sampling request to the client, which then routes it to the LLM. This design keeps the client (and by extension, the user) in control of all LLM interactions. Sampling enables more sophisticated agentic workflows where a server can leverage the LLM's reasoning abilities as part of its processing pipeline [8].
Roots are URIs that a client provides to a server to indicate which resources or scopes the server should focus on. For example, a client might tell a filesystem server that it should only operate within a specific project directory. Roots help servers understand the boundaries of their operating context [8].
Introduced in the June 2025 specification, elicitation allows servers to request additional information from the user through the client. If a server needs clarification or a decision from the user during a task, it can send an elicitation request that the client presents to the user, collects their response, and sends back to the server [9].
MCP is transport-agnostic at its core, but the specification defines standard transport mechanisms for common use cases.
| Transport | Use Case | How It Works | Status |
|---|---|---|---|
| stdio | Local integrations, CLI tools | Client spawns the server as a subprocess. Messages flow through standard input (stdin) and standard output (stdout), delimited by newlines. | Active, recommended for local use |
| Streamable HTTP | Remote connections, cloud-hosted servers | Uses a single HTTP endpoint. Client-to-server messages go via HTTP POST. Server-to-client messages use Server-Sent Events (SSE) for streaming. | Active since March 2025, recommended for remote use |
| HTTP with SSE (legacy) | Remote connections | Used separate endpoints for sending and receiving. | Deprecated in favor of Streamable HTTP |
| Custom | Specialized deployments | Any transport that supports bidirectional JSON-RPC messaging can be used. | Supported |
The stdio transport is well-suited for local development and desktop applications where the server runs on the same machine as the client. Streamable HTTP is designed for production deployments where servers run remotely, and was introduced in March 2025 to replace the earlier SSE-based transport with a more flexible approach that supports both stateful and stateless server architectures [10].
MCP is not the first attempt to give AI models access to external tools. Understanding how it differs from prior approaches helps clarify its value proposition.
Function calling (also known as tool calling) is a feature built into most modern LLM APIs. The developer defines functions as JSON schemas in the API request, the model decides when to call them, and the application executes the function locally. Function calling works well for simple, self-contained integrations but has significant limitations at scale [11].
With function calling, tool definitions are tightly coupled to specific LLM providers. Switching from one model to another often requires rewriting tool definitions. There is no standard discovery mechanism; tools must be hardcoded into each application. And the M x N problem remains: every application must implement its own connection to every tool.
MCP addresses these limitations by providing a provider-agnostic standard. An MCP server works with any MCP client regardless of which LLM it uses. Tools are discovered dynamically through the protocol rather than hardcoded.
OpenAI introduced ChatGPT plugins in March 2023 as a way to extend ChatGPT's capabilities. Plugins were restricted to the ChatGPT ecosystem and relied on OpenAPI specifications. OpenAI deprecated the plugin system in April 2024, later replacing it with GPTs and Actions. ChatGPT plugins demonstrated the demand for tool integration but were limited by their vendor-specific nature [11].
Many AI applications build direct REST API or GraphQL integrations with specific services. This approach offers maximum flexibility and performance but creates the M x N problem at full scale. Each integration requires custom authentication handling, data transformation logic, and ongoing maintenance. MCP does not eliminate the need for APIs entirely; rather, MCP servers often wrap existing APIs behind a standardized interface [11].
| Approach | Standardized | Provider-Agnostic | Dynamic Discovery | Bidirectional | Reusable Across Apps |
|---|---|---|---|---|---|
| Function Calling | Partially | No | No | No | No |
| ChatGPT Plugins | Yes (OpenAPI) | No (ChatGPT only) | Yes | No | No |
| Custom Integrations | No | N/A | No | Varies | No |
| MCP | Yes | Yes | Yes | Yes | Yes |
MCP adoption accelerated rapidly in 2025, going from a niche protocol to an industry-wide standard within roughly a year.
| Date | Milestone |
|---|---|
| November 2024 | Anthropic launches MCP with Claude Desktop support |
| Early 2025 | Cursor, Cline, and Windsurf add MCP support |
| March 2025 | OpenAI adopts MCP across its Agents SDK, Responses API, and ChatGPT Desktop [12] |
| April 2025 | Google DeepMind adopts MCP for Gemini [12] |
| Mid-2025 | VS Code (via GitHub Copilot), Zed, JetBrains IDEs, and Sourcegraph add MCP support |
| September 2025 | MCP Registry preview launches for server discovery |
| November 2025 | Updated specification (2025-11-25) released with Tasks, OAuth improvements, and extensions [13] |
| December 2025 | MCP donated to the Agentic AI Foundation under the Linux Foundation [3] |
By early 2026, MCP is natively supported by virtually every major AI development tool and assistant. Claude Desktop and Claude Code were the first adopters. Cursor, the AI-native code editor, added MCP support in early 2025, allowing its AI assistant to access project files, run terminal commands, and interact with version control through MCP servers. VS Code integrated MCP through its GitHub Copilot extension, and in June 2025 published a blog post announcing "full MCP spec support" [14]. JetBrains added MCP to its AI Assistant plugin, and Zed and Sourcegraph both implemented client support.
On the general-purpose AI side, OpenAI's adoption in March 2025 was a turning point. The company integrated MCP into its Agents SDK and the ChatGPT Desktop app. Google followed in April 2025 with MCP support in Gemini. Microsoft integrated MCP across its Copilot products [12].
By November 2025 (the protocol's first anniversary), the MCP ecosystem had grown to over 97 million monthly SDK downloads across the Python and TypeScript SDKs, more than 10,000 active servers, and first-class client support from Anthropic, OpenAI, Google, and Microsoft [6]. The PulseMCP directory listed over 7,800 servers by early 2026 [15].
The MCP ecosystem consists of official servers maintained by the modelcontextprotocol GitHub organization, vendor-maintained servers from platform companies, and a large community of third-party servers.
Anthropic released several reference MCP servers at launch, maintained under the official GitHub organization.
| Server | Description |
|---|---|
| Filesystem | Direct read/write access to the local file system |
| GitHub | Repository management, issues, pull requests, and code search |
| Google Drive | File listing, searching, and reading from Google Drive |
| Slack | Channel management, messaging, and search |
| PostgreSQL | Read-only database access with schema inspection |
| SQLite | SQLite database operations and queries |
| Git | Git repository operations |
| Puppeteer | Browser automation and web scraping |
As MCP adoption grew, platform companies began building and maintaining their own official MCP servers. By early 2026, companies including Datadog, Stripe, Cloudflare, Notion, Linear, Sentry, and many others had released production-ready MCP servers for their platforms. Datadog announced the general availability of its MCP server on March 9, 2026, enabling AI agents to access live observability data [16].
The community-developed server ecosystem expanded rapidly. The awesome-mcp-servers repository on GitHub became a popular directory, cataloging hundreds of community-built servers spanning domains from databases and cloud infrastructure to productivity tools and scientific research. Community servers are not affiliated with or endorsed by Anthropic, and users are advised to evaluate them carefully before deployment [15].
Official SDKs are available for Python, TypeScript, Go, Kotlin, C#, Java, and PHP. The Python and TypeScript SDKs are the most mature, with the broadest feature coverage and the largest user bases [5].
MCP uses date-based versioning in YYYY-MM-DD format.
| Version | Key Changes |
|---|---|
| 2024-11-05 | Initial specification. Defined core primitives (tools, resources, prompts), stdio and SSE transports, and JSON-RPC 2.0 messaging. |
| 2025-03-26 | Introduced Streamable HTTP transport to replace SSE. Added support for stateless server deployments. |
| 2025-06-18 | Added structured tool outputs, OAuth 2.0-based authorization, elicitation for server-initiated user interactions, and improved security best practices [9]. |
| 2025-11-25 | Major update on the protocol's first anniversary. Added Tasks primitive for tracking long-running server operations, Client ID Metadata Documents (CIMD) for simplified OAuth, Cross App Access for enterprise SSO, incremental scope management, mandatory PKCE, and authorization extensions [13]. |
On April 9, 2025, Google announced the Agent-to-Agent (A2A) protocol, with backing from over 50 companies including Atlassian, Salesforce, and PayPal [17]. While MCP and A2A might appear to be competing standards, they address different layers of the AI integration stack.
MCP focuses on vertical integration: connecting a single AI agent to the tools, data sources, and services it needs to do its work. A2A focuses on horizontal integration: enabling multiple AI agents to discover, communicate with, and delegate tasks to one another [17].
Google explicitly positioned A2A as complementary to MCP. In its announcement, Google stated that "A2A is an open protocol that complements Anthropic's MCP, which provides helpful tools and context to agents" [17].
To illustrate the distinction: in a car repair shop analogy, MCP is the protocol that connects mechanics (agents) to their structured tools ("raise platform by 2 meters," "turn wrench 4 mm to the right"). A2A is the protocol that lets a customer communicate with the shop, or that allows one mechanic to delegate a subtask to a specialist [18].
A2A introduces concepts not present in MCP, such as Agent Cards (JSON metadata documents describing an agent's capabilities and contact information) and a Task lifecycle model with states like submitted, working, input-required, completed, failed, and canceled [17].
In practice, many production systems may use both protocols: MCP to connect agents to their tools, and A2A to orchestrate multi-agent workflows.
MCP's power comes from giving AI models access to real-world systems, which introduces significant security risks. Several classes of vulnerabilities have been identified by security researchers.
Prompt injection is a general LLM vulnerability, but MCP environments amplify its impact. Instead of merely generating misleading text, a successful prompt injection in an MCP context can trigger automated actions through connected tools: reading sensitive files, sending messages, modifying databases, or executing code. Security researcher Simon Willison published a detailed analysis of MCP's prompt injection risks in April 2025 [19].
Tool poisoning occurs when an attacker embeds malicious instructions within an MCP tool's description metadata. Since the LLM reads tool descriptions to decide how to use them, poisoned descriptions can manipulate model behavior. A variant of this attack, sometimes called a "rug pull," involves dynamically changing a tool's description after initial user approval [20].
In HTTP-based MCP deployments, session IDs determine where the server sends responses. If an attacker obtains a valid session ID, they can inject requests that the server processes as if they came from the legitimate client. The November 2025 specification addressed this by requiring secure, non-deterministic session IDs generated with cryptographically secure random number generators [20].
Because MCP sampling allows servers to craft prompts and request LLM completions through the client, malicious servers can inject hidden instructions, manipulate model outputs, and potentially influence subsequent tool executions. Palo Alto Networks' Unit 42 published research on these attack vectors [21].
The MCP specification recommends several security practices: maintaining a human in the loop for tool invocations, implementing strict input validation on both client and server sides, applying the principle of least privilege (granting servers only the minimum necessary permissions), and conducting regular security audits of MCP server configurations. The November 2025 specification made PKCE mandatory for OAuth flows and introduced incremental scope management to avoid over-permissioned tokens [13].
On December 9, 2025, the Linux Foundation announced the formation of the Agentic AI Foundation (AAIF). Anthropic donated MCP as a founding project, alongside Block's Goose (an open-source agent framework) and OpenAI's AGENTS.md (a repository instruction file for AI coding tools) [3].
Platinum members of the AAIF include Amazon Web Services, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, and OpenAI. The foundation provides a neutral home for developing, governing, and extending agent interoperability standards [3].
This governance move was widely seen as the most significant signal about MCP's long-term trajectory. By placing the protocol under a vendor-neutral foundation with backing from all major AI companies, Anthropic ensured that MCP's evolution would not be controlled by any single company [6].
Within the AAIF, MCP development is now organized around Working Groups and Interest Groups, formalized through SEP-1302. A Governance Working Group is developing a Contributor Ladder that defines progression from community participant to core maintainer [22].
As of March 2026, MCP is the de facto integration layer for agentic AI, natively supported by Anthropic, OpenAI, Google, and Microsoft and deployed across millions of daily active developer tool users [22].
The MCP roadmap, last updated on March 5, 2026, is organized around four priority areas [22]:
Transport and Scaling: Streamable HTTP revealed gaps around horizontal scaling and stateless operation in production environments. The protocol is being evolved to support running across multiple server instances with proper session creation, resumption, and migration.
Governance: Formalizing the Working Group and Interest Group structure, developing the Contributor Ladder, and ensuring transparent decision-making.
Enterprise Readiness: Addressing the needs of enterprise deployments, including audit trails, SSO-integrated authentication, gateway behavior standardization, and configuration portability.
Tasks Primitive Maturation: The Tasks primitive, shipped as experimental in November 2025, is being hardened with production feedback. Concrete lifecycle gaps around retry semantics and expiry policies are being addressed.
JFrog announced the general availability of the JFrog MCP Registry on March 18, 2026, described as an enterprise-scale control plane for governing and securing MCP servers [23]. The MCP Registry preview, launched in September 2025, continues to grow as an open catalog and API for indexing and discovering MCP servers.
MCP is not without its critics. In March 2026, Perplexity CTO Denis Yarats announced that his company was moving away from MCP toward traditional APIs and CLI tools. Engineers at several companies have reported that MCP's promise of interoperability comes with costs that were not immediately obvious: high token consumption (because tool descriptions and resource content must be included in the LLM's context window), authentication friction in complex enterprise environments, and reduced agent autonomy in certain architectures [24].
These criticisms reflect growing pains rather than fundamental flaws. The 2026 roadmap directly addresses many of these concerns, and the protocol's governance structure provides a mechanism for the community to drive improvements.
The MCP specification, SDKs, and official server implementations are all open source under the MIT License. The main repository is hosted at github.com/modelcontextprotocol/modelcontextprotocol, with separate repositories for each SDK and for the official server collection [5].
The MIT License was chosen to maximize adoption by allowing both commercial and non-commercial use with minimal restrictions. Since the donation to the AAIF, the project is formally hosted by the Linux Foundation and open to contributions from the entire community [3].