The Model Context Protocol

Most engineers hear "protocol" and think of something academic — an RFC gathering dust in a standards body while the real world ships whatever compiles. So when Anthropic released the Model Context Protocol, the default reaction was polite indifference. Another abstraction layer. Another interface nobody asked for. The industry already had function calling, tool-use APIs, and a dozen wrapper libraries. Why would anyone adopt a protocol when duct tape was working fine?

The duct tape was not working fine. It was holding, the way duct tape always holds — until the third API changes its authentication scheme, the fourth tool returns a shape your parser doesn't expect, and the fifth integration needs to run in a different environment from the first four. Every AI integration I've seen in production shares the same structural problem: the connection between the model and the tool was written as a one-off, and it aged like one.

MCP exists because the AI industry's approach to integrations was the software equivalent of building a new electrical plug for every appliance. Every model talked to every tool differently. Nothing was portable. Nothing was discoverable. And every time you moved to a new model or a new host application, you rewired from scratch.

The Fragmentation Problem

Before MCP, the landscape looked roughly like this: you had an LLM that needed to call a function, read a file, query a database, or hit an API. Each of those capabilities required a custom integration. The model's tool-calling interface was one format. The API's authentication was another. The response shapes were whatever the developer felt like returning that day. Error handling was "try/except and hope."

This created three compounding failures:

1. Nothing was reusable. A tool built for one model host couldn't be ported to another without rewriting the transport layer, the schema, and often the business logic.
2. Debugging was archaeological. When something broke — and it always broke — you had to trace through custom JSON formats, bespoke error codes, and ad-hoc retry logic that varied per integration.
3. The ecosystem couldn't grow. If every tool requires a custom connector for every host, the number of integrations you need scales as tools times hosts. That's quadratic complexity, and it kills adoption.

This is not a theoretical concern. I've seen teams maintaining fifteen separate API wrapper scripts, each with its own authentication pattern, its own error format, and its own maintainer who left the company six months ago. MCP doesn't make integrations trivial. It makes them standard, which is far more valuable.

The Architecture: Clients, Servers, and the Host

MCP is a client-server protocol, but the terminology is precise and worth getting right early.

The host is the application process that runs the AI model — Claude Desktop, an IDE plugin, a custom agent runtime. Inside the host, one or more MCP clients manage connections to external capability providers. Each capability provider is an MCP server: a lightweight process that exposes tools, resources, or both through the protocol.

The message flow is always the same:

1. The client establishes a connection to the server and negotiates capabilities. The server declares what it can do — which tools are available, which resources are exposed, what schemas they expect.
2. The client sends structured requests. Not raw API calls, not free-form text — structured, typed JSON-RPC messages.
3. The server validates the request, executes the operation, and returns a structured response.
4. The client aggregates results from multiple servers into a unified context for the model.

The critical insight is what the model doesn't do. The model never talks to tools directly. It never authenticates with an API. It never parses a raw HTTP response. Every external interaction is mediated through MCP, which means the model can focus on reasoning and decision-making while the protocol handles access, execution, and safety.

┌─────────────────────────────────────────┐
│              Host Application           │
│  ┌───────────┐  ┌───────────┐           │
│  │ MCP Client│  │ MCP Client│           │
│  └─────┬─────┘  └─────┬─────┘           │
│        │               │                │
└────────┼───────────────┼────────────────┘
         │               │
    MCP Protocol    MCP Protocol
         │               │
   ┌─────┴─────┐   ┌─────┴─────┐
   │ MCP Server │   │ MCP Server │
   │  (Local)   │   │  (Remote)  │
   │ Files, DB  │   │ APIs, SaaS │
   └────────────┘   └────────────┘

Building Your First MCP Server

Enough architecture diagrams. Here is a working MCP server in Python using the FastMCP framework, which handles the protocol plumbing — message formatting, JSON-RPC handling, schema generation, and the transport layer.

from mcp.server.fastmcp import FastMCP

# Create the server instance — this name is visible to any
# connecting client, including Claude Desktop
mcp = FastMCP("TaskAnalyzer")

@mcp.tool()
def analyze_task(description: str, priority: int) -> dict:
    """Analyze a task description and return structured metadata."""
    summary = description.strip().capitalize()
    
    if priority >= 8:
        level = "critical"
    elif priority >= 5:
        level = "medium"
    else:
        level = "low"
    
    return {
        "original": description,
        "summary": summary,
        "priority_level": level
    }

@mcp.resource("notes://list")
def list_notes() -> list[str]:
    """Return available notes."""
    return [
        "Review Q3 deployment plan",
        "Update API documentation",
        "Schedule architecture review"
    ]

@mcp.resource("notes://{note_id}")
def get_note(note_id: str) -> str:
    """Retrieve a specific note by ID."""
    return f"Contents of note: {note_id}"

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

Three things to notice about this code.

First, type annotations drive everything. The analyze_task function declares description: str and priority: int. FastMCP reads those annotations and auto-generates the JSON schema that clients use to validate inputs before sending them. If a client sends a string where an integer is expected, the protocol catches it before your code ever executes.

Second, the @mcp.tool() and @mcp.resource() decorators are the entire registration API. You don't write schema files, you don't configure routes, you don't build a manifest. The decorator inspects the function and handles everything.

Third, mcp.run() starts the event loop on stdio. The server listens for JSON-RPC messages from whatever client connects to it. It looks like the process is hanging — that's correct. It's waiting for a client to send a message.

Tools vs. Resources: The Distinction That Matters

MCP separates capabilities into two categories, and conflating them is one of the fastest ways to build a server that confuses both clients and models.

Tools are actions. They accept inputs, execute logic, and produce outputs. A tool might analyze text, fetch weather data, create a file, or query a database. The model invokes tools — they are the verbs of your MCP server.

Resources are data. They expose read-only information through URI-based endpoints. A resource might return a list of documents, the contents of a configuration file, or metadata about the server itself. The model reads resources — they are the nouns.

Resources also support parameterized URIs. The pattern notes://{note_id} tells the client that any URI matching that shape — notes://42, notes://alpha — should be routed to the same function, with the variable segment passed as an argument. This is the same pattern used in REST APIs, but applied to a protocol designed for AI consumption rather than human browsing.

Schema Validation: Trust but Verify

Here's a mistake I see repeatedly: developers build MCP servers that return whatever Python dictionary their function produces, without validating the output against a schema. The tool works in testing because the data is clean. In production, a missing field or a wrong type silently corrupts the model's context, and the failure surfaces three reasoning steps later as a hallucination nobody can trace.

FastMCP does not automatically enforce output schemas on resources. Resources are intentionally lightweight. If you want strict output control — and in production you always do — you validate explicitly using Pydantic.

from mcp.server.fastmcp import FastMCP
from pydantic import BaseModel, ValidationError

mcp = FastMCP("ValidatedServer")

class Task(BaseModel):
    id: int
    title: str
    priority: str

class TaskList(BaseModel):
    tasks: list[Task]

@mcp.resource("tasks://list")
def list_tasks() -> dict:
    """Return validated task list."""
    data = {
        "tasks": [
            {"id": 1, "title": "Deploy staging", "priority": "high"},
            {"id": 2, "title": "Update docs", "priority": "low"},
        ]
    }
    validated = TaskList(**data)
    return validated.model_dump()

When the data matches the schema, Pydantic returns a validated object. When it doesn't — say, someone passes a string where id expects an integer — Pydantic raises a ValidationError, and MCP reports it as a resource failure instead of silently returning garbage. This is the difference between a demo server and a production server.

Why This Changes the Economics of AI Integration

The real impact of MCP isn't technical — it's economic. Before MCP, every new tool integration was a project. You needed to understand the API, build the connector, handle authentication, design error recovery, and test the whole chain. That's a week of work per integration, minimum.

With MCP, the protocol handles transport, schema negotiation, and message formatting. The server handles capability exposure and validation. The client handles aggregation and context management. What's left for you is the business logic — the actual thing the tool does. That's a few hours of work, not a week.

This changes who can build integrations. It changes how many integrations a team can maintain. And it changes the break-even point on whether an integration is worth building at all. When the cost of connecting a new tool drops from a week to an afternoon, tools that were never worth connecting suddenly become viable.

What to Do Monday Morning