What is MCP? The Model Context Protocol Explained with a Python Example

If you have looked at AI agent job descriptions recently, you have probably seen "MCP" listed next to RAG and LangGraph. The Model Context Protocol has quickly become the standard way to connect AI applications to tools and data.

This guide explains what MCP is, why it matters, and how to build your first MCP server in Python.

The problem MCP solves

An AI assistant becomes far more useful when it can reach real systems: your database, your ticketing tool, your file storage, your CRM.

Before MCP, every AI application connected to every system in its own way. If you had 5 AI apps (a chat assistant, an IDE assistant, an internal agent...) and 10 systems, you potentially needed 50 custom integrations, each written differently.

MCP is an open protocol that standardises that connection. You build an MCP server for a system once, and any MCP client (an AI app that supports the protocol) can use it. A common analogy: MCP is to AI apps what USB-C is to devices, one standard connector instead of a drawer of different cables.

MCP was introduced by Anthropic in late 2024 as an open standard and is now supported across many AI assistants, IDEs and agent frameworks.

How MCP works

MCP has three roles:

• Host: the AI application the user interacts with (a desktop assistant, an IDE, your own agent)
• Client: the component inside the host that talks to one MCP server
• Server: a program that exposes capabilities from some system, such as a database or an API

The server can offer three kinds of things:

Servers run either locally (the host starts them as a subprocess and talks over standard input/output) or remotely (over HTTP, for shared servers used by many people).

Build your first MCP server in Python

We will build a small server for an online shop with two tools and one resource.

Install the official Python SDK:

pip install "mcp[cli]>=2"

This tutorial uses version 2 of the SDK, where the server class is called MCPServer. (In version 1.x it was FastMCP, imported from mcp.server.fastmcp, and older tutorials still show that.)

Create shop_server.py:

from mcp.server.mcpserver import MCPServer

mcp = MCPServer("shop")

# A stand-in for your real database
ORDERS = {
    "ORD-1001": {"status": "shipped", "courier": "BlueDart", "eta": "2026-10-10"},
    "ORD-1002": {"status": "processing", "courier": None, "eta": "2026-10-12"},
}


@mcp.tool()
def get_order_status(order_id: str) -> str:
    """Get the current status, courier and expected delivery date of an order.

    Args:
        order_id: The order ID, for example ORD-1001.
    """
    order = ORDERS.get(order_id.strip().upper())
    if order is None:
        return f"No order found with ID {order_id}."
    courier = order["courier"] or "not assigned yet"
    return f"Order {order_id}: {order['status']}, courier {courier}, ETA {order['eta']}."


@mcp.tool()
def list_orders_by_status(status: str) -> list[str]:
    """List order IDs that currently have the given status (shipped, processing or delivered)."""
    return [oid for oid, o in ORDERS.items() if o["status"] == status.lower()]


@mcp.resource("policy://returns")
def returns_policy() -> str:
    """The shop's returns policy."""
    return "Items can be returned within 7 days of delivery if unused and in original packaging."


if __name__ == "__main__":
    mcp.run()  # uses standard input/output by default

A few things to notice:

• The docstrings matter. The model reads the tool name, description and parameter types to decide when and how to call it. Clear descriptions mean fewer wrong calls.
• The tools are narrow. There is no run_sql(query) tool. Narrow tools are easier to secure and easier for models to use correctly.
• Errors are returned as helpful text, so the model can recover ("No order found...") instead of crashing.

Test it

The SDK ships with a development inspector:

mcp dev shop_server.py

This opens a web UI where you can list the tools and call them by hand before connecting any AI app.

Connect it to an AI app

Most MCP hosts let you register a local server by giving the command that starts it. For example, desktop assistants typically use a JSON config like this:

{
  "mcpServers": {
    "shop": {
      "command": "python",
      "args": ["/full/path/to/shop_server.py"]
    }
  }
}

Coding assistants usually have a command for it; in Claude Code, for example:

claude mcp add shop -- python /full/path/to/shop_server.py

Now ask the assistant "Where is order ORD-1001?" and it will call your get_order_status tool.

MCP vs function calling: what's the difference?

They work together; they are not alternatives.

• Function calling (or tool calling) is how a model, inside one API request, says "call this tool with these arguments".
• MCP is how tools are packaged, discovered and shared across applications.

When an MCP host connects to your server, it fetches your tool definitions and passes them to the model as ordinary tools. The model then uses normal function calling. MCP just means you did not have to write that integration separately for every app.

Security: what every MCP developer must know

MCP servers give AI models real access to real systems. Treat them like any other privileged API.

• Least privilege. Expose only what is needed. A read-only tool is much safer than a write tool.
• Validate every input. The model can be tricked into passing malicious arguments. Validate IDs, ranges and formats on the server.
• Require approval for risky actions. Refunds, deletions, emails and payments should need a human confirmation.
• Beware prompt injection through tool results. If a tool returns text from an email, document or web page, that text might contain instructions aimed at the model. Hosts and agents should treat tool results as data, not commands.
• Only install servers you trust. A third-party MCP server runs with whatever access you give it. Review the code or use servers from trusted publishers.
• Use proper authentication for remote servers, and never put secrets in tool descriptions or responses.

Where MCP fits in your learning path

MCP sits in the middle of the agentic AI roadmap: after you understand LLM APIs and RAG, and before you build complex agent workflows with frameworks like LangGraph. Next step: build your first AI agent with LangGraph.