Domain 2 · Tool Design & MCP

MCP architecture

The Model Context Protocol is an open standard that lets any AI app plug into any tool or data source through one common socket — like USB-C did for chargers. Instead of writing custom glue for every integration, you run an MCP server that exposes tools, resources, and prompts, and any MCP client (Claude Desktop, Claude Code, your app) can use them.

host / client / servertools resourcesprompts stdio vs HTTP

Explain like I'm 10

Remember when every phone had a different charger and nothing fit anything? Then USB-C came and one plug worked everywhere. MCP is USB-C for AI. Before it, hooking Claude up to your files, your database, or GitHub each needed its own special cable. With MCP, anyone builds one plug (a server) and any AI app can use it. Build it once, plug in anywhere.

Host, client, server — who's who

MCP has three roles. Hover the diagram pieces. The key insight: the server is reusable across every host, and the host can connect many servers at once. That many-to-many web is what makes the ecosystem compound.

Hover a box to see its role.

The stack in 3-D — drag to orbit

The same architecture as free-orbit layers: the host on top, its client connector beneath, your reusable servers below, and the real systems they wrap at the base. Fly around it — the many-to-many shape (one host, many servers) is easiest to feel in 3-D.

Rendered by the zero-dependency WebGL orbit renderer — same scene data as the site's isometric engine.

What a server can expose

Primitive	What it is	Example
Tools	Actions the model can call (model-controlled) — same anatomy as native tools.	`create_issue`, `run_query`
Resources	Read-only data the host can attach as context (app-controlled).	a file, a DB row, a wiki page
Prompts	Reusable prompt templates a user can invoke (user-controlled).	a "/summarize-PR" template

How it connects: transports

A client talks to a server over a transport. Two common ones: stdio — the server runs as a local subprocess, ideal for local tools (your filesystem, a local DB); and streamable HTTP — the server runs remotely, ideal for shared/hosted integrations with auth. Choosing the transport is a deployment decision: local-and-private → stdio; shared-and-networked → HTTP.

Exam trap: MCP doesn't replace good tool design — an MCP tool with a vague description fails exactly like a native one (see Anatomy of a tool). MCP solves distribution (one server, many hosts), not quality. Also know the direction: tools are model-controlled, resources are app-controlled, prompts are user-controlled.

Takeaways: MCP = an open standard ("USB-C for AI") with three roles — host (the app), client (the connector inside it), server (your reusable integration). Servers expose tools (callable), resources (attachable data), and prompts (templates), over stdio (local) or HTTP (remote). Build a server once; every MCP host can use it. It standardises connection, not tool quality.

Curated companion: modelcontextprotocol.io — Introduction · Anthropic — MCP.