Introduction to MCP

• QuestionWhat is "Classify tool / resource / prompt"?Tap to revealAnswerTools are what the model decides to use, resources are data the app/user attaches, prompts are templates the user picks from a menu.
• QuestionIn "Classify tool / resource / prompt", explain:Tap to revealAnswerThree primitives, defined by *invoker*: tools (model), resources (app/user), prompts (user).
• QuestionIn "Classify tool / resource / prompt", explain:Tap to revealAnswerTools = executable / side-effecting. Resources = read-only data references. Prompts = reusable templates.
• QuestionIn "Classify tool / resource / prompt", explain:Tap to revealAnswerMisclassification has real costs: tool clutter, hidden workflows, user confusion.
• QuestionIn "Classify tool / resource / prompt", explain:Tap to revealAnswerSampling and roots are emerging additions but not the focus of D3 questions.
• QuestionAnalogy for "Classify tool / resource / prompt":Tap to revealAnswerImagine a kitchen. Tools are the appliances (the chef decides when to use them). Resources are the ingredients in the pantry (the kitchen owner decides what's stocked). Prompts are the recipes pinned to the wall (the customer picks which one).
• QuestionWhat is "stdio vs Streamable HTTP"?Tap to revealAnswerstdio is for tools running on the same machine as one user. Streamable HTTP is for servers serving multiple users or running remotely.
• QuestionIn "stdio vs Streamable HTTP", explain:Tap to revealAnswerTwo official transports. Closed list. Anything else is wrong.
• QuestionIn "stdio vs Streamable HTTP", explain:Tap to revealAnswerstdio = local single-user. Server is a child process; lifecycle bound to client.
• QuestionIn "stdio vs Streamable HTTP", explain:Tap to revealAnswerStreamable HTTP = remote / multi-user. HTTP endpoint, streaming response, auth at transport.
• QuestionIn "stdio vs Streamable HTTP", explain:Tap to revealAnswerOlder name for Streamable HTTP: 'HTTP+SSE' — same thing, may appear in older question banks.
• QuestionAnalogy for "stdio vs Streamable HTTP":Tap to revealAnswerstdio is like a personal assistant in the same room as you (no doorbell, no shared schedule). Streamable HTTP is like a receptionist serving the whole office (door, schedule, badge to enter).
• QuestionWhat is "Reject non-MCP transports"?Tap to revealAnswerMCP only has two transports: stdio and Streamable HTTP. WebSockets and gRPC are common in other systems but not MCP.
• QuestionIn "Reject non-MCP transports", explain:Tap to revealAnswerMCP transports: stdio, Streamable HTTP. Closed list.
• QuestionIn "Reject non-MCP transports", explain:Tap to revealAnswerWebSockets, gRPC, named pipes, raw TCP, message queues are *not* MCP.
• QuestionIn "Reject non-MCP transports", explain:Tap to revealAnswerStreamable HTTP already streams (via SSE) — 'streaming' is not a reason to reach outside the spec.
• QuestionIn "Reject non-MCP transports", explain:Tap to revealAnswerOlder name for Streamable HTTP: HTTP+SSE.
• QuestionAnalogy for "Reject non-MCP transports":Tap to revealAnswerIt's like asking 'which countries are in this trade agreement?' There's a list. Other countries might be reasonable trading partners but they're not in the agreement.
• QuestionWhat is "Diagnose wrong-tool-pick to description"?Tap to revealAnswerIf the model keeps picking the wrong tool, fix the descriptions before anything else. Say what each tool does, what it operates on, when to use it, and what it doesn't handle.
• QuestionIn "Diagnose wrong-tool-pick to description", explain:Tap to revealAnswerWrong-tool-pick → check the description first.
• QuestionIn "Diagnose wrong-tool-pick to description", explain:Tap to revealAnswerGood description = operation + operand + when-to-use + when-NOT-to-use.
• QuestionIn "Diagnose wrong-tool-pick to description", explain:Tap to revealAnswerDifferentiation between neighbouring tools is the most-missed component.
• QuestionIn "Diagnose wrong-tool-pick to description", explain:Tap to revealAnswerRename / system-prompt nudges / tool merges are second-order fixes.
• QuestionAnalogy for "Diagnose wrong-tool-pick to description":Tap to revealAnswerIt's like having two job titles in an org: 'Frontend Engineer' and 'UI Engineer'. If their job descriptions are vague, requests get routed badly. Tighten the descriptions and the routing fixes itself.
• QuestionWhat is "Server-per-capability vs monolith"?Tap to revealAnswerBuild one MCP server per integration (git, Jira, Postgres). Don't bundle them into one giant company server.
• QuestionIn "Server-per-capability vs monolith", explain:Tap to revealAnswerServer-per-capability is the default. Monolith is the antipattern.
• QuestionIn "Server-per-capability vs monolith", explain:Tap to revealAnswerTool list bloat reduces model selection accuracy at ~10+ tools.
• QuestionIn "Server-per-capability vs monolith", explain:Tap to revealAnswerIndependent versioning, smaller blast radius, finer-grained auth.
• QuestionIn "Server-per-capability vs monolith", explain:Tap to revealAnswerClients compose multiple servers concurrently — there's no need to bundle.
• QuestionAnalogy for "Server-per-capability vs monolith":Tap to revealAnswerLike microservices vs. a monolith: small, focused services compose better than one giant service. Same principle here.
• QuestionWhat is "Auth at transport, not in tool input"?Tap to revealAnswerAuth happens when the client connects to the server, not in the parameters of each tool call. Don't put api_key fields in tool schemas.
• QuestionIn "Auth at transport, not in tool input", explain:Tap to revealAnswerAuth lives at the transport layer (Streamable HTTP: OAuth/headers; stdio: parent process).
• QuestionIn "Auth at transport, not in tool input", explain:Tap to revealAnswerTool inputs carry operation parameters only, never identity/credentials.
• QuestionIn "Auth at transport, not in tool input", explain:Tap to revealAnswerCredentials in tool inputs leak into the model's context — log/trace/cache risk.
• QuestionIn "Auth at transport, not in tool input", explain:Tap to revealAnswerSchema fields named api_key / auth_token / bearer in tool inputs are smells.
• QuestionAnalogy for "Auth at transport, not in tool input":Tap to revealAnswerIt's like showing your badge at the office door (transport auth) versus carrying it into every meeting and reading it aloud (auth in tool input). One leaks; one doesn't.

1. 1Summarise the core idea

   Analyse~10 min

   In your own words, summarise the central idea of "Classify tool / resource / prompt". Aim for one paragraph, no jargon you haven't earned.

   Done when: A non-expert could read your paragraph and explain it back to you.

   Re-read the source concept

2. 2Solve it to a real situation

   Apply~15 min

   Find a real situation from your own work / life where "Auth at transport, not in tool input" applies. Solve the idea — describe the situation, the move you'd make, and the alternative you considered first.

   Done when: You can name a specific situation (not a hypothetical), state your move, and explain the trade-off in one paragraph.

   Re-read the source concept

3. 3Teach it back

   Evaluate~5 min

   Pick someone (a colleague, a peer, a rubber duck) and explain the section to them in under 5 minutes. Use your own example, not the one from the lesson.

   Done when: Your listener can repeat the core idea + the trade-off back to you without prompting.

Why this matters. Reading + quizzing prove recall; applying it in a real situation is the only evidence of transfer. Treat at least one of these as non-negotiable before you move on.