How this track works
Eight sessions, one running project: the Daybreak MCP server - a Python server that gives any AI app safe access to a coffee brand's sales, subscriptions, catalog, and ops playbooks. Tonight you learn what the protocol actually says on the wire. By b2 you are writing the server, b5 the client, b6 you deploy it remotely, b7 you secure it, b8 you publish it to the official registry. Every session ships a working artifact.
The N x M problem MCP kills 6 min live
Before MCP, every AI app that wanted to reach your database, your files, or your ticket system needed its own custom integration - and so did every other AI app, for every other tool. M apps times N tools = M x N connectors, all slightly different, all breaking separately. MCP replaces that grid with one protocol: apps implement it once, tools implement it once, everything interoperates.
LiveWhy "just use the API" stopped scaling3 min▶
Every tool already has an API - so why a new protocol? Because the AI app cannot know, at build time, which tools YOU will need at run time. Traditional integrations are compiled in by the vendor. MCP flips it: the app discovers what a server offers at runtime (you will watch tools/list do exactly this in a minute), so anyone can extend any AI app without touching the app's code.
- Discovery over hardcoding: servers describe their own capabilities; hosts adapt on the fly.
- Standard messages: every request and reply is JSON-RPC 2.0 - one grammar for every integration.
- Separation of trust: the host app stays in control of what the model may touch - the server never reaches in.
The connector team that disappeared. A fintech's platform team maintained 23 bespoke "AI plugin" integrations - each with its own auth, retry logic, and breakage schedule. After moving to MCP servers, new integrations became config, not code: point the host at a server URL, approve the scopes, done. The team now maintains servers (their domain logic), not glue.
Self-studyWho owns MCP now - and why that matters2 min read▶
Anthropic open-sourced MCP in November 2024, and in December 2025 donated it to the Agentic AI Foundation under the Linux Foundation, with OpenAI and Block as co-founders. Changes now flow through a public SEP process (like Python's PEPs). Translation for you: MCP is not a vendor lock-in bet - OpenAI adopted it in March 2025, Google DeepMind in April 2025, Microsoft across Copilot and VS Code.
- Spec versions are dates: current is
2025-11-25; the next revision lands 2026-07-28 (this course flags every change it brings). - Ten official SDKs: Tier 1 = TypeScript, Python, C#, Go. This track uses Python.
- An official registry (since Sept 2025) lists ~10k active servers - you publish yours there in b8.
Host, client, server - who is who 6 min live
Three roles, constantly confused, worth getting exactly right tonight. The host is the AI application the human uses (Claude Desktop, Claude Code, your chatbot). Inside it, the host runs one client per connection. Each client talks to exactly one server - the program that exposes tools and data. Host contains clients; clients pair with servers; 1:1 each.
LiveThe wire itself: JSON-RPC 2.0, three message shapes5 min▶
Everything between client and server is JSON-RPC 2.0: a request (has an id, expects a reply), a response (carries the same id back, with result or error), or a notification (no id, fire-and-forget). That is the entire grammar. Step through a real session opening below - press Next and read each message before advancing.
_meta on each request instead. We teach the current spec (2025-11-25) and flag every such change - b8 walks the full delta.
Self-studystdio vs Streamable HTTP - when each3 min read▶
You will build both in this track. The decision is simpler than it looks:
- stdio - the host launches your server as a subprocess and pipes JSON over stdin/stdout. Zero network, zero auth to design, perfect for personal and local tools. Daybreak starts here in b2.
- Streamable HTTP - your server is a web service; clients POST messages to one endpoint, and the server may stream responses. This is how teams and products ship MCP - b6 moves Daybreak onto it.
- Rule of thumb: your machine only → stdio. Anyone else, ever → Streamable HTTP.
Six primitives: three each way 6 min live
Everything MCP can do is six capabilities. The server offers three - tools, resources, prompts. The client offers three back - sampling, roots, elicitation. The pattern to memorize is who controls each: tools are for the model, resources are for the app, prompts are for the user.
LiveTools - discovery, then action5 min▶
Tools are the primitive you will use most. Two methods carry everything: tools/list (what can you do?) and tools/call (do it). Watch discovery first - notice each tool ships a JSON Schema so the model knows exactly what arguments to supply.
The descriptions you see are not documentation garnish - they are the interface the model reads to decide what to call. Writing them well is half of server craft, and b2 drills it.
LiveResources and prompts - context and playbooks4 min▶
Tools act; resources inform. A resource is read-only content with a URI - Daybreak's catalog, its refund policy - that the app attaches to conversations. Prompts are server-authored templates the user picks explicitly, slash-command style. Different control, different primitive: model → tools, app → resources, user → prompts.
Self-studyThe client-side three, honestly3 min read▶
Most intros skip the client-side primitives; most older courses teach two of them as if they were forever. The honest 2026 picture:
- Elicitation (since 2025-06-18): the server pauses and asks the user a structured question - "which store?". Alive, growing, and in b7 you build with it.
- Sampling: the server asks the host's model to complete a prompt, so servers do not need their own API keys. Clever, rarely implemented by hosts - and deprecated 2026-07-28.
- Roots: the client tells the server which directories it may touch. Also deprecated 2026-07-28.
We teach you to recognize all three on the wire, and to build only on the one with a future.
Read a full tool call, message by message ★ 12 min · everyone reads the wire
A user asks Daybreak's assistant: "How did March look - is the dip real?" Here is every message that puts the answer on screen. Step through it and say each message's job out loud - if you can narrate this exchange, you understand MCP better than most people shipping servers.
Step the handshake box in Part 2 again if you skipped it - sessions start there, versions and capabilities agreed.
Step the tools/list box in Part 3 - the host discovers query_sales and hands the model its schema.
Now step tools/call below - the model filled store and week from the user's question; the server does the work and returns content.
Find the id fields pairing each request to its response. Requests have ids; the notifications/initialized message did not. That distinction is the whole message grammar.
Why wire-literacy pays. When an MCP integration misbehaves in production, the difference between a 10-minute fix and a lost afternoon is being able to read the traffic: was the tool never listed (capability problem)? Called with bad arguments (schema problem)? Returned isError:true (server-side failure) or a JSON-RPC error (protocol failure)? You now know the difference - and the Inspector you meet in b2 shows you this same traffic for any real server.
Your turn: two flows most people never see ★ 10 min · explore
Two more scenarios, no narration this time. Step through each and answer the question above it before reading the note under the last message.
LiveQ1 · Prompts: who chose to run this - the model or the user?4 min▶
LiveQ2 · Errors: how does a protocol error differ from a failed tool?3 min▶
Self-studyQ3 · Elicitation: which side starts this exchange?3 min▶
One flow flips the usual direction entirely - the server asks first. You will build this in b7; for tonight, just notice who holds the id.
Try it yourself - this week ◐ 20-30 min total
- Step through all seven wire scenarios on this page until you can predict each next message before pressing Next.
- List the AI apps you already use (Claude Desktop? Claude Code? Cursor? VS Code?) and check which are MCP hosts - all four are. Find where each one configures servers, but do not install anything yet; b2 and b4 do it properly.
- Write down two tools, one resource, and one prompt YOUR dream MCP server would expose for your own work. Bring the list to b2 - one of them becomes real code.
- Skim the official "What is MCP" page (modelcontextprotocol.io) and notice how much of it you now already know.
Official sources covered
This track teaches the working core of the official MCP documentation and the major MCP courses, with the protocol itself made steppable on every page. Certificates, videos, and graded assessments stay on the official sites (linked each session). This page covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · In MCP, the "host" is...
Host = the AI app (Claude Desktop, Claude Code, your chatbot). It contains MCP clients; each client pairs 1:1 with one server - the program offering tools and data.
2 · Tools, resources, prompts - who controls each?
The control triangle: the model decides when to call tools, the app decides which resources enter context, the user explicitly picks prompts. The server only offers.
3 · A reply comes back with an "error" object instead of a "result". What happened?
JSON-RPC error = the protocol itself rejected the request (unknown tool, bad params). A tool that ran but failed returns a normal result with isError:true. Different layers, different fixes.