Model Context Protocol (MCP)

What is the Model Context Protocol (MCP)?

The Model Context Protocol (MCP) is an open standard developed to standardize how AI applications, agents, and large language models interface with external data sources, tools, and environments. Historically, every AI assistant or agent framework built custom integrations to fetch external data or invoke specific APIs. This left a fragmented landscape of connectors: one written for a given framework generally did not work in another without substantial rewrites.

MCP solves this by defining a universal, bidirectional protocol built on JSON-RPC 2.0. Local servers communicate over stdio. Remote servers use Streamable HTTP, the transport the specification adopted in its March 2025 revision to replace the earlier HTTP+SSE design. Because the interface is standardized, developers write an MCP server once to expose their application's data or capabilities, and any MCP-compliant client, such as Claude Desktop, an IDE, or a custom AI agent, can connect to and use those capabilities.

MCP is often described as the USB-C connector for AI models: one standard interface instead of a separate integration for every data source. It lets a model plug into enterprise databases, local file systems, web APIs, and similar systems, giving it access to real-time, relevant, and private data.

Anthropic released MCP as an open standard in November 2024, and it became the rare integration standard that every major vendor actually adopted: OpenAI added MCP support across its products in March 2025, followed by Google DeepMind and Microsoft, which built MCP into Windows. An official MCP server registry entered preview in September 2025 to make servers discoverable, and by 2026 the ecosystem counts thousands of community and vendor-maintained servers.

Specification Timeline and the Current Revision (2026-07-28)

The protocol is versioned by date-stamped revisions, and knowing which revision a server or client targets matters because the transport and authorization stories have changed substantially:

• 2024-11-05: Initial release. Local stdio transport plus an HTTP+SSE remote transport.
• 2025-03-26: Replaced HTTP+SSE with Streamable HTTP and adopted OAuth 2.1-based authorization for remote servers.
• 2025-06-18: Added elicitation (servers requesting user input), structured tool output, and reclassified servers as OAuth resource servers with mandatory resource indicators.
• 2025-11-25: Interim revision, the baseline against which the current spec's changelog is written.
• 2026-07-28: The current stable revision, and the largest change since launch. The protocol core became stateless: the initialize handshake and protocol-level sessions (the Mcp-Session-Id header) were removed, and every request now carries its protocol version and client capabilities in _meta. This makes remote servers horizontally scalable like ordinary web services. The revision also introduced an Extensions framework, with Tasks (long-running work) and MCP Apps (server-rendered UIs) as the first official extensions, hardened authorization, and adopted a formal deprecation policy with a minimum twelve-month window. The full 2026-07-28 changelog lists every change.

For implementers the practical takeaway is that statelessness is the direction of travel: new remote servers should not depend on per-connection state, and clients should expect capability discovery through per-request metadata rather than a handshake.

Core Architecture: Hosts, Clients, and Servers

The architecture of the Model Context Protocol is structured around three primary components, creating a clear separation of concerns for scalability, security, and extensibility.

1. MCP Hosts: The Host is the top-level application the user interacts with. Examples include an IDE, an AI chat application, or a multi-agent orchestration framework. The Host manages the lifecycle of the AI models and the overall user interface.
2. MCP Clients: Embedded within the Host, the Client maintains 1:1 connections with one or more MCP Servers. The Client handles protocol negotiation, routes requests to the appropriate Servers, and manages state. When the AI model needs to take an action or fetch data, the Host instructs the Client to communicate with the relevant Server.
3. MCP Servers: Servers are lightweight, purpose-built programs that expose specific capabilities to the Client. An MCP Server could wrap a PostgreSQL database, provide read/write access to a GitHub repository, or interact with an enterprise SaaS application like Slack or Jira. Servers are agnostic to the AI model or Host application; they respond to standard JSON-RPC requests conforming to the MCP specification.

This decoupled architecture means Server developers do not need to worry about prompt engineering or model orchestration, and Host developers do not need to maintain hundreds of fragile, custom integrations.

Key Primitives: Resources, Prompts, and Tools

The Model Context Protocol exposes capabilities through three foundational primitives. They give AI models the flexibility to consume passive data, guide user interactions, and execute active commands.

Resources

Resources represent read-only data that an MCP Server can provide to the Client. They are accessed via unique URIs and can be thought of as a virtual file system for the AI. A Resource can be static (a configuration file), dynamic (a live database query result), or binary (an image). When an AI model needs context, it can request the Client to read a specific Resource URI.

Prompts

Prompts are pre-defined templates or starting points provided by the Server. They let a Server suggest specific workflows or structured queries to the Host application. For instance, a GitHub MCP Server might expose a Prompt called review-pr, which takes a pull request number as an argument and generates a standardized instruction set for the AI model to perform a code review. Prompts often stitch together multiple Resources to form a complete context for the AI.

Tools

Tools are actionable, executable functions exposed by the Server, and unlike Resources, they have side effects. A Server might expose Tools to run a SQL query, commit code, send an email, or trigger a deployment pipeline. This is a specific application of function calling: Tools are defined using JSON Schema so the AI model knows exactly what arguments are required and what types they must be, following the same structured output principles used elsewhere in tool calling. The Client passes the AI's intended tool call to the Server, which executes the action and returns the result.

MCP vs. Traditional Custom Tool Calling APIs

Before MCP, most AI frameworks relied on proprietary tool calling or plugin systems. The table below compares the Model Context Protocol with traditional custom approaches.

Example MCP Server Implementation & JSON-RPC Protocol Flow

Official SDKs make an MCP Server simple to write. Below is a Python example using the FastMCP interface from the official Python SDK, exposing a tool to fetch weather data, followed by the JSON-RPC message flow.

Python Server Snippet

from mcp.server.fastmcp import FastMCP

mcp = FastMCP('weather')

@mcp.tool()
def get_weather(city: str) -> str:
    """Get current weather for a location."""
    return f'The weather in {city} is sunny and 75°F.'

if __name__ == '__main__':
    mcp.run()

JSON-RPC Protocol Flow

When the Client requests the available tools, the JSON-RPC flow over standard input/output looks like this:

Client Request (stdin):

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list"
}

Server Response (stdout):

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tools": [
      {
        "name": "get_weather",
        "description": "Get current weather for a location.",
        "inputSchema": {
          "type": "object",
          "properties": {
            "city": { "type": "string" }
          },
          "required": ["city"]
        }
      }
    ]
  }
}

Production Considerations & Security Boundaries

Deploying MCP Servers in production requires treating several risks as non-negotiable, not as advice to weigh against convenience. Because MCP lets AI models interact with real systems and data, the following are requirements, not optional hardening.

• Servers are untrusted third-party code: Installing an MCP Server means running someone else's code with whatever permissions you grant it, the same supply-chain exposure as any dependency. A malicious or compromised server can read every argument the model sends it, including data pulled in from other tools. Vet and pin server versions the way you would any dependency with the same access level, and do not connect a server to credentials or data it hasn't been reviewed for.
• Tool descriptions are a prompt-injection vector: A server's tool names, descriptions, and schemas are text that the Host injects directly into the model's context. A malicious server can write a description that instructs the model to exfiltrate data, ignore prior instructions, or call other tools in unintended ways, and the model has no reliable way to distinguish that from legitimate tool documentation. Treat tool descriptions from untrusted or unvetted servers as adversarial input, not inert metadata, and see prompt injection defense for mitigations.
• Transport authentication is not server trustworthiness: Mutual TLS or OAuth 2.1 bearer tokens (per the current spec) verify that you're talking to the server you think you're talking to. They say nothing about whether that server's code is safe to run or its maintainer trustworthy. Authenticating a connection to a malicious server just gets you a verified connection to something malicious.
• Principle of Least Privilege: An MCP Server must be granted only the minimum permissions its function requires. A Server that only needs to read a database should hold a read-only credential, not one that also has write access.
• Isolation and human approval are required, not optional: Sandbox server execution so a compromised or buggy server cannot reach beyond its intended scope, and require human-in-the-loop approval before any Tool that performs a destructive or sensitive action (executing code, sending external communications, modifying infrastructure) actually runs. The AI can propose the call; a human, not the model, authorizes it.
• Rate Limiting and Timeouts: To prevent runaway AI loops or denial-of-service, MCP Servers should enforce strict timeouts and rate limits on resource fetching and tool execution.
• Centralized Routing: Organizations connecting many MCP servers across teams often place an AI gateway in front of them to centralize authentication, logging, and policy enforcement rather than configuring each client separately.

Frequently Asked Questions

Does MCP only work with specific LLMs like Claude? No. Anthropic created and open-sourced the protocol alongside Claude Desktop, but MCP is model-agnostic. Any AI application or agent framework can implement an MCP Client to interact with standard MCP Servers.

How do I handle authentication with an MCP Server? For local stdio servers, authentication is usually handled via environment variables passed when spawning the server process. For remote servers, the current specification defines an OAuth 2.1-based authorization flow: the client obtains a token through a standard OAuth exchange and passes it via HTTP headers (such as Authorization) on each request.

Can an MCP Server initiate requests to the Client? The protocol is bidirectional. Clients primarily drive the interaction by requesting resources or calling tools, but Servers can send notifications to the Client. For example, a Server can notify the Client that a previously fetched Resource has been updated, prompting the AI to refresh its context.

Does MCP make my agent's context window explode? It can. Every connected server's tool definitions are injected into the model's context, and a handful of feature-rich servers can add tens of thousands of tokens before the conversation starts. Mitigations include connecting only the servers a task needs, using hosts that support dynamic tool discovery or code-execution wrappers that expose tools on demand, and caching the tool block with prompt caching so it bills at cache-read rates.

Do existing MCP servers break under the 2026-07-28 stateless revision? Not immediately. The spec's deprecation policy guarantees a minimum twelve-month window between deprecation and removal, and clients negotiate the protocol revision per request. But servers that relied on protocol-level sessions for per-connection state need redesigning: state now belongs in the application layer (for example, keyed by an identifier a tool returns) rather than in the transport.

Is it possible to chain MCP Servers together? An MCP Server can act as a Client to other Servers, but standard practice is for a single Host application to manage connections to multiple independent Servers and combine their capabilities in the Host's orchestration layer.