Day 124 · The universal adapter

Model Context Protocol

You will be able to

Explain the N×M integration problem and how a protocol reduces it to N+M
Diagram MCP's participants — host, client, server — and what each owns
Distinguish the three server primitives (tools, resources, prompts) and choose the right one for a capability
Build and run a minimal Python MCP server and connect it to a host

Today's ~120 minutes

Spaced-rep: due cards + the five patterns from memory (D123)	10 min
ELI5 + tech read; mcp-hosts visualizer	20 min
Guided: wire protocol by hand + real SDK server	42 min
Practice: primitive triage + trust review	18 min
Project: docsqa_server.py	22 min
Quiz + flashcards	8 min

Builds on: Day 111 — Tool use & function calling · Day 120 — Agents I — the loop · Day 41 — HTTP & APIs

The analogy

🧸 ELI5⚙ Tech

Before USB, every gadget shipped its own plug, and every computer needed a matching port: N gadgets × M computers = a drawer full of adapters and a lot of gadgets you simply couldn't connect. USB replaced the drawer with one agreement: any device that speaks the standard works with any computer that has the port. Device makers build ONE plug; computer makers build ONE port; N×M melted into N+M.

AI tools had the same drawer problem. Your Day 111 toolbelt was hand-wired to your app: your schemas, your dispatch code. Want those same tools in Claude Desktop? Rewire. In your IDE agent? Rewire again. Every tool provider was soldering custom plugs for every AI app. The Model Context Protocol is the USB moment: a tool provider wraps their capability in an MCP *server* (one plug), and any MCP *host* — Claude Desktop, an IDE, your own agent — can discover and use it through a standard handshake (one port). The host asks "what have you got?", the server answers with a machine-readable menu, and from then on the model can order off that menu. Build your filesystem tools once; every MCP-speaking app can use them forever.

Why this matters on the job

MCP went from Anthropic announcement (late 2024) to industry standard with remarkable speed — Claude, ChatGPT, VS Code, Cursor, and thousands of community servers speak it — because N×M was everyone's cost center. For you it is doubly practical: as an AI engineer you will consume MCP servers (databases, ticketing, browsers) instead of hand-wiring integrations, and as an FDE the sentence "we can expose your internal systems to any AI application through one MCP server" is a deal-shaping capability. It is also fresh interview material: hosts vs clients vs servers, and why tools/resources/prompts are separate primitives, are exactly the questions that reveal whether someone has built with it or only read headlines.

Watch it happen

The universal adapter — N×M integrations become N+M

step 1 / 5

3 AI appschat, IDE, agent→12 custom connectorsN × M→4 systemsfiles, DB, Slack, CRM

✉ every pair hand-wired — and every new tool means N more connectors

The problem before MCP: every AI app that wants every tool writes a CUSTOM integration. 3 apps × 4 tools = 12 bespoke connectors, each with its own bugs.

🎯 Predict modespeed1×

Guided practice

guided 1

The wire protocol by hand — discovery to invocation

20 min

Create mcp_wire.py with the starter code: a toy in-process "server" that dispatches the three JSON-RPC methods, and a "host" that walks the real message sequence — list tools, then call one. No SDK, no processes: the point is to see that MCP is just structured messages, so nothing about it stays magic.
Run it. Read the tools/list response: name, description, inputSchema — recognize Day 111's tool schema, now standardized and *discoverable*. The host learned the menu at runtime; nothing was hard-coded.
Add a second tool to SERVER_TOOLS (e.g. delete_note) and rerun WITHOUT touching the host code. The host picks it up from discovery — that is the N+M economics in one edit.
Make the call fail: request a tool name that doesn't exist and see the JSON-RPC error object come back as data (not a crash) — errors-as-observations again, one protocol layer down.
Note what this toy omits (real framing, transports, capability negotiation, notifications) — the SDK in exercise 2 handles all of it.

🐍 python — editable, runs in your browser

# mcp_wire.py — the MCP message shapes, in-process. SDK does this for real.
import json

NOTES = {"standup": "Daily at 9:30, #eng-sync", "oncall": "Rotation wiki page 4"}

SERVER_TOOLS = {
    "search_notes": {
        "description": "Return titles of notes whose text contains the query.",
        "inputSchema": {"type": "object",
                        "properties": {"query": {"type": "string"}},
                        "required": ["query"]},
        "fn": lambda args: [t for t, x in NOTES.items()
                            if args["query"].lower() in x.lower()],
    },
    "add_note": {
        "description": "Store a note under a title. Overwrites existing.",
        "inputSchema": {"type": "object",
                        "properties": {"title": {"type": "string"},
                                       "text": {"type": "string"}},
                        "required": ["title", "text"]},
        "fn": lambda args: NOTES.update({args["title"]: args["text"]}) or "saved",
    },
}

def server_handle(msg):                       # the server side of the wire
    method, mid = msg.get("method"), msg.get("id")
    if method == "tools/list":
        tools = [{"name": n, "description": t["description"],
                  "inputSchema": t["inputSchema"]} for n, t in SERVER_TOOLS.items()]
        return {"jsonrpc": "2.0", "id": mid, "result": {"tools": tools}}
    if method == "tools/call":
        name = msg["params"]["name"]
        if name not in SERVER_TOOLS:
            return {"jsonrpc": "2.0", "id": mid,
                    "error": {"code": -32602, "message": f"unknown tool: {name}"}}
        out = SERVER_TOOLS[name]["fn"](msg["params"]["arguments"])
        return {"jsonrpc": "2.0", "id": mid,
                "result": {"content": [{"type": "text", "text": json.dumps(out)}]}}
    return {"jsonrpc": "2.0", "id": mid, "error": {"code": -32601, "message": "no such method"}}

# --- the host walks the sequence ---
listing = server_handle({"jsonrpc": "2.0", "id": 1, "method": "tools/list"})
print("discovered tools:")
for t in listing["result"]["tools"]:
    print("  -", t["name"], "|", t["description"])

call = {"jsonrpc": "2.0", "id": 2, "method": "tools/call",
        "params": {"name": "search_notes", "arguments": {"query": "rotation"}}}
print("\ncall:", json.dumps(call["params"]))
print("resp:", server_handle(call)["result"]["content"][0]["text"])

bad = server_handle({"jsonrpc": "2.0", "id": 3, "method": "tools/call",
                     "params": {"name": "drop_database", "arguments": {}}})
print("\nbad call ->", bad["error"]["message"], "(an error object, not a crash)")

Ctrl/⌘+Enter runs · Tab indents · numpy/pandas/sklearn auto-load on import (torch and network calls need a local run)

guided 2

A real MCP server with the Python SDK

22 min

This exercise needs a local environment (pip install "mcp[cli]"); browser-only today means read every line, map it onto exercise 1, and run it tonight.

Create notes_server.py with the starter code: the same notes capability, now as a real MCP server via FastMCP. Note how little is left: decorators register tools, type hints become the inputSchema, docstrings become the descriptions the model reads — everything you hand-wrote in exercise 1, generated.
Test it with the MCP Inspector: mcp dev notes_server.py opens a browser UI where you can list and invoke your tools — you are being the host, manually.
Connect it to a real host: add the printed config block to Claude Desktop's config file (or any MCP-speaking host), restart, and ask the assistant "what's in my oncall note?" Watch it discover and call YOUR server — with the host's consent prompt in between (that approval UX is the security model working).
Add a resource: get_note exposed at notes://{title} — data the HOST can load, distinct from tools the MODEL calls. Re-run the Inspector and find it under resources, not tools. Say out loud who decides for each primitive: model / application / user.

🐍 python — editable, runs in your browser

# notes_server.py — a real MCP server. Local: pip install "mcp[cli]"
# Run in dev UI:  mcp dev notes_server.py
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("nimbus-notes")

NOTES = {"standup": "Daily at 9:30, #eng-sync", "oncall": "Rotation wiki page 4"}

@mcp.tool()
def search_notes(query: str) -> list[str]:
    """Return titles of notes whose text contains the query (case-insensitive)."""
    return [t for t, x in NOTES.items() if query.lower() in x.lower()]

@mcp.tool()
def add_note(title: str, text: str) -> str:
    """Store a note under a title. Overwrites any existing note with that title."""
    NOTES[title] = text
    return f"saved note '{title}'"

@mcp.resource("notes://{title}")
def get_note(title: str) -> str:
    """Read one note's full text by title."""
    return NOTES.get(title, "no such note")

if __name__ == "__main__":
    mcp.run(transport="stdio")     # host launches this process, speaks stdin/stdout

# Claude Desktop config (claude_desktop_config.json) to connect a host:
# {"mcpServers": {"nimbus-notes": {
#     "command": "python", "args": ["/absolute/path/to/notes_server.py"]}}}

Ctrl/⌘+Enter runs · Tab indents · numpy/pandas/sklearn auto-load on import (torch and network calls need a local run)

On your own

Primitive triage + the trust review

18 min

Part 1 — for each capability, pick tool, resource, or prompt, with one line of reasoning: (a) run a read-only SQL query the model composes; (b) the database's schema, so the model writes correct SQL; (c) a user-invoked "/weekly-report" template; (d) create a Jira ticket; (e) the contents of the currently open file in an editor; (f) redact PII from pasted text on demand.

Part 2 — you are evaluating a community MCP server for your team ("connects to your CRM!"). Write the five-question security review you'd run before allowing it: think about what enters the model's context from the server, what credentials the server holds, and what its tools can do. Compare with: (1) what do its tool descriptions and results inject into context? (2) what scopes/credentials does it demand — least privilege? (3) which tools are destructive and does the host gate them? (4) is the code auditable and the version pinnable? (5) where does data flow — does ticket text leave your boundary?

Answers part 1: a tool; b resource; c prompt; d tool (destructive — flag for approval); e resource; f tool (or prompt if user-invoked by convention).

Ship before you stop

An MCP server for the capstone corpus

Build docsqa_server.py: an MCP server exposing your capstone (Day 119) to any host. Tools: search_docs(query, k=3) calling your hybrid retriever and returning chunks with citations, and answer_question(question) returning your grounded answer() output (text, citations, refused). Resource: corpus://{doc_id} serving raw document text for host-side context. Write model-facing docstrings with the same care as Day 111 schemas — they are the only manual the model gets. Verify with mcp dev (screenshot or transcript in the README), and add a security note: why answer_question is safe to auto-approve but a hypothetical reindex_corpus tool would need an approval gate. Commit to the capstone repo — this is the capstone's second interface (CLI, now MCP; API comes Day 148).

Rubric — check what you completed (0/6)

Both tools wrap the real Day 119 modules, not reimplementationssearch_docs returns chunk text + resolvable citations; answer_question preserves the refusal pathResource serves raw docs by id at a corpus:// URIDocstrings/type hints produce clean discoverable schemas (verified in Inspector)README records the Inspector verification and the approval-gate security noteCommitted to the capstone repo

Common mistakes & misconceptions

Confusing the participants: the host is the app, the client is the per-server connection the host owns, the server exposes capabilities. One host, many clients, each pinned to one server.
Exposing everything as tools. Data the application should load is a resource; user-invoked templates are prompts. The primitive encodes who decides — model, app, or user.
Writing lazy tool descriptions. Discovery means the model chooses tools by description alone; vague descriptions produce wrong tool choices at runtime, same as Day 111.
Treating community servers as safe because the protocol is standard. The protocol standardizes the wire, not the trustworthiness — server output is injected context; review, pin, least-privilege.
Hard-coding against one server's tool list. The entire point is runtime discovery; enumerate tools/list at connect time and handle the menu changing.
Building a bespoke REST API where an MCP server was the answer. If the consumer is an AI app — yours or a customer's — MCP gets you every host for free; that is the N+M argument in reverse.

Knowledge check

Q1. MCP turns the integration problem from N×M into N+M because…

Q2. A DB's schema should be exposed to the model as which primitive, and why?

Q3. Why is a malicious MCP server a prompt-injection vector?

Go deeper — curated resources

docsMCP — What is the Model Context Protocol? (intro) ↗15 min docsMCP — Architecture overview (participants, primitives, transports) ↗30 min docsMCP — Build an MCP server (Python quickstart) ↗30 min

If you have a third hour

MCP server concepts — tools/resources/prompts in depth ↗ — The full primitive semantics, including annotations for destructive vs read-only tools — the metadata Day 125's approval gates key off.

Done means

Wire lab run; second tool discovered without host changes
notes_server.py verified in Inspector (or fully traced if browser-only, run scheduled)
All six primitive-triage calls correct; security review written
docsqa_server.py committed to the capstone repo with README verification
Quiz ≥ 2/3

How this connects

← Back: Day 111's tool schemas and descriptions are exactly what MCP standardizes and makes discoverable; Day 41's HTTP/JSON-RPC literacy is the transport layer; Day 120's loop is what lives inside every MCP host.

Forward →: Day 125 builds the approval gates MCP's consent model expects around destructive tools. Day 132 weaponizes (then defends) the injection vector you named today, and Day 169 pitches MCP as the enterprise integration story.