"front"	"back"	"tags"
"What does MCP stand for and what is it?"	"Model Context Protocol. A JSON-RPC 2.0 wire protocol for exchanging tools, resources, and prompts between agent clients and tool servers. The protocol that externalizes hardcoded tool registries into discoverable services."	"c1::dd22::recall"
"Name the three MCP primitives and who initiates each."	"Tool (the model calls it), Resource (the user/client reads it), Prompt (the user invokes it). Three primitives, three trust boundaries, three lifecycles."	"c1::dd22::recall"
"What are the two MCP transports?"	"stdio (local — the agent spawns the server as a subprocess, communicates over stdin/stdout) and HTTP+SSE (remote — the agent connects over HTTP, receives updates via Server-Sent Events). Same protocol, different pipes."	"c1::dd22::recall"
"What message envelope does MCP use?"	"JSON-RPC 2.0. Three message types: request (has id, expects reply), response (carries result or error for that id), notification (no id, no reply — fire and forget)."	"c1::dd22::recall"
"What are the four phases of the MCP server lifecycle?"	"1. Initialize (exchange protocol version + capabilities), 2. Initialized notification (handshake confirmation), 3. Message loop (tools/list, tools/call, resources/read), 4. Graceful shutdown (drain in-flight, close handles, exit zero)."	"c1::dd22::recall"
"What is the single most common MCP server bug?"	"Logging to stdout on a stdio transport. stdout IS the protocol stream — a console.log corrupts it, the client gets a JSON parse error, disconnects, reconnects in a loop. Fix: stderr only, always."	"c1::dd22::recall"
"What is capability negotiation and what is its rule?"	"The initialize handshake where client and server exchange what features they support. The rule: the session may only use the INTERSECTION of client-offered and server-offered features. Only use what both sides advertised."	"c1::dd22::recall"
"Why is additionalProperties: false a security control, not just a schema nicety?"	"Without it, a steered model can inject unexpected fields into tool arguments — e.g., adding a 'bcc' field to a send_email tool. Forbidding extra properties closes this injection vector at the schema level."	"c1::dd22::analysis"
"What are the three classes of tool-call failure and why must they be distinguished?"	"Class 1: unknown tool (model recovery: stop calling it). Class 2: validation failure (model recovery: retry with fixed args). Class 3: execution failure (model recovery: retry or report). Each needs a different isError payload so the model knows which recovery path to take."	"c1::dd22::analysis"
"Why are tools, resources, and prompts on different trust boundaries? What is the bug?"	"Tools: model initiates, input is untrusted, must be schema-validated. Resources: user/client initiates, data is semi-trusted. Prompts: user initiates, template is trusted (server-authored). The bug: exposing as a tool something that should be a resource — the model can now call it autonomously, including when steered to."	"c1::dd22::analysis"
"Why does the client send an 'initialized' notification before any other request?"	"It's a synchronization point confirming the capability handshake is complete. Before it, the contract (which messages are valid for this session) is not in force. Sending tools/call before initialized is the most common integration bug — the server rejects it."	"c1::dd22::application"
"A client offers 'roots' capability but the server didn't advertise roots support. What happens?"	"The client must not query roots. The session may only use the intersection. A capability offered by only one side is forbidden for this session — the client degrades gracefully, using whatever subset both support."	"c1::dd22::application"
"Your agent subscribes to a live log resource and the context fills with update noise. What went wrong and how do you fix it?"	"Subscription flood: a volatile resource generates a notification per change. Fix: subscribe narrowly to specific URIs (not wildcards), debounce on the server (coalesce to max one per second), unsubscribe aggressively when the model is done."	"c1::dd22::application"
"You upgrade an MCP server and the model's calls start failing validation. What happened and what's the fix?"	"Schema drift: the tool's input schema changed in the new version, but the model is producing arguments for the old schema. Fix: namespace tools by server (acme-crm__search_tickets), pin server versions in the registry, treat schema changes as breaking (version the tool name or re-test the agent)."	"c1::dd22::application"
"Why must the server re-validate arguments against the schema on every call, even though the model 'knows' the schema?"	"The model is not a reliable validator — it will produce extra fields, wrong types, missing required fields, especially under adversarial steering. The client may not have validated either. The schema is the server's defense boundary; trusting the model or the client to validate is an unenforced boundary."	"c1::dd22::analysis"
"What is the registry pattern and when do you need it?"	"A service or directory listing available MCP servers. Static config (a file) works for up to ~5-8 servers; beyond that you graduate to a dynamic registry that enables 'vendor ships a server, agent picks it up without redeploy.' The registry is what makes MCP a platform primitive, not just an integration pattern."	"c1::dd22::application"
"How does MCP relate to Pi (DD-01) and to Course 4 Module E07?"	"Pi has four hardcoded tools — the personal-harness pole. MCP externalizes tools into discoverable services — the platform turn. E07 builds the fleet: registry-as-service, multi-tenancy, policy layer, audit log. The arc: hardcoded → single server → fleet."	"c1::dd22::analysis"
"Why are tool descriptions instructions to the model, not documentation?"	"The description determines WHEN the model calls the tool and HOW it formats arguments. A vague description ('searches tickets') produces worse calls than a precise one ('searches support tickets by keyword, returns up to 50 newest-first, use status to filter'). Write descriptions like prompts, not like docstrings."	"c1::dd22::application"
"What production patterns must a remote (HTTP+SSE) MCP server implement beyond the protocol itself?"	"Connection pooling (one backend connection per agent session is a leak), health checks (separate endpoint outside the protocol), rate limiting per client (a runaway model calling a paid API tool costs real money), idempotency keys for side-effecting tools (network retries must not double-charge), structured logging to stderr."	"c1::dd22::analysis"
"What is the difference between a tool and a resource in terms of who can trigger the action?"	"A tool is model-invoked — the model decides to call it, so the input is untrusted and must be safe to execute with arbitrary conforming arguments. A resource is user/client-invoked — the model cannot autonomously read it; the user opts in. This asymmetry is why they are separate primitives."	"c1::dd22::analysis"
"Why does MCP reuse JSON-RPC 2.0 instead of inventing a new protocol?"	"Because the problem is the same one LSP (Language Server Protocol) and DAP (Debug Adapter Protocol) already solved: two processes, one with capabilities the other wants, needing a structured conversation over a pipe. Reusing JSON-RPC means mature tooling, known semantics, and no novelty cost for integrators."	"c1::dd22::analysis"
"What happens if a server advertises tools.listChanged in initialize but the client didn't offer that capability?"	"The server should not send tools/list_changed notifications. The session uses only the intersection. Advertising a capability the other side can't handle is harmless but misleading — advertise what works, omit what doesn't."	"c1::dd22::application"