Phase 5: Model Context Protocol (MCP) · 60 min · Python · MCP SDK · Anthropic SDK

What MCP Is and Why It Matters

Build a tool once as an MCP server — every AI host that speaks MCP can use it instantly.

Hiring signal: MCP is the infrastructure question every AI engineer will face in 2026. Engineers who can explain the architecture, the three primitives, and the ecosystem state are demonstrably ahead of candidates who still think tool integration requires custom code per model.

What you will learn

Explain the MCP architecture: hosts, clients, servers, and the JSON-RPC 2.0 transport
Identify the three MCP primitives: tools, resources, and prompts, and the control model for each
Connect a public MCP server to Claude Desktop and verify a working tool call

The Problem

You build an AI assistant for a company. It needs to read Jira tickets, write to Slack, query a customer database, and call an internal deployment API. Without a standard, you write custom integration code for every tool in every agent. When you add a second agent six months later, you write the integrations again. When Claude upgrades its API, you update all of them.

This is the integration tax that every team building AI products paid from 2022 to 2025. Each model had its own function-calling format. Each tool integration was bespoke. The AI code was tangled with the business logic of each connected system.

Model Context Protocol (MCP) is Anthropic's answer: a standard protocol for connecting AI models to external tools and data. Instead of integrations that only work with one model or one framework, you build a tool once as an MCP server, and any MCP-compatible host — Claude Desktop, Cursor, your custom agent — can use it without modification.

By 2026, MCP had become the de facto standard: 13,000+ servers on GitHub, native support in Claude Desktop, Cursor, and Windsurf, and compatibility announcements from OpenAI and Google. It's the USB-C of AI tool integration.

Three primitives, one protocol
MCP standardizes three types of capabilities: tools (model-controlled function calls), resources (host-loaded context data exposed as URIs), and prompts (user-selected reusable templates). Understanding which primitive fits which use case is the first architectural decision in every MCP implementation.

MCP Architecture

The protocol separates four distinct roles:

Host — the AI application. Claude Desktop, Cursor, your custom Python agent. The host is the process the user interacts with.

Client — embedded inside the host. The client manages the connection to one or more MCP servers, handles the protocol handshake, and routes messages.

Server — a separate process that exposes capabilities. A filesystem server exposes read_file. A GitHub server exposes search_repositories. Each server focuses on one domain.

Transport — how client and server communicate. Two options:

stdio: the server runs as a subprocess; communication happens over stdin/stdout. Used for local tools in Claude Desktop.
Streamable HTTP (Nov 2025 spec): the server runs as a web service. Used for shared infrastructure, remote servers, and production deployments.

The protocol is JSON-RPC 2.0: every message has jsonrpc: "2.0", a method (like tools/list or tools/call), params, and an id for matching responses to requests.

What is the difference between an MCP "tool" and an MCP "resource"?

Control is the key distinction. Tools are like function calls — the model invokes them when it decides they're needed. Resources are like context files — the HOST decides to include them in the context window. A database query is a tool (the AI decides when to query). A README file is a resource (the host loads it as context when relevant).

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers The Three MCP Primitives, The MCP Ecosystem, Build It, What to Practice — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.

Key terms in this lesson

MCP (Model Context Protocol)