The MCP Practitioner Course · Lesson 1 of 7
Foundations and Protocol Mechanics
> ~3 hours · what MCP actually is, the four roles, the four primitives, and the wire format
By the end of this module you'll have run the MCP Inspector against a reference server and traced a real message exchange between a host and a server. We're not building servers yet — Module 2 is for that. This one is about getting the model of how MCP works correct in your head, because everything that follows depends on it.
---
Anthropic announced MCP in November 2024. By March 2025 OpenAI had adopted it. By July, Microsoft Copilot Studio. By November, AWS. In December, Anthropic donated the spec to the Linux Foundation under the new Agentic AI Foundation. Today every major model provider supports it.
That timeline matters. Inside fifteen months MCP went from one company's idea to a multi-vendor standard governed by a foundation. Anyone telling you "MCP is too new" is two years behind.
The problem MCP solves is the N×M problem. Before MCP, if you wanted Claude to talk to QuickBooks, somebody wrote a Claude-to-QuickBooks connector. If you wanted GPT to talk to QuickBooks, somebody wrote a separate one. ChatGPT plugins, OpenAI function calling, custom GPT actions, Anthropic's tool use API, Gemini's function calling — all incompatible. N model providers × M tools = N × M custom integrations to build and maintain.
MCP redraws the picture. Build M MCP servers — one per tool — and N MCP-compatible clients use them. The math becomes N + M. The picture goes from a tangled mesh to a clean bus.
This is the same shape of problem the Language Server Protocol solved for editors. MCP is LSP for AI assistants. The other analogy you'll hear is "USB-C for AI." Overused but accurate.
For a consultant or IT partner serving SMBs, the commercial implication is enormous. The integration you build today is portable across every model the client might use this year, next year, or in 2030. You're building durable assets, not vendor-specific glue code. That's why this is a services wedge, not a one-shot project.
---
Most MCP confusion comes from sloppy use of these four words. Lock them in now.
Host. The AI application the user actually opens and types into. Claude Desktop. Cursor. VS Code with an MCP extension. ChatGPT (when it's an MCP host). Custom-built agents. The host is where the user is.
Client. The piece *inside* the host that speaks the MCP wire protocol. There is one client per server connection. If your host connects to three servers, there are three clients running inside it. You almost never write client code — the host's runtime ships with it. Common confusion: people say "client" when they mean "user." The user uses the host. The host runs clients. The clients talk to servers.
Server. The thing you write. A server exposes some combination of tools, resources, prompts, and (eventually) tasks. Servers are usually small — a typical first MCP server is 50–200 lines of TypeScript or Python.
Transport. How messages move between client and server. Two options:
- STDIO — server runs as a subprocess of the host, messages flow over stdin/stdout. Simple, secure-by-default (no network surface), perfect for developer tools. Module 2 uses this.
- Streamable HTTP — server runs as a network service. The host connects over HTTP, optionally upgrading to Server-Sent Events. Module 3 uses this.
A common mistake in older docs: references to a separate "HTTP+SSE" transport. That's been folded into Streamable HTTP. Don't waste time on the deprecated path.
The mental model: User → Host → Client(s) → Transport → Server(s). Draw this when you describe MCP to a client during a sales conversation. It demystifies the architecture in 30 seconds and positions you as the person who knows how it works.
---
A server exposes some combination of four primitives. Each one solves a different job.
1. Tools. Functions the model can call to take action. Each tool has a name, a natural-language description, and a JSON Schema for its inputs. The model reads the description and decides when to call. Examples: `send_email`, `create_invoice`, `restart_service`. Tool descriptions are prompts. A good description gets the tool used correctly. A bad description gets it ignored or misused. We'll dig into this in Module 2.
2. Resources. Read-only data the model can pull into context. URI-addressable: `file:///path/to/doc`, `db://customers/123`. Use resources when you want the model to *consult* something, not *do* something. If the operation might mutate state, it's a tool, not a resource.
3. Prompts. Parameterized prompt templates the user can invoke. They surface in the host as slash commands or menu items. Example: `/audit-this-table` with argument `table_name`. The primitive everybody forgets — and often the most commercially useful one. Build one prompt; every user gets the same quality output.
4. Tasks. Long-running asynchronous operations (still experimental). Pattern: client kicks off the task, gets a task ID back immediately, polls or subscribes for the result later. Use when operations take minutes to hours. You won't write tasks in this course's labs — the tooling is still settling.
---
Every message on the wire is a JSON-RPC 2.0 frame. Three shapes:
```json // Request — has an id, expects a response {"jsonrpc":"2.0","id":1,"method":"tools/call", "params":{"name":"list_files","arguments":{"path":"/tmp"}}}
// Response — same id, carries result or error {"jsonrpc":"2.0","id":1,"result":{"content":[...]}}
// Notification — no id, fire-and-forget {"jsonrpc":"2.0","method":"notifications/initialized"} ```
That's the entire wire format. Three shapes.
Every session opens with a three-step handshake: client sends `initialize` with its protocol version and capabilities; server responds with the same; client sends `notifications/initialized`. After that the session is live.
---
60–75 minutes. The goal is to install the Inspector, connect it to a reference server, and see every message in a complete session. You walk away knowing exactly what's on the wire.
```bash
npx @modelcontextprotocol/inspector@latest
```
Once connected:
- Watch the initialize handshake. Note the protocol version each side advertises and the capability flags.
- Call `tools/list`. See the catalog of tools — names, descriptions, JSON Schemas.
- Invoke a tool. Pick a simple one (the everything server has `add`) and watch the request fly out and the response come back. Inspect the raw JSON.
- Read a resource. Call `resources/list`, then `resources/read` on one of them.
- Trigger a prompt. Same pattern: `prompts/list` then `prompts/get`.
When you can read those raw frames and explain what each field is for to a colleague, you have the protocol.
---
- Searching the web for "MCP" without context — you'll get Microsoft Certified Professional results. Always search "MCP protocol" or "Model Context Protocol."
- Confusing client and user. The user uses the host. The host contains clients. Whiteboard it if you get tangled.
- Treating tool descriptions like API docs. They're prompts, not docs.
---
- Have Node.js 20+ and your editor of choice ready
- Have an Anthropic API key (free tier is fine)
- Skim the official MCP TypeScript SDK at `github.com/modelcontextprotocol/typescript-sdk`
- Make sure Claude Desktop is installed and you know where its `claude_desktop_config.json` lives for your OS
In Module 2 we ship a working stdio MCP server with one tool, wire it into Claude Desktop, and run a real conversation that calls our code.