The Protocol Layer

For two years, every LLM application reinvented tool integration from scratch. MCP is the attempt to make that stop.

The Integration Tax

In 2023, OpenAI shipped function calling. Anthropic followed with its own tool-use format. LangChain built an abstraction layer on top of both. Then came LlamaIndex, Semantic Kernel, and a dozen more frameworks, each with their own conventions for how a model should describe, invoke, and receive results from external tools.²⁶

Every tool author who wanted broad adoption faced the same arithmetic. If you had N tools and M frameworks, you needed N × M integration adapters. A weather API needed one wrapper for OpenAI's function calling format, another for Anthropic's tool-use blocks, another for LangChain's tool interface, and so on. Each wrapper did roughly the same thing: declare a name, describe the parameters, call the underlying function, return the result. But the plumbing was different every time.²⁷

This is the integration tax. It is a tedious problem that scales multiplicatively, exactly the kind that protocols are designed to eliminate.²⁸

What MCP Actually Is

Model Context Protocol (MCP) is a protocol, not a library.¹ That distinction matters. A library gives you functions to call. A protocol gives you a contract that both sides agree to follow. MCP defines a JSON-RPC 2.0 interface⁶ between an MCP host (the LLM application) and MCP servers (tool providers).²⁹

The protocol was created by Anthropic engineers David Soria Parra and Justin Spahr-Summers, and publicly launched on November 25, 2024. It was open-source from day one, with SDKs in Python and TypeScript shipping alongside the spec.²⁵ The design re-uses the message-flow ideas of the Language Server Protocol (LSP), the same standard that powers autocomplete in every modern code editor, and is transported over JSON-RPC 2.0.³⁰

The host discovers what tools a server offers by sending a tools/list request. It calls them with structured arguments via tools/call. It receives structured results back. The entire exchange follows a schema that both sides understand before they ever communicate.

The key insight is separation of concerns. The tool author does not need to know which LLM is calling, which framework wraps it, or how the application manages conversation state. The application does not need to know how the tool is implemented, what language it runs in, or where it is deployed. The protocol is the boundary. Everything on each side of that boundary is a private implementation detail.

Consider what this looked like before MCP. A tool author building a GitHub integration would write something like the following, with different adapter code for each framework:

# Before MCP: one adapter per framework per tool

# OpenAI format
openai_tools = [{
    "type": "function",
    "function": {"name": "create_issue", "parameters": {...}}
}]

# Anthropic format
anthropic_tools = [{
    "name": "create_issue", "input_schema": {...}
}]

# LangChain format
class CreateIssueTool(BaseTool):
    name = "create_issue"
    # ... yet another wrapper for the same logic

Three wrappers for one tool, multiplied by every tool and every framework in your stack: that is the N × M problem in practice.

The Architecture

MCP defines three participants. The MCP Host is the AI application itself: Claude Desktop, an IDE plugin like VS Code with Copilot, or your custom application. The MCP Client is a component inside the host that manages the connection to a specific server. The MCP Server is a program that exposes tools, resources, and prompts over the protocol.

The host creates one client per server. Each client maintains a dedicated connection to its server. When VS Code connects to both a filesystem server and a Sentry server, two separate clients handle those two connections independently.

The flow follows a predictable sequence. The client sends an initialize request to negotiate capabilities. The server responds with what it supports. The client discovers available tools via tools/list. When the model decides to use a tool, the client sends tools/call with the appropriate arguments. The server executes the tool and returns the result. The client hands it back to the host, which feeds it into the conversation.

If you completed the function calling work in Week 3, this should look familiar. The tool-use loop is the same: the model decides to call a tool, the application executes it, the result goes back to the model. MCP does not change that loop. It standardizes the interface between the application and the tool provider, so that the "execute it" step works the same way regardless of what is on either end.³¹

Capabilities

MCP servers expose three types of capabilities, each serving a distinct role in how an LLM interacts with external systems.

Tools are executable functions. They are the MCP equivalent of function calling from Week 3, but wrapped in the protocol's standardized format. A tool has a name, a description, and a JSON Schema defining its input parameters. When the model calls a tool, the server executes it and returns structured content.³²

Resources are data the model can read. Think of them as retrieval-augmented context that the server makes available: file contents, database records, API responses, configuration data. Resources have URIs and can be listed, read, and in some cases subscribed to for updates.³³

Prompts are reusable templates that the server provides. They structure interactions with the model for specific tasks, like a code review template or a data analysis workflow. Prompts can include arguments that customize the template for a particular use case.

A concrete example makes this tangible. Consider a GitHub MCP server. Its tools might include create_issue, list_pull_requests, and merge_pr. Its resources might expose file contents at a given path, pull request diffs, and repository metadata. Its prompts might include a code review template that takes a PR number as input and structures the model's review around specific criteria.

The model discovers all three capability types through list methods: tools/list, resources/list, and prompts/list. Discovery is dynamic. If the server's capabilities change, it can send a notification, and the client refreshes its understanding of what is available.

Building an MCP Server

A minimal MCP server in Python demonstrates how little ceremony the protocol requires. The official Python SDK provides decorators that handle the JSON-RPC plumbing, leaving the developer to focus on the tool's actual logic.

↗ docsfrom mcp.server.fastmcp import FastMCP

# Create server
mcp = FastMCP("weather")

@mcp.tool()
async def get_forecast(
    city: str,
    days: int = 3
) -> str:
    """Get weather forecast for a city.

    Args:
        city: City name (e.g. "San Francisco")
        days: Number of days to forecast (1-7)
    """
    # The SDK infers the input schema from
    # the function signature and docstring
    forecast = await fetch_weather_api(city, days)
    return format_forecast(forecast)

@mcp.resource("weather://cities")
async def list_supported_cities() -> str:
    """List all cities with weather data."""
    return "\n".join(SUPPORTED_CITIES)

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

That is a complete MCP server. The @mcp.tool() decorator registers the function as a callable tool. The SDK reads the type hints and docstring to generate the JSON Schema that clients will use for discovery. When a client calls tools/call with {"name": "get_forecast", "arguments": {"city": "Boston", "days": 5}}, the SDK routes the request to this function, validates the arguments, and returns the result.³⁴

Compare this to the Week 3 function calling definitions. The shape is the same: a name, a description, typed parameters, and execution logic. The difference is that this server can be connected to any MCP-compatible host without any adapter code. Claude Desktop, VS Code, a custom agent, anything that speaks MCP can discover and use this tool.⁴

Transport Layer

MCP separates what gets communicated (the JSON-RPC messages) from how it gets communicated (the transport). The protocol currently supports two transport mechanisms, each suited to different deployment scenarios.

stdio is the simpler option. The host launches the MCP server as a subprocess and communicates via standard input and output. Messages are newline-delimited JSON-RPC objects. No networking, no ports, no HTTP. The server starts when the host starts and stops when the host stops. This is how Claude Desktop runs local MCP servers, and it is the right choice for development, desktop applications, and scenarios where the server and host share a machine.

Streamable HTTP is for production and shared deployments. The server runs as an independent HTTP service that accepts POST requests for client-to-server messages and optionally uses Server-Sent Events (SSE) for streaming responses. Multiple clients can connect to the same server. The server persists independently of any single client. This is the right choice when you want a team, an organization, or the public to share a single MCP server deployment.

A host's configuration file shows how this works in practice:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/home/user/projects"]
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "ghp_xxxxxxxxxxxx"
      }
    },
    "sentry": {
      "url": "https://mcp.sentry.dev/sse"
    }
  }
}

The first two servers use stdio: the host will launch them as subprocesses. The third uses a remote URL, connecting over Streamable HTTP to a server Sentry operates. From the model's perspective, all three work identically. It discovers tools from each, calls them with the same protocol, and receives results in the same format. The transport is invisible.³³⁵³⁶

From N × M to N + M

The arithmetic of the integration tax changes with a shared protocol. Without MCP, adding a new tool means writing an adapter for every framework. Adding a new framework means writing an adapter for every tool. The cost is multiplicative. With MCP, adding a new tool means writing one MCP server. Adding a new host means implementing one MCP client. The cost is additive.

This is not a new pattern. USB replaced the era of dedicated ports for every peripheral. HTTP replaced proprietary networking protocols for document transfer. SQL replaced per-database query languages. In each case, the protocol created a shared interface that turned a multiplicative integration problem into an additive one. The ecosystem compounds: every new device that speaks USB is immediately compatible with every computer that has a USB port.³⁷

MCP aims for the same dynamic. A GitHub MCP server written once becomes available to Claude Desktop, VS Code, Cursor, Windsurf, and any future application that implements the MCP client protocol. A new IDE that adds MCP client support immediately gains access to every existing MCP server. The value of the ecosystem grows with each participant, and no participant needs to coordinate directly with any other.²⁴³⁸

To see the contrast clearly, consider the same tool exposed as a raw function definition (the Week 3 pattern) versus an MCP server:

# Week 3 approach: tool definition coupled to one framework
tools = [{
    "name": "get_forecast",
    "description": "Get weather forecast for a city",
    "input_schema": {
        "type": "object",
        "properties": {
            "city": {"type": "string"},
            "days": {"type": "integer", "default": 3}
        },
        "required": ["city"]
    }
}]

# You still need to manually:
# 1. Parse the model's tool call from the API response
# 2. Route to the correct function
# 3. Handle errors and format results
# 4. Feed the result back into the conversation
# 5. Rewrite all of this for each new framework

# MCP approach: write once, connect anywhere
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("weather")

@mcp.tool()
async def get_forecast(city: str, days: int = 3) -> str:
    """Get weather forecast for a city."""
    forecast = await fetch_weather_api(city, days)
    return format_forecast(forecast)

# Discovery, routing, error handling, and result
# formatting are handled by the protocol.
# Any MCP host can connect without adapter code.

The tool logic is identical in both cases. The difference is everything around it. The MCP version delegates discovery, routing, serialization, and error handling to the protocol. The framework-specific version requires you to handle all of that yourself, differently, for each integration target.

The Ecosystem Explodes

Anthropic shipped MCP with a set of reference servers that demonstrated the protocol's range. Filesystem for file operations. GitHub for repository management. PostgreSQL for database queries. Brave Search for web lookups. Puppeteer for browser automation. Google Drive and Slack for enterprise integration. These were proof-of-concept implementations, but they worked, and they established the pattern that every subsequent server would follow.

The adoption curve was steep. Server downloads grew from roughly 100,000 at launch in November 2024 to over 8 million by April 2025. By the one-year mark, more than 10,000 MCP servers existed in the wild, with 97 million monthly SDK downloads.⁹³⁹

The enterprise signings came fast. In March 2025, OpenAI CEO Sam Altman announced full MCP support, integrating it into the ChatGPT desktop app.¹² Google DeepMind's Demis Hassabis confirmed MCP support for Gemini models and SDK. Microsoft joined the MCP Steering Committee at Build 2025, rolling out support across Copilot Studio, GitHub, Dynamics 365, Azure, and even Windows 11 "App Actions."¹⁴

First-party MCP servers arrived from companies that had never collaborated on a shared protocol before. Stripe shipped payment processing tools.¹⁶ Atlassian connected Jira and Confluence. Sentry exposed error tracking. Cloudflare opened up Workers, KV, R2, and D1.¹⁵ The pattern repeated across Notion, Linear, Twilio, PayPal, Asana, Intercom, Plaid, and Zapier.⁴⁰

The cloud providers built their own layers on top. AWS launched an API MCP Server in July 2025 that made any AWS API callable via natural language, alongside servers for Amazon MSK (Kafka), real-time pricing, and Bedrock agent orchestration.¹³ Microsoft shipped Azure Functions with MCP transport support, a GitHub server, and Dynamics 365 integration. Google contributed open-source servers for Google Maps and Google Cloud databases.

By January 2026, MCP had first-class client support in Claude, ChatGPT, Cursor, Gemini, Microsoft Copilot, Visual Studio Code, Windsurf, and Zed. A tool author could write one MCP server and reach all of them.²⁵

The Specification Evolves

MCP did not stay frozen at its November 2024 release. The specification moved through four versions in its first year, each responding to problems that emerged as real-world adoption exposed limitations.⁷⁸

The March 2025 release was the most disruptive. It replaced the original HTTP+SSE transport with Streamable HTTP, a fundamental architectural change. The original design required two endpoints: one for establishing a persistent SSE connection (/sse), another for sending requests (/sse/messages). The server had to maintain a long-lived, highly available connection per client. This broke in practice: load balancers terminated idle connections, proxies interfered with SSE, and serverless platforms could not keep connections alive.

Streamable HTTP collapsed everything into a single endpoint (/mcp) that accepts POST requests. The server can respond immediately for simple requests or upgrade to SSE for streaming, all within the same HTTP response. Stateless servers became possible. Standard HTTP middleware, proxies, and hosting platforms worked without modification. Cloudflare's workers, AWS Lambda, and Vercel's edge functions could all serve MCP without special infrastructure.

The November 2025 anniversary release added capabilities that pushed MCP from a tool-calling protocol toward an agentic infrastructure layer. Tasks introduced async execution: any request could return a task handle that clients poll for completion, enabling long-running operations without blocking the conversation. Sampling with Tools let servers initiate their own LLM calls with tool definitions, enabling server-side agent loops. URL Mode Elicitation allowed servers to redirect users to a browser for sensitive operations like OAuth flows and payment authorization, keeping credentials out of the MCP client entirely.²³⁴¹

The Security Surface

Protocols that connect AI models to external tools create attack surfaces that did not exist before. MCP is no exception. Within months of widespread adoption, security researchers began documenting a taxonomy of vulnerabilities specific to the protocol's architecture.²¹⁴²

Tool Poisoning was the first novel attack class. Invariant Labs demonstrated in April 2025 that malicious instructions could be embedded in MCP tool descriptions using Unicode tricks, ANSI escape sequences, or zero-width characters. The LLM reads and obeys these hidden instructions. Users see only the benign tool name and visible description. In a proof-of-concept, a poisoned MCP server silently exfiltrated a user's entire WhatsApp history by piggy-backing on a legitimate whatsapp-mcp server running in the same agent.¹⁷⁴³

Tool Shadowing is a related attack where a malicious server registers tools with names that mimic trusted tools. The agent believes it is calling the legitimate version. The attacker's substitute logs data, modifies parameters, or executes unauthorized operations alongside the expected behavior. The user sees correct results; the attacker sees everything.¹⁸

Rug Pulls exploit the fact that MCP tool definitions are dynamic. A server can change its tool descriptions after installation. You approve a safe-looking tool on day one. By day seven, it has quietly rerouted your API keys to an external endpoint. Dynamic capability negotiation, one of MCP's design strengths, becomes a liability without integrity verification.¹⁹

The supply chain is vulnerable too. A study by AuthZed found that 34% of attacks against MCP servers used typosquatting in package registries like npm and pip, while 28% targeted supply chain compromise of popular servers. These risks compound when the model has access to a large context window filled with tool results from multiple sources. The typical installation guide tells users to run npx directly from a GitHub URL without integrity verification. 73% of surveyed guides followed this pattern.²⁰

Real incidents accumulated. Invariant Labs disclosed a prompt-injection attack against the official GitHub MCP server in which a malicious public issue could hijack an agent into exfiltrating data from private repositories. A Supabase/Cursor incident in mid-2025 saw a privileged agent processing support tickets that contained embedded SQL, exfiltrating integration tokens. Anthropic's own MCP Inspector developer tool was found vulnerable to unauthenticated remote code execution. CVE-2025-6514 in the mcp-remote npm OAuth proxy affected 437,000+ downloads.⁴⁴

In January 2026, an arXiv paper titled "Breaking the Protocol" presented the first rigorous security analysis of MCP's architecture. Testing 847 attack scenarios across five server implementations, the researchers found that MCP's architectural choices amplified attack success rates by 23 to 41 percent compared to equivalent non-MCP integrations. The fundamental vulnerabilities they identified: absence of capability attestation, bidirectional sampling without origin authentication, and implicit trust propagation in multi-server configurations.²²

The MCP specification has responded incrementally. The June 2025 update classified MCP servers as OAuth 2.1 Resource Servers. The November 2025 release added URL Mode Elicitation to keep credentials out of clients, Client ID Metadata Documents for registration, and default scopes in authorization. These are real improvements. They are not sufficient. The core problem is architectural: MCP trusts tool descriptions that can be manipulated, enables dynamic capability changes that can be exploited, and connects models to execution environments with broad permissions. The protocol provides the plumbing. The guardrails are still the developer's responsibility.

The Governance Question

For its first year, MCP was Anthropic's project. Anthropic designed it, maintained it, and controlled its direction. This was efficient for moving fast, but it created a structural tension: a protocol that aspired to be a universal standard was governed by a single vendor.

On December 9, 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF), a directed fund under the Linux Foundation.¹⁰¹¹ The move put MCP on the same governance path as Kubernetes, PyTorch, and GraphQL: vendor-neutral stewardship by an independent foundation.

The founding was a joint effort. Anthropic contributed MCP. Block contributed goose, an open-source agentic AI framework that had become a reference MCP implementation. OpenAI contributed AGENTS.md, a standard for project-specific AI agent guidance released in August 2025. Three competing companies placing their agentic infrastructure projects under shared governance.⁴⁵

The governance structure separates strategic decisions from technical direction. The AAIF Governing Board handles budget, member recruitment, and project approval. Individual projects like MCP retain full autonomy over their technical roadmap and day-to-day operations. The Linux Foundation provides neutral infrastructure but does not dictate what the protocol becomes.

Whether this governance model can sustain the pace of the protocol's first year remains to be seen. MCP shipped four spec versions in twelve months, driven by a small core team with short decision loops. Foundation governance introduces process, consensus requirements, and committee dynamics. The tension between velocity and neutrality is inherent. It is the same tension that every successful open standard eventually navigates.⁴⁶

What MCP Does Not Solve

MCP standardizes the interface. It does not standardize the quality. A poorly designed tool schema is still a poorly designed tool schema, whether it is served over MCP or hardcoded into a LangChain agent. The schema design principles from Week 3 still apply: clear names, precise descriptions, constrained parameter types, and sensible defaults.⁴⁷

Security is not automatic either. MCP servers must validate inputs, implement access controls, and rate-limit invocations. The MCP specification explicitly states that applications should provide confirmation prompts before executing tool calls. The security concerns from Week 3, prompt injection through tool results, excessive permissions, unvalidated inputs, all carry over. MCP provides the transport, not the guardrails. The attack surface analysis above makes this concrete.

Evaluation does not become easier. Whether your tool is called through MCP or through a direct function call, you still need to verify that the model selects the right tool, passes correct arguments, and uses the results appropriately. The evaluation frameworks from Week 7 apply unchanged. MCP is orthogonal to quality assurance.⁴⁸⁴⁹

Think of MCP as plumbing. Good plumbing is essential. You cannot build a functional building without it. But good plumbing does not guarantee a well-designed kitchen. It simply ensures that water flows reliably between the source and the fixtures. What you do with that water is still up to you.⁵⁰