Model Context Protocol (MCP): Complete Guide
In This Guide
What Is the Model Context Protocol
The Model Context Protocol is a client-server protocol built on JSON-RPC 2.0 that standardizes how AI applications discover and invoke external capabilities. Before MCP, every AI tool integration was a bespoke connection. If you wanted Claude to query a database, you wrote custom code for that specific model, that specific database, and that specific application. If you then wanted ChatGPT to access the same database, you wrote entirely new integration code. The same database, the same operation, but completely different implementations.
MCP eliminates this duplication by introducing a standard protocol layer between AI models and external systems. A developer builds one MCP server that exposes database capabilities, and any MCP-compatible AI client can connect to it and use those capabilities without additional integration work. The protocol handles discovery, authentication, invocation, and result formatting in a consistent way regardless of which model or application is on the other end.
The analogy that captured industry attention early on was USB. Before USB, every peripheral needed its own port, cable, and driver. Printers used parallel ports, mice used serial ports, keyboards used PS/2 connectors. USB introduced one standard interface that all peripherals could implement, and the industry consolidated around it. MCP aims to do the same for AI tool integration. One protocol, one interface, any tool, any model.
Anthropic released the MCP specification publicly in November 2024 alongside reference implementations in TypeScript and Python, a set of official servers for common tools like filesystem access and GitHub, and native support in Claude Desktop. The project was open-source from day one, using the MIT license for SDKs and a specification license designed for broad adoption. This open approach proved critical to adoption, as competing AI providers could implement MCP without any concern about vendor lock-in or licensing constraints.
Why MCP Exists
The fundamental problem MCP solves is the N-times-M integration challenge. In a world with N different AI applications and M different external tools, connecting everything requires N times M custom integrations. Five AI agents connecting to ten tools means fifty separate integration implementations, each with its own authentication handling, error management, schema definition, and maintenance burden. As both N and M grow, the integration work grows multiplicatively, and the ecosystem fragments into incompatible silos.
MCP reduces this to N plus M. Each AI application implements the MCP client protocol once, and each external tool implements the MCP server protocol once. The five agents each implement one client, the ten tools each implement one server, and every agent can immediately use every tool. Fifteen implementations instead of fifty, with every new agent or tool automatically compatible with the entire ecosystem.
This problem was becoming acute by late 2024. The AI agent ecosystem was expanding rapidly, with tools like Claude Desktop, Cursor, Windsurf, VS Code Copilot, and dozens of other AI-powered applications all needing access to external data and tools. Each was building its own plugin system, its own integration framework, and its own tool protocol. Developers who wanted their tool to work everywhere had to build and maintain separate integrations for each platform. The situation closely mirrored the pre-USB peripheral landscape, and the industry was ready for a standard.
Beyond reducing integration work, MCP brings consistency to how AI agents interact with external systems. Without a standard, every integration makes its own decisions about error formatting, capability discovery, authentication flow, and result structure. With MCP, these concerns are handled by the protocol specification. A developer building an MCP server for Postgres knows exactly how to expose query capabilities, how errors should be reported, how the client discovers available operations, and how authentication works. This consistency reduces bugs, simplifies debugging, and makes it practical to build reusable tool infrastructure.
Architecture: Hosts, Clients, and Servers
MCP uses a layered architecture with three distinct roles: hosts, clients, and servers. Understanding how these roles interact is essential for working with MCP effectively, because the architecture intentionally separates concerns that many integration approaches conflate.
The host is the user-facing application that provides the AI experience. Claude Desktop, Claude Code, Cursor, Windsurf, and VS Code with Copilot are all examples of MCP hosts. The host manages the overall user interaction, coordinates between multiple connected tools, enforces security policies, and decides which MCP servers to connect to. A single host typically connects to multiple MCP servers simultaneously, giving the AI model access to a diverse set of capabilities within one conversation.
The client is the protocol-level component that maintains a connection to a single MCP server. Each host creates one client per connected server, and each client manages its own independent session, capability set, and connection state. This one-to-one relationship between clients and servers ensures that interactions with one server cannot interfere with another. The client handles the JSON-RPC message exchange, capability negotiation, transport management, and session lifecycle for its assigned server.
The server is a lightweight process that exposes specific capabilities through the MCP protocol. An MCP server might provide access to a filesystem, a database, a search engine, a version control system, or any other external resource. Servers are designed to be focused and composable. Rather than building one massive server that does everything, the MCP philosophy encourages small servers that each do one thing well. A developer might run separate MCP servers for filesystem access, GitHub operations, and database queries, with the host client connecting to all three simultaneously.
This architecture creates clean security boundaries. Each server runs in its own process with its own permissions. The filesystem server might have read access to a project directory but nothing else. The database server might have query access but not schema modification rights. The host enforces which servers the model can connect to, and each server enforces what operations are available through it. This layered permission model is more secure than monolithic integrations where a single component has broad access to everything.
The separation of host, client, and server also enables deployment flexibility. Servers can run locally on the developer's machine, on a remote server, or in a cloud environment. A team might run shared MCP servers for company databases and internal tools while individual developers run local servers for their personal file systems and development environments. The protocol handles both scenarios identically, abstracting away the deployment topology from the model and the user.
The Three Core Primitives
MCP servers expose capabilities through three core primitives: tools, resources, and prompts. Each primitive serves a distinct purpose and carries different control semantics. Understanding which primitive to use for a given capability is one of the most important design decisions when building MCP servers.
Tools are executable operations that produce side effects. When an AI model calls a tool, something happens in the external world. A database row gets inserted, an email gets sent, a file gets written, an API endpoint gets called. Tools are the most powerful and the most security-sensitive primitive. They are model-controlled, meaning the AI model decides when and how to invoke them based on its analysis of the user request. The model receives tool descriptions, evaluates the user's intent, and generates structured calls with appropriate arguments. Examples include running a SQL query, creating a GitHub issue, sending a Slack message, or executing a shell command.
Resources are data that the model can read. File contents, database records, API responses, configuration values, and system status information all qualify as resources. Unlike tools, resources are application-controlled, meaning the host application or the user decides when to include resource data in the model context. Resources are identified by URIs and can be either static (a specific file) or dynamic (the output of a template query). They do not produce side effects, they simply provide information. The distinction matters because resources are inherently safer than tools, they can be loaded freely without risk of unintended modifications to external systems.
Prompts are reusable, parameterized templates that standardize how the model approaches specific tasks. A code review prompt might accept a language and file path, then assemble a detailed system message instructing the model how to review that type of code. A data analysis prompt might define the structure and tone for analyzing a dataset. Prompts are user-controlled, meaning they are typically selected explicitly by the user rather than automatically by the model. They represent best practices and institutional knowledge encoded as templates, moving prompt engineering from ad-hoc user input into structured, versioned, reusable server assets.
The rule of thumb is straightforward: if your MCP server only needs to give the model information, expose a resource. If it needs to do something in the external world, expose a tool. If you want to template how the model approaches a specific class of task, expose a prompt. Most production MCP servers expose tools and resources, while prompts are less commonly used but highly valuable for teams that want to enforce consistent agent behavior across developers.
Transport Mechanisms
MCP supports two transport mechanisms for communication between clients and servers: stdio and Streamable HTTP. The transport layer handles message delivery while the protocol layer above it handles the semantics of tool calling, resource reading, and prompt selection.
Stdio transport uses standard input and output streams for communication. The host launches the MCP server as a child process and communicates with it by writing JSON-RPC messages to the server's stdin and reading responses from its stdout. This is the simplest transport, requiring no network configuration, no port management, and no authentication infrastructure. It is the default choice for local MCP servers and the transport used by Claude Desktop and Claude Code for locally installed servers. Stdio transport is fast, reliable, and secure because all communication stays within the local machine.
Streamable HTTP transport, introduced in the November 2025 specification revision, enables MCP servers to run as remote network services. It replaces the original Server-Sent Events (SSE) transport with a more flexible HTTP-based protocol that supports both stateful and stateless operation modes. A remote MCP server exposes an HTTP endpoint, and clients connect to it using standard HTTP requests. This transport supports authentication via OAuth 2.1, session management across reconnections, and horizontal scaling behind load balancers. Streamable HTTP makes it practical to deploy shared MCP servers that multiple users and applications can access, which is essential for enterprise environments where tools and data sources are centrally managed.
The choice between transports is primarily a deployment decision. Local development tools, personal utilities, and single-user servers typically use stdio because it requires zero configuration. Shared team servers, cloud-hosted tool services, and enterprise integrations use Streamable HTTP because they need remote access, authentication, and multi-user support. The protocol semantics are identical regardless of transport. An MCP server that works over stdio can be adapted to Streamable HTTP without changing any of its tool, resource, or prompt implementations.
Capability Negotiation and Lifecycle
Every MCP session begins with a capability negotiation handshake. When a client connects to a server, both sides exchange their supported capabilities, including which protocol version they implement, which primitives they support, and which optional features they enable. This negotiation ensures that the client and server agree on what operations are available before any tool calls or resource reads occur.
The server declares which primitives it exposes (tools, resources, prompts) and any additional capabilities like list change notifications, logging, or experimental features. The client declares its capabilities as well, including whether it supports sampling (which allows the server to request LLM completions from the host) and roots (which tells the server about the current working context). This bidirectional negotiation means both sides understand each other's capabilities before the session begins.
After initialization, the client can discover available tools, resources, and prompts by sending list requests. The server responds with detailed descriptions of each capability, including names, descriptions, parameter schemas for tools, URI templates for resources, and argument definitions for prompts. The model uses these descriptions to understand what operations are available and how to invoke them correctly. Good descriptions are critical because they directly influence how well the model uses each capability.
Servers can send change notifications to inform clients when their available capabilities change during a session. A new file appearing in a monitored directory might add a new resource, or a configuration change might enable additional tools. These notifications let the client refresh its capability list without restarting the session, supporting dynamic environments where the set of available operations evolves over time.
The MCP Ecosystem in 2026
The MCP ecosystem has grown from Anthropic's initial release to a broad, vendor-neutral standard supported by every major AI platform. This growth happened faster than most observers expected, driven by genuine developer demand for integration standardization and by strategic decisions from competing AI providers.
Anthropic integrated MCP natively into Claude Desktop, Claude Code, and the Claude API from the start. Claude was the first AI assistant where users could connect MCP servers and immediately use external tools within conversations. This early integration gave MCP real-world validation and built a community of server developers who published their implementations for others to use.
OpenAI adopted MCP support in early 2025, integrating it into ChatGPT and the OpenAI platform. In a notable move, OpenAI subsequently deprecated its proprietary Assistants API in favor of MCP, with a mid-2026 sunset date. This decision signaled that even Anthropic's primary competitor viewed MCP as the right approach to tool integration, lending the protocol significant credibility as a vendor-neutral standard rather than an Anthropic-specific technology.
Google added MCP support to Gemini and Google Cloud's AI platform, and Microsoft integrated it into Copilot and VS Code. AWS, through its Bedrock and CodeWhisperer products, also adopted MCP. By mid-2026, a developer building an MCP server could be confident that it would work with Claude, ChatGPT, Gemini, Copilot, and essentially every major AI-powered application.
In December 2025, Anthropic donated MCP to the Linux Foundation's Agentic AI Foundation (AAIF), a new governance body co-founded by Anthropic, OpenAI, Block, Google, and Microsoft. The AAIF now oversees both MCP and Google's A2A protocol, providing vendor-neutral governance and ensuring that no single company controls the protocol's evolution. This governance transition was important for enterprise adoption, where companies need assurance that a standard will remain open and stable regardless of any single vendor's strategic decisions.
The server ecosystem has exploded in scale. Over 10,000 community-built MCP servers cover virtually every common integration need: databases (PostgreSQL, MySQL, SQLite, MongoDB), version control (GitHub, GitLab), communication tools (Slack, Discord, email), cloud infrastructure (AWS, GCP, Azure), search engines (Brave, Tavily), file systems, web browsers, and hundreds of SaaS APIs. Popular server registries and discovery services help developers find existing servers rather than building from scratch.
Security Model
MCP's security model is built on the principle of least privilege enforced at multiple layers. Each MCP server runs as an isolated process with its own permissions, and the host application controls which servers the model can access and what operations are allowed. This layered approach means that compromising one server does not grant access to other servers or to the host system.
Authentication for remote MCP servers uses OAuth 2.1, standardized in the June 2025 specification revision. This brings MCP in line with established web security practices, supporting token-based authentication, refresh flows, and scoped permissions. Local servers using stdio transport rely on the operating system's process isolation and file system permissions for security, since all communication stays within the local machine.
Permission scoping lets server operators define exactly what operations are available. A filesystem MCP server might be configured to allow reading files in a specific directory but deny write access or access to directories outside the approved scope. A database server might allow SELECT queries but deny INSERT, UPDATE, or DELETE operations. These permissions are enforced at the server level, independent of what the model requests, ensuring that even a manipulated model cannot exceed the server's configured permissions.
Despite these architectural safeguards, security researchers have identified real vulnerabilities in MCP deployments. Studies found that a significant percentage of community-built MCP servers contained command injection vulnerabilities, and poorly configured servers have exposed sensitive environments. These findings underscore that MCP provides a security framework, but the actual security of a deployment depends on how carefully each server is implemented and configured. The protocol can enforce boundaries, but it cannot prevent a server developer from writing insecure code within those boundaries.
MCP vs Alternatives
MCP exists alongside several other approaches to AI tool integration, and understanding how they relate helps clarify when MCP is the right choice and when other approaches might be more appropriate.
Function calling is the mechanism that LLMs use to invoke tools. It is not a competitor to MCP but rather a complementary layer. Function calling is phase one, where the model generates a structured call specifying which function to invoke with which arguments. MCP is phase two, where the call is routed to the appropriate server, executed, and the result returned. Most MCP implementations use the model's native function calling capability to generate tool invocations, with MCP handling the discovery, routing, and execution infrastructure. The two technologies work together rather than competing.
REST APIs are the standard for web service integration and remain the right choice for many scenarios. REST is stateless, widely understood, massively scalable, and backed by decades of tooling and infrastructure. MCP adds value specifically for AI agent contexts where dynamic tool discovery, session state, and multi-step interactions matter. A scheduled batch job that calls a fixed set of endpoints does not benefit from MCP. An AI agent that needs to discover available tools, invoke them based on conversation context, and chain multiple calls together benefits significantly.
Google's A2A protocol (Agent-to-Agent) addresses a different problem entirely. While MCP standardizes how an agent connects to tools (vertical integration), A2A standardizes how agents communicate with and delegate tasks to other agents (horizontal coordination). In production multi-agent systems, the two protocols are complementary: an orchestrating agent uses A2A to delegate a task to a specialist agent, and that specialist agent uses MCP to access the tools it needs to complete the task. Both protocols are now governed by the same Linux Foundation body, reflecting the industry consensus that they are complementary layers rather than competitors.
Getting Started with MCP
The fastest way to experience MCP is through Claude Desktop or Claude Code, both of which support MCP natively. Installing a pre-built MCP server typically involves adding a configuration entry that tells the host where to find the server executable and what arguments to pass. Within minutes, you can have Claude accessing your local filesystem, querying a database, or searching the web through MCP servers.
For developers building MCP servers, the official TypeScript and Python SDKs provide the protocol handling, transport management, and utility functions needed to expose tools, resources, and prompts. A minimal MCP server can be built in under 100 lines of code. The SDKs handle the JSON-RPC message parsing, capability negotiation, session lifecycle, and error formatting, letting the developer focus on implementing the actual tool logic.
Building an MCP client is a larger undertaking, typically relevant for developers building AI applications rather than tool integrations. Client implementations need to manage multiple server connections, handle capability discovery, route tool calls to the correct server, and present available capabilities to the model. The official SDKs include client implementations that handle these concerns, and open-source clients in both TypeScript and Python provide reference implementations for custom host applications.
The ecosystem offers pre-built servers for most common needs. Before building a custom server, check community registries for existing implementations. The official MCP servers repository, npm and PyPI package listings, and community directories catalog thousands of available servers. Using a well-maintained existing server is almost always preferable to building from scratch, unless your integration has unique requirements that existing servers cannot satisfy.