🔌 The Agent Is Still Alone
In Episode 6, we gave our agent a personality. We built everything from a cheerful Chef Marco to a sharp-tongued code reviewer. But there’s one problem — these agents are still not connected to the outside world.
Ask about the weather, and they can’t fetch live data. Ask them to read a file, and they can’t reach it. Ask them to create a Jira issue? Not a chance. They have great personalities, but they’re like a genius locked in a room.
Wait — we learned Tool Use back in Ep3. Web search, calculators — isn’t that enough?
Great question! Tool Use introduced the idea that “AI can use tools.” But in reality, there are hundreds of tools out there — weather APIs, file systems, databases, Git, Jira, Slack… What happens if we have to connect each one individually?
😵 The M×N Problem: Connection Hell
Say we have 3 AI models: Claude, GPT, and Gemini. And 5 tools we want to connect: GitHub, Slack, file system, database, and a weather API. We’d need to write custom integration code for every combination.
3 models × 5 tools = 15 custom integrations. Scale that to 10 models and 50 tools? That’s 500 connections to manage. This is the M×N problem — the combinations explode exponentially.
It’s like back when every phone had a different charger — Samsung had its own, LG had its own, iPhone had yet another one…
Exactly! And what solved that problem?
USB-C!
That’s right! The AI world now has its own USB-C — and it’s called MCP!
🔗 MCP: The USB-C of the AI World
MCP stands for Model Context Protocol. This MCP protocol was released as open source by Anthropic in November 2024. The core idea is simple: create one universal connection standard between AI models and external tools.
An open standard protocol for AI models to access external tools and data. Like USB-C, a single spec lets any model connect to any tool. All communication is based on JSON-RPC 2.0.
With MCP, the M×N problem is solved. The model side only needs to implement an “MCP client,” and the tool side only needs to build an “MCP server.” 3 models + 5 tools = 3 + 5 = 8 implementations. Down from 15 to 8!
There’s also a key difference from REST APIs. REST APIs were designed for human developers — you read the docs, memorize the endpoints, and write the code yourself. MCP, on the other hand, is designed so that AI can discover and use tools on its own. The AI asks “what tools do you have?”, and the server automatically responds with “here’s what I have, and here’s what parameters I accept.”
A mechanism where the client asks the server “tell me what tools are available,” and the server dynamically returns tool names, descriptions, and parameter schemas. This is a core MCP capability that REST APIs don’t have.
🏗️ MCP Architecture: Think of a Restaurant
Let’s use a restaurant analogy to understand MCP’s structure.
Host (restaurant manager) is the AI app that manages everything — like Claude Desktop or VS Code. It houses the LLM and manages multiple Clients, just like a manager overseeing several waiters.
Client (waiter) is the connector between Host and Server. Each Client connects one-to-one with one Server. Like a waiter shuttling orders between the kitchen and customers, the Client handles protocol negotiation and message passing.
Server (kitchen) is the side that provides actual functionality — fetching weather data, reading files, querying databases. Like a chef preparing the food.
So Claude Desktop is the Host, my weather server is the Server, and the thing connecting them is the Client?
Perfect! And we can connect multiple Servers to one Host. Hook up a weather server, a file server, and a GitHub server all at once — then the AI can check the weather, read files, AND open pull requests!
🧩 The Three Building Blocks of MCP
An MCP server can provide three types of capabilities.
1. Tools — Functions the AI can execute: search_web, read_file, send_email, and so on. This is what we covered in Ep3’s Tool Use! The difference now is that these tools follow the MCP standard, so any AI model can use them the same way.
2. Resources — Data the AI can read: file contents, database records, config files, etc. Addressed by URI, and read-only. Accessed with paths like file:///path/to/doc.txt, similar to web page URLs.
3. Prompts — Reusable templates. Define a complex workflow like “do a code review” once, then invoke it whenever needed.
What’s the difference between a Tool and a Resource? Don’t they both just retrieve data?
A Tool is an “action” — it executes something and can change the world, like sending an email or creating a file. A Resource is “reading” — it only retrieves existing data without changing anything. Think of it as the difference between borrowing a book from a library (Resource) and writing one yourself (Tool)!
🚀 Transport: How Do They Connect?
MCP supports two connection methods.
stdio (standard input/output) — Used for local machines. The MCP server runs as a child process, communicating over stdin/stdout pipes. No network needed — fast and simple. Perfect for personal development environments.
Streamable HTTP — Used for remote servers. Requests go out via HTTP POST, responses come back via SSE (Server-Sent Events). Supports OAuth 2.1 authentication for secure connections to cloud services.
A lightweight message protocol where requests and responses are exchanged as JSON. All MCP communication follows this format. Send a request like “method: list_tools” and the server returns results in JSON.
🛠️ Exercise 1: Build Your Own MCP Server
Let’s build an MCP server from scratch! Using Python’s FastMCP framework makes it remarkably simple.
An MCP server framework that auto-generates tool definitions from Python type hints. Add the @mcp.tool() decorator and it analyzes your function’s parameter types and docstring to automatically produce a JSON Schema.
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("weather-demo")
@mcp.tool()
def get_weather(city: str) -> str:
"""Get current weather for a city.
Args:
city: City name (e.g. Seoul)
"""
weather_db = {
"Seoul": "Clear, 18°C",
"Tokyo": "Cloudy, 22°C",
"New York": "Rainy, 15°C",
}
return weather_db.get(
city, f"No data for {city}"
)
if __name__ == "__main__":
mcp.run(transport="stdio")
That’s all there is to it! Install with pip install mcp, add the @mcp.tool() decorator, and you’re done. FastMCP analyzes the type hint (city: str) and docstring to auto-generate a JSON Schema. The AI automatically knows “this tool takes a string parameter called city.”
Is that really it? How is this any different from writing a normal function?
It’s almost identical to writing a regular function! The only difference is that one @mcp.tool() decorator. That single line transforms the function into an “MCP-standard tool.” Any AI app that connects to this server can use it!
🛠️ Exercise 2: Connect via MCP Client
Now that we have a server, let’s connect to it from a client.
from mcp import (
ClientSession,
StdioServerParameters
)
from mcp.client.stdio import stdio_client
server = StdioServerParameters(
command="python",
args=["mcp_weather_server.py"],
)
async with stdio_client(server) as (r, w):
async with ClientSession(r, w) as s:
await s.initialize()
tools = await s.list_tools()
print(f"Found {len(tools.tools)}"
f" tools")
result = await s.call_tool(
"get_weather",
{"city": "Seoul"}
)
print(result.content[0].text)
Let’s break down the key parts. stdio_client(server) launches the server as a child process and connects to it. s.list_tools() is exactly Tool Discovery — asking the server “what tools do you have?” And s.call_tool() executes the tool.
Running it produces:
Found 1 tools
Clear, 18°C
The full code is available at GitHub ep07.
🌍 MCP Adoption in the Real World
MCP became an industry standard within a year of its release. The numbers speak for themselves.
97 million monthly SDK downloads. Over 10,000 public MCP servers active. In December 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF) under the Linux Foundation — co-founded alongside OpenAI and Block. MCP is no longer any single company’s technology; it’s a shared industry standard.
Here’s a snapshot of major adoption:
| Company / Product | MCP Support | When |
|---|---|---|
| Anthropic | Claude Desktop, Claude Code native support | 2024.11 |
| OpenAI | Agents SDK, ChatGPT Desktop integration | 2025.03 |
| Google DeepMind | Gemini MCP support | 2025.04 |
| Microsoft | Copilot Studio, VS Code integration | 2025 |
| Dev Tools | Cursor, Zed, Replit, Windsurf, etc. | 2025 |
| Enterprise | Salesforce, Atlassian, PayPal, etc. | 2025 |
OpenAI adopted it too? Even though Anthropic made it?
That just shows how much MCP was needed! USB-C started as a proposal from one company, but eventually every manufacturer adopted it. When a standard is good enough, even competitors use it.
⚔️ MCP vs REST API
You might ask: “Can’t we just use REST APIs?” There are important differences.
| Comparison | REST API | MCP |
|---|---|---|
| Designed for | Human developers | AI agents |
| Tool discovery | Read docs, manual coding | Runtime auto-discovery (list_tools) |
| Schema | Separate documentation | JSON Schema built-in |
| State management | Stateless (fresh each time) | Stateful sessions supported |
| Bidirectional | Request-response only | Server → client notifications |
| Authentication | Different per API | OAuth 2.1 standard |
Here’s the key point: MCP is not a replacement for REST APIs. MCP servers often call REST APIs internally. MCP sits on top of REST APIs as a standard layer that lets AI automatically discover and use tools.
⚡ Connect Your MCP Server in 3 Lines
Connecting an MCP server in Claude Desktop is surprisingly simple — just add 3 lines to a config file.
{
"mcpServers": {
"weather": {
"command": "python",
"args": [
"mcp_weather_server.py"
]
}
}
}
Save this to claude_desktop_config.json and the server connects automatically when Claude Desktop restarts. Then just tell Claude “what’s the weather in Seoul?” and it calls our get_weather tool directly!
%APPDATA%\Claude\claude_desktop_config.json on Windows, and ~/Library/Application Support/Claude/claude_desktop_config.json on macOS. See the MCP official quickstart for a detailed guide.
🔗 Connecting the Dots
Let’s see how everything we’ve learned ties into MCP.
Ep3 Tool Use gave the AI “hands.” MCP standardizes those hands — unifying the custom connections we built for each tool into one universal spec.
Ep5 Agent Loop taught us the “think → act → observe” loop. The tools called inside that loop can now be MCP servers — servers you build once and reuse across multiple apps.
Ep6 System Prompts gave the AI a personality. Personality (system prompt) + capability (MCP server) = a complete agent!
References
- Model Context Protocol — Official Docs
- MCP Specification (2025-03-26)
- Anthropic — Introducing MCP
- Linux Foundation — Agentic AI Foundation Announcement
- This Episode’s Code (GitHub)
◀ Previous: Ep.6 — Give Your Agent a Personality
▶ Next: Ep.8 — Assembling Agents with the SDK (coming soon)
✅ What We Learned Today
1. MCP protocol is the USB-C of the AI world. It turns the combinatorial explosion of M models × N tools into a clean M+N set of implementations using one standard protocol. Announced by Anthropic in 2024, it’s now an industry standard adopted by OpenAI, Google, and Microsoft alike.
2. MCP architecture follows a Host → Client → Server structure. The Host (AI app) communicates with the Server (tool provider) through a Client. Servers expose three capability types: Tools (execute), Resources (read), and Prompts (templates).
3. Building a server with FastMCP is surprisingly easy. A single @mcp.tool() decorator transforms a plain Python function into a standard tool that any AI app can connect to. Three lines in the Claude Desktop config and you’re live.
Next episode, we put it all together. We’ll use the Claude Agent SDK to create multiple agents, connect MCP servers, and build a system where agents collaborate with each other!
