MCP is the USB-C for AI apps — one open protocol that lets any model host plug into any tool or data source. Learn the host/client/server model and the two layers underneath.
Why: before MCP, every AI app wired up every tool with bespoke, one-off integration code — an M×N mess. MCP defines one protocol so any host can talk to any server, turning M×N into M+N. When: use MCP whenever you want a capability (a database, an API, a filesystem) to be reusable across Claude Desktop, Claude Code, IDEs, and your own apps. Where: it is an open standard, not an Anthropic-only feature.
WITHOUT MCP every app writes custom glue for every tool (M x N)
WITH MCP each app and each tool speaks one protocol (M + N)
"USB-C for AI": one connector, and everything interoperates.Why: MCP has three roles and keeping them straight is the whole mental model — the host is the AI app, it runs one client per connection, and each client talks to one server that exposes capabilities. When: you build servers; hosts (Claude Desktop, Claude Code, your app) and their clients already exist. Where: a host can run many clients at once, each connected to a different server.
HOST (Claude Desktop / Claude Code / your app)
| runs one CLIENT per server
+--- CLIENT <====MCP====> SERVER (your weather tool)
+--- CLIENT <====MCP====> SERVER (a database)
+--- CLIENT <====MCP====> SERVER (the filesystem)
You write SERVERS. The host and clients are already built.Why: a server offers capabilities in exactly three shapes, and choosing the right one matters — tools are actions the model calls, resources are data the model reads, prompts are reusable templates the user invokes. When: pick tools for "do something", resources for "here is context", prompts for "a saved workflow". Where: the next three lessons build one of each.
TOOLS model-invoked actions (get_weather, create_ticket)
RESOURCES app-/model-read data (file contents, a DB row) — like GET
PROMPTS user-invoked templates ("summarize this PR") — reusable flows
Rule of thumb: side effects -> tool; read-only context -> resource.Why: MCP separates WHAT is said from HOW it travels — the data layer is JSON-RPC 2.0 (the messages and lifecycle), the transport layer moves those messages (over stdio locally or HTTP remotely). When: you rarely touch these directly, but knowing the split explains why the same server runs locally and remotely unchanged. Where: the SDK implements both; you write handlers, it speaks the protocol.
DATA LAYER JSON-RPC 2.0 messages: initialize, tools/list,
tools/call, resources/read, ... + lifecycle
TRANSPORT LAYER how bytes move:
stdio -> local subprocess (fast, private)
HTTP -> remote/multi-client (streamable HTTP + SSE)
Your handlers stay the same; only the transport changes.