Course Review and Exam Tips
The Whole Protocol on One Page
You've gone from 'what is MCP?' to building, securing, and deploying servers and clients. Let's consolidate. MCP is an open standard (USB-C for AI) that connects AI applications to external systems, solving the M×N integration problem. It has three participants, two layers, two transports, three server primitives, and three client primitives — internalize those numbers and the rest follows.
| Dimension | The set |
|---|---|
| Participants (3) | Host (app) · Client (one per server) · Server (provides context) |
| Layers (2) | Data layer (JSON-RPC 2.0, lifecycle, primitives) · Transport layer |
| Transports (2) | stdio (local) · Streamable HTTP (remote) |
| Server primitives (3) | Tools (model) · Resources (app) · Prompts (user) |
| Client primitives (3) | Sampling · Elicitation · Logging |
The entire mental model of MCP in five numbers: 3 participants, 2 layers, 2 transports, 3 + 3 primitives.
High-Yield Facts to Remember
- •Control model: Tools = model-controlled, Resources = application-controlled, Prompts = user-controlled. This single distinction answers a huge share of questions.
- •Methods: tools/list + tools/call · resources/list (+ templates/list) + resources/read · prompts/list + prompts/get · initialize + notifications/initialized.
- •Transports: only stdio and Streamable HTTP. SSE is a streaming feature inside Streamable HTTP, not a separate transport.
- •Auth: OAuth 2.1 for HTTP transports; stdio uses env credentials. Validate token audience; never pass tokens through; use PKCE.
- •SDK: @mcp.tool() / @mcp.resource(uri) / @mcp.prompt(); type hints generate schemas; mcp.run(transport=...); test with `mcp dev`.
The one question that unlocks most decisions
'Who should control this — the model, the app, or the user?' picks your primitive (tool/resource/prompt). 'Local or remote?' picks your transport (stdio/HTTP). Two questions, most of the design decisions.
Common Traps
- 1.Saying MCP replaces tool use — it's complementary (MCP supplies the tools; tool use calls them).
- 2.Calling the client 'the server' or merging host and client — keep Host → Client (one per server) → Server straight.
- 3.Listing SSE or WebSockets as transports — only stdio and Streamable HTTP.
- 4.Forcing data-fetching into a tool when the app already knows it needs the data — that's a resource.
- 5.Forgetting capability negotiation — never call a method for a capability the peer didn't advertise.
- 6.Passing a client's token through to a downstream API — explicitly forbidden (confused deputy).
Watch the controller, not the verb
Many tricky questions hinge on WHO controls a primitive, not what it does. 'Fetch data for the UI' sounds like an action (tool) but is app-controlled data (resource). 'Run a saved workflow' is user-controlled (prompt). Identify the controller first.
Where to Go Next
You now have a complete, accurate mental model of MCP and hands-on patterns for both sides of the protocol. To deepen it: build a small server for a service you actually use, wire it into Claude Desktop, then convert it to Streamable HTTP and add auth. Reading the official specification (version 2025-06-18) will reinforce everything here with the precise wire-level details.
- •Build a real server for a tool/data source you use daily, and run it in Claude Desktop.
- •Convert it from stdio to Streamable HTTP and add OAuth — feel the operational shift firsthand.
- •Explore the official reference servers (filesystem, GitHub, etc.) to see idiomatic implementations.
- •Skim the spec at modelcontextprotocol.io for the exact message schemas behind each primitive.
You've completed the course
From the USB-C analogy to production deployment, you can now explain, build, secure, and operate MCP — and reason confidently about any MCP design decision. Congratulations.
Key Takeaways
- ✓MCP in five numbers: 3 participants (host/client/server), 2 layers (data/transport), 2 transports (stdio/Streamable HTTP), 3 server primitives, 3 client primitives.
- ✓The control model is the master key: Tools = model-controlled, Resources = application-controlled, Prompts = user-controlled.
- ✓Know the methods: tools/list+call, resources/list(+templates)+read, prompts/list+get, initialize + notifications/initialized.
- ✓Two design questions decide most of it: 'who controls this?' (primitive) and 'local or remote?' (transport).
- ✓Avoid the classic traps: MCP ≠ tool use, only two transports (SSE isn't one), respect capability negotiation, and never pass tokens through.
- ✓Deepen it by building a real server, running it in Claude Desktop, converting it to Streamable HTTP with OAuth, and reading the 2025-06-18 spec.
Check Your Understanding
Test what you learned in this lesson.
Q1.Which control mapping is correct for MCP's server primitives?
Q2.How many transports does MCP define, and is SSE one of them?
Q3.Two questions unlock most MCP design decisions. What are they?
Q4.Which is a genuine MCP fact, not a common misconception?
Practice This Lesson