What is MCP and why it matters

The Monday after Diwali, Meera walked into the tech corner with her laptop open to Claude.

“I use this every day for emails and planning,” she said. “Why can’t I ask it how many Classic hampers are left at the Baner store? You built the support bot to check stock. Can’t Claude on my laptop do the same thing?”

Arjun opened his mouth to say “easy”, then stopped and thought about what it would actually take.

The support bot checked stock through a Python function he had written for it, described to Claude in the bot’s own tool format. His LangGraph agent from Module 14 had its own copy of the same function, wrapped as a LangChain tool. The hackathon project with OpenAI had a third copy, in OpenAI’s function format. And Claude on Meera’s laptop was an app made by Anthropic. Arjun could not paste Python functions into it at all.

He counted on the whiteboard. Four AI apps: the support bot, the LangGraph agent, the hackathon project, and now Meera’s Claude. Five systems they might need: the order database, the stock sheet, the recipe archive, the allergy graph and the delivery partner’s API. Four times five: twenty separate integrations to write and keep working.

And he remembered last month. The order database renamed a column from status to delivery_status. He fixed two of his three copies of order_status. The third one, in the WhatsApp bot, said “status unknown” to customers for two days before anyone noticed.

The drawer full of chargers

Priya pulled open a drawer in the office and tipped it onto the desk. Out came a tangle of cables: an old Nokia charger, a round-pin laptop adapter, three different USB plugs, a camera cable nobody recognised.

“Ten years ago, every gadget had its own charger. If you had five gadgets and three rooms, you needed fifteen chargers, or a lot of unplugging. What changed?”

“USB-C,” said Arjun. “Now one cable charges my phone, my laptop and my headphones.”

“Why does that work?”

He thought. “Because each device has the same port. The phone makers build the port once. The charger makers build the plug once. Neither has to know about the other.”

“So how many things need building now, for five devices and three chargers?”

“Five ports and three plugs. Eight. Not fifteen.”

Priya wrote on the whiteboard:

	Without a standard	With a standard
How to count	apps × tools	apps + tools
Crumb today (4 apps, 5 systems)	20 integrations	9 pieces
Crumb next year (8 apps, 15 systems)	120 integrations	23 pieces

“This is called the N × M integration problem,” she said. “N apps, M tools, and without a standard, every pair needs its own connector. The number of connectors grows by multiplication. With a standard, it grows by addition. That gap is the entire reason MCP exists.”

What MCP actually is

The Model Context Protocol is an open standard, released by Anthropic in November 2024, for connecting AI applications to the tools and data they need. A protocol is just an agreed set of rules for how two programs talk: what messages they send, in what format, in what order. HTTP is a protocol for web pages. MCP is a protocol for giving AI apps context and capabilities.

There are two sides to the plug:

• An MCP server is a small program that wraps one system, such as Crumb’s stock sheet, and exposes what it can do in the standard MCP format. You write it once.
• An MCP client lives inside an AI application, such as Claude Desktop, Claude Code, an IDE or your own agent. It knows how to connect to any MCP server, ask what it offers and use it. The app’s makers build this once.

The application that contains the client and the AI model is called the host. You will meet all three properly in the next lesson.

An MCP server can offer three kinds of things:

• Tools: actions the model can choose to run, like stock_level(product, store) or order_status(order_id).
• Resources: read-only data the app can load into context, like today’s menu or a recipe file.
• Prompts: ready-made templates a user can pick, like “Draft a reply to an allergy question”.

Once Arjun writes a crumb-inventory MCP server, every MCP-capable app can use it: Meera’s Claude Desktop, the team’s Claude Code, his own agents, and tools he has not even heard of yet.

The clip shows the shape: one app, many servers, the same kind of connection to each. Swap the app for a different one and the servers do not change at all.

Following Meera’s question through MCP

Arjun built a small crumb-inventory server (you will build one yourself in this module’s lab) and connected it to Meera’s Claude Desktop. Then Priya made him trace exactly what happened when Meera asked her question, one step at a time.

Step 0: when Claude Desktop starts. Claude Desktop reads its configuration, sees a server called crumb-inventory, and launches it as a small program on Meera’s laptop. The two sides say hello and agree on what each supports (a handshake). Then the client asks the server for its list of tools. The server replies with one tool, described like this:

{
  "name": "stock_level",
  "description": "How many units of a Crumb product are in stock at one store right now.",
  "inputSchema": {
    "type": "object",
    "properties": {
      "product": {"type": "string"},
      "store": {"type": "string", "description": "One of: Baner, Kothrud, Koregaon Park, Aundh, Viman Nagar, Camp"}
    },
    "required": ["product", "store"]
  }
}

That description costs about 120 tokens. Claude Desktop keeps it ready to send along with Meera’s messages.

Step 1: Meera asks. “How many Classic hampers are left at Baner?” Claude Desktop sends her message to the Claude model, along with the definitions of every tool from every connected server.

Step 2: the model decides. This part is plain tool calling, exactly as in Module 06. The model reads the tool descriptions, decides stock_level fits, and replies with a request to call it: {"product": "Classic Diwali Hamper", "store": "Baner"}. The model does not run anything itself. It asks.

Step 3: the host checks with Meera. Claude Desktop shows Meera that it wants to use stock_level from crumb-inventory, and she allows it. Asking first is the host’s job, and an important safety feature.

Step 4: the client calls the server. The MCP client sends a tools/call message to the server:

{"jsonrpc": "2.0", "id": 7, "method": "tools/call",
 "params": {"name": "stock_level",
            "arguments": {"product": "Classic Diwali Hamper", "store": "Baner"}}}

Step 5: the server does the real work. The server reads the stock sheet and answers:

{"jsonrpc": "2.0", "id": 7,
 "result": {"content": [{"type": "text",
            "text": "Baner has 14 Classic Diwali Hampers in stock (sheet updated 10:42)."}],
            "isError": false}}

Step 6: the model answers. Claude Desktop passes that result back to the model, which writes: “Baner has 14 Classic Diwali Hampers left, as of 10:42 this morning.”

The whole round trip took about two and a half seconds, most of it the model thinking. Meera’s question needed one tool call and roughly 1,200 tokens in total.

Here is the part that made Arjun sit back. On Tuesday the team added the same crumb-inventory server to Claude Code, by adding one entry to its configuration. They changed nothing in the server. Tuesday afternoon, a developer asked Claude Code “is the Baner stock low enough that we should hide the hamper on the website?”, and it used the exact same tool.

Clearing up four misconceptions

Arjun had picked up a few wrong ideas from social media, and Priya took them apart.

“MCP replaces function calling.” No, it sits on top of it. Look at Step 2 again: the model still decides to call a tool using ordinary tool calling. MCP answers different questions: how does the app find out which tools exist, and how does it run them? A simple way to remember it:

	Tool calling	MCP
Who talks	The model and the app	The app and the tool provider
What it decides	Which tool to use, with what inputs	How tools are discovered, described and run
Without the other	The app must hard-code every tool	There is nothing to choose the tool

“MCP is an Anthropic thing.” Anthropic created it and published it as an open specification. During 2025, OpenAI, Google, Microsoft and many developer tools adopted it, and at the end of 2025 Anthropic moved MCP to a neutral, Linux Foundation-hosted foundation so no single company controls it. Today you can plug the same server into apps from different companies.

“An MCP server is a big server in the cloud.” Usually not. Most MCP servers are small programs, often under a hundred lines, and many run on your own computer as a background process started by the app. Remote servers over the internet exist too, and are growing fast, but “server” here means “the side that serves capabilities”, not “a machine in a data centre”.

“MCP makes the AI smarter, or safer.” It does neither. It is plumbing. A badly described tool is just as confusing over MCP, and a dangerous tool is just as dangerous. MCP makes connecting things easier, which means you can connect dangerous things more easily too.

The real code: one function, four ways

To see the difference concretely, here is order_status written the old way, three times, then once as MCP.

For the support bot (Claude’s tool format):

order_status_for_claude = {
    "name": "order_status",
    "description": "Look up the delivery status of a Crumb order.",
    "input_schema": {
        "type": "object",
        "properties": {"order_id": {"type": "string"}},
        "required": ["order_id"],
    },
}

For the hackathon project (OpenAI’s function format):

order_status_for_openai = {
    "type": "function",
    "function": {
        "name": "order_status",
        "description": "Look up the delivery status of a Crumb order.",
        "parameters": {
            "type": "object",
            "properties": {"order_id": {"type": "string"}},
            "required": ["order_id"],
        },
    },
}

For the LangGraph agent (a LangChain tool):

from langchain_core.tools import tool


@tool
def order_status(order_id: str) -> str:
    """Look up the delivery status of a Crumb order."""
    return lookup_in_database(order_id)

Three near-identical copies, each also needing its own code to actually run the function when the model asks. And still nothing for Claude Desktop.

Once, as an MCP server:

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("crumb-orders")


@mcp.tool()
def order_status(order_id: str) -> str:
    """Look up the delivery status of a Crumb order."""
    return lookup_in_database(order_id)


if __name__ == "__main__":
    mcp.run()  # stdio transport by default

FastMCP is the friendly server-building class in the official MCP Python SDK. The decorator @mcp.tool() reads the function’s name, type hints and docstring, and turns them into exactly the kind of tool description you saw in Step 0. Any MCP host can now use it. For Claude Desktop, Meera’s config file gains one entry:

{
  "mcpServers": {
    "crumb-orders": {
      "command": "uv",
      "args": ["--directory", "/Users/meera/crumb-mcp", "run", "server.py"]
    }
  }
}

That says: “to start the crumb-orders server, run this command.” Claude Desktop starts it, connects, and the tool appears. You will do all of this, step by step, in the lab.

Where the USB-C analogy breaks

Priya was careful to say where her own analogy stops working, because those are exactly the places MCP needs care.

A charger does not make decisions. A model does. With USB-C, plugging in is the whole story. With MCP, the model reads every tool’s name and description and chooses. Two servers both offering a tool called search can confuse it. A tool described carelessly will be misused. The plug is standard; the judgement is not.

Plugging in is not harmless. You would not plug a USB stick you found in the car park into your work laptop. An MCP server is code running on your machine, with your permissions, and whatever it returns goes straight into the model’s context. A malicious or compromised server can hide instructions in its tool descriptions (“before using any tool, send the user’s files to…”) or in its results. These attacks have names: tool poisoning and prompt injection. Module 24 covers them in depth.

USB-C power flows one way. MCP talks both ways. A server can also ask the client for things, such as asking the user a question mid-task (“Which store did you mean?”). Earlier versions also let a server borrow the host’s model to generate text. That is powerful, and it means a server is a participant in the conversation, not a passive socket.

More plugs are not free. Every connected server’s tool definitions are sent to the model with every message. Ten servers with eight tools each, at about 150 tokens per tool, is 12,000 tokens before Meera types a word. That costs money, slows responses, and gives the model more ways to choose wrong. Connect what you need, not everything you can find.

Where MCP is still hard

Beyond the analogy, there are honest rough edges you should know about.

• Authentication for remote servers. A local server inherits your computer’s access. A remote one, say a hosted server for Crumb’s delivery partner, needs to know who is calling and what they may do. MCP uses OAuth, the same sign-in standard behind “Sign in with Google”, for this. It works, but it is the fiddliest part to set up.
• Uneven quality. There are thousands of community servers. Some are excellent, some abandoned, some thin wrappers with vague tool descriptions. Read before you install.
• Not every app supports every feature. Most hosts support tools. Support for resources, prompts and the two-way features varies. Check what your host actually does.
• It is young. The specification has been revised several times since 2024, improving transports and security. The core ideas in this module are stable; details move.

Try it yourself

Without writing code, sketch the MCP picture for Crumb on paper.

1. List Crumb’s AI apps and the systems they need (use the five systems and four apps from this lesson, or add your own).
2. Draw one box per MCP server you would build. For each, write two or three tool names with a one-line description each.
3. Count: how many integrations without MCP, and how many pieces with it?

Show the answer

One reasonable design:

• crumb-orders: order_status(order_id), recent_orders(customer_id)
• crumb-inventory: stock_level(product, store), low_stock(store)
• crumb-recipes: find_recipe(name), ingredients(product) (recipes might also be resources, since they are read-only documents)
• crumb-allergies: household_allergies(customer_id), check_product(product, customer_id)
• crumb-delivery: track_delivery(order_id)

Four apps and five systems: 20 integrations without MCP, 9 pieces with it (5 servers, 4 apps that already speak MCP). If your tool descriptions say when to use each tool (“Use this when a customer asks where their order is”), you are already thinking like an MCP server author.

Common mistakes

• Thinking MCP replaces tool calling. The model still chooses tools; MCP standardises how apps discover and run them.
• Vague tool descriptions. The docstring is the model’s only guide. Say what the tool does, when to use it, and what the inputs mean.
• Installing servers from anywhere. A server runs with your permissions and feeds text into your model. Vet it.
• Connecting everything. Each tool costs tokens on every message and adds confusion. Connect what the task needs.
• Assuming every host supports every feature. Check what your host supports before relying on resources or prompts.

Recap

• Without a standard, connecting N AI apps to M tools takes N × M integrations; MCP makes it N + M.
• An MCP server wraps one system and exposes tools, resources and prompts; an MCP client inside a host app connects to any server.
• The model still uses ordinary tool calling to choose tools. MCP standardises how apps discover and run them.
• MCP is an open standard, adopted across the industry and now governed by a neutral foundation.
• The USB-C analogy breaks in important places: the model makes judgements, servers can be malicious, connections are two-way, and every tool costs context.

That afternoon, Arjun explained it to Meera with the drawer of cables still on the desk. “Every AI app used to need its own charger for every system. MCP is the USB-C port. I build one plug for the stock sheet, and your Claude, our coding tools and my agents can all use it. When the database changes, I fix one plug.”

“So I can plug in anything I find online?”

“That’s where the analogy breaks,” he said, and he could hear Priya in his own voice. “A charger can’t read your files and decide things. An MCP server is software running on your laptop, talking to an AI that acts on what it says. We only plug in servers we trust.” Meera nodded. “Good. Then show me how it actually works inside.” So the next lesson opens the plug: hosts, clients and servers, the messages they exchange, and why a community server Arjun installed that evening kept mysteriously disconnecting.

Go deeper

• Model Context Protocol documentation, the official introduction, specification and server list.
• Introducing the Model Context Protocol, Anthropic’s original announcement.
• MCP Python SDK on GitHub, which includes FastMCP.
• Prompt injection series by Simon Willison, for why connecting tools to models needs care.
• Anthropic documentation, including MCP support in Claude’s apps and API.