What Is Model Context Protocol (MCP)

The Problem MCP Solves

Before MCP, connecting AI models to external systems required custom code for every combination. If you built a tool integration for Claude, it would not work with ChatGPT, Gemini, or any other AI application. Each platform had its own plugin system, its own API conventions, and its own way of defining what tools were available. A developer who wanted their database tool to work across multiple AI platforms had to build and maintain separate integrations for each one.

This created an N-times-M scaling problem. With N AI applications and M external tools, you needed N times M separate integrations. Five AI apps connecting to ten tools required fifty custom implementations. MCP reduces this to N plus M by standardizing the connection layer. Each AI app implements the MCP client protocol once, each tool implements the MCP server protocol once, and they all work together automatically.

The practical impact is significant. A developer who builds an MCP server for PostgreSQL can be confident that it works with Claude Desktop, Claude Code, ChatGPT, Cursor, Windsurf, VS Code Copilot, and any other MCP-compatible host without writing a single line of platform-specific code. The server exposes database capabilities through the standard protocol, and any client can discover and use those capabilities.

How MCP Works at a High Level

MCP uses a client-server architecture built on JSON-RPC 2.0, the same message format used by the Language Server Protocol (LSP) that powers code intelligence in modern editors. An MCP host application (like Claude Desktop) creates a client connection to each MCP server it wants to use. Each server is a lightweight process that exposes specific capabilities, such as reading files, querying databases, or calling web APIs.

When the host connects to a server, the two sides negotiate capabilities. The server tells the client what tools, resources, and prompts it offers. The client passes this information to the AI model, which can then decide to use those capabilities when processing user requests. When the model wants to invoke a tool, it generates a structured call that the client sends to the appropriate server. The server executes the operation and returns the result, which the model incorporates into its response.

This entire process is transparent to the user. They ask a question or give an instruction, the model determines which tools would help, invokes them through MCP, and presents the result. The user does not need to know which MCP servers are connected or how the protocol works. They simply get better, more grounded responses because the model can access real data and real tools instead of relying solely on its training knowledge.

The Three Primitives

MCP servers expose capabilities through three types of primitives, each with different control semantics and use cases.

Tools are executable operations that produce side effects in external systems. Running a database query, creating a file, sending a message, calling an API, these are all tools. Tools are model-controlled, meaning the AI model decides when to invoke them based on the user's request. This makes tools the most powerful primitive but also the most security-sensitive, because the model is making decisions about when to execute actions that affect real systems.

Resources are read-only data that the model can access. File contents, configuration values, API responses, and database records all qualify as resources. Unlike tools, resources are application-controlled, meaning the host application or user decides when to include them in the model's context. Resources are inherently safer than tools because they cannot modify external systems.

Prompts are reusable, parameterized templates that define how the model should approach specific tasks. A code review prompt might accept a programming language and file path, then instruct the model with detailed review criteria. Prompts are user-controlled, meaning users explicitly select them rather than the model invoking them automatically. They encode best practices and institutional knowledge into reusable templates.

Origins and Timeline

Anthropic developed MCP internally and released it publicly in November 2024. The initial release included the protocol specification, reference SDKs for TypeScript and Python, a set of official servers for common tools (filesystem, GitHub, Slack, databases), and native integration in Claude Desktop. The project was open-source from the start, using the MIT license for SDKs.

Adoption accelerated rapidly through 2025. OpenAI added MCP support in early 2025 and later deprecated its Assistants API in favor of MCP. Google integrated MCP into Gemini. Microsoft added support in Copilot and VS Code. By mid-2025, MCP was supported by every major AI platform.

In December 2025, Anthropic donated MCP governance to the Linux Foundation's Agentic AI Foundation (AAIF), ensuring vendor-neutral stewardship. The AAIF, co-founded by Anthropic, OpenAI, Block, Google, and Microsoft, now manages both MCP and Google's A2A protocol. As of mid-2026, MCP has surpassed 97 million monthly SDK downloads and over 81,000 GitHub stars.

Why MCP Matters for Developers

For developers building AI-powered applications, MCP eliminates the need to design proprietary plugin or tool systems. Instead of inventing a custom way for your application to connect to external services, you implement the MCP client protocol and immediately gain access to thousands of existing MCP servers. Your application can connect to databases, filesystems, APIs, communication tools, and cloud services through a single protocol.

For developers building tools and integrations, MCP means building once and reaching every AI platform. An MCP server for your company's internal API works with every MCP-compatible AI application without modification. This dramatically reduces the integration and maintenance burden compared to building separate plugins for each platform.

For organizations deploying AI agents, MCP provides a consistent security and governance model. Each MCP server runs in its own process with its own permissions, creating clear security boundaries. The protocol supports OAuth 2.1 authentication for remote servers, permission scoping for operations, and audit logging for compliance. These features make MCP suitable for enterprise environments where security and governance are non-negotiable requirements.

MCP vs Other Approaches

MCP is often compared to function calling, REST APIs, and Google's A2A protocol, but each serves a different purpose. Function calling is the mechanism LLMs use to generate structured tool invocations. MCP is the infrastructure that discovers, routes, and executes those invocations. The two work together: the model uses function calling to express intent, and MCP handles fulfillment.

REST APIs remain the right choice for traditional backend integrations, scheduled jobs, and scenarios where tool discovery is not needed. MCP adds value specifically when AI agents need to dynamically discover available tools, maintain session context across multiple invocations, and chain operations together in multi-step workflows.

Google's A2A protocol handles agent-to-agent communication, which is a different layer entirely. MCP connects agents to tools (vertical), while A2A connects agents to other agents (horizontal). Production multi-agent systems typically use both protocols together.