What Is MCP (Model Context Protocol)? A Python Guide

What the Model Context Protocol actually standardizes, how it differs from LangChain or DSPy, and a basic FastMCP server example

Every LLM framework used to invent its own way of connecting a model to external tools and data — a LangChain tool, a DSPy module, a custom function-calling schema, none of them compatible with each other. MCP standardizes that connection instead of leaving every framework to reinvent it.

What MCP actually standardizes

The Model Context Protocol defines a common interface for three things: tools (functions an AI application can call), resources (structured or semi-structured data it can read without modifying), and prompts (reusable prompt templates a server can expose). An MCP server implements that interface once; any MCP-compatible client — Claude, an IDE, a custom agent — can connect to it without server-specific integration code. It’s often described as “USB-C for AI”: one standard connector instead of a different cable for every device.

Where it sits relative to LangChain and DSPy

These solve different layers of the same problem. LangChain and DSPy are frameworks for building the application logic — chains, agents, prompt optimization. MCP standardizes how that application logic reaches external tools and data once it needs to. In practice they compose: a LangChain agent can call tools exposed by an MCP server rather than each tool needing bespoke LangChain integration code.

Building a server with FastMCP

FastMCP is the standard Python framework for building MCP servers and clients — it handles protocol details (schema generation, transport, lifecycle) so you write plain Python functions:

from fastmcp import FastMCP

mcp = FastMCP("My Server")

@mcp.tool()
def add(a: int, b: int) -> int:
    """Add two numbers"""
    return a + b

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

@mcp.tool() inspects the function signature and docstring to generate the schema a client needs to call it correctly — no separate schema file to maintain and keep in sync with the actual implementation.

Why this matters now

MCP had a significant rewrite in mid-2026 — sessions were dropped from the spec and FastMCP itself was renamed as the ecosystem matured past its earliest, more experimental design. That kind of churn is normal for a young standard, but it’s also why “is this worth learning yet” is a fair question: the core tool/resource/prompt model has stayed stable even as transport and session details evolved, which is the part worth understanding now rather than waiting for it to fully settle.

Should you build an MCP server

If you’re already building tools for an AI application — internal or public — exposing them via MCP instead of a framework-specific integration means any MCP-compatible client can use them without you writing separate integration code per framework. For a one-off internal script calling a single LLM, it’s more protocol than you need; MCP earns its complexity once multiple clients or tools are involved.