A standard for connecting AI to the world
The Model Context Protocol is an open standard for how AI applications connect to external tools and data — often called "USB-C for AI." Without it, every app wires up every integration by hand (an M×N problem); with it, a tool written once as a server works with any MCP-speaking client (M+N).
Key concept · Architecture, and where the burden moves
MCP has a host (the app running the model), a client (manages one connection), and a server (exposes capabilities). Its big shift: the burden of defining and executing tools moves off your agent code and into the server, so integrations become reusable and swappable. Communication is transport-agnostic — the same protocol runs over a local process or a remote HTTP connection — and it uses structured JSON-RPC messages between client and server. The payoff is dynamic discovery: a client asks a server what it offers at runtime, so tools can change without touching the app.
Tools, resources, and prompts
A server exposes three kinds of capability. Building one means defining these and testing them with the server inspector, a dev tool that connects to your server so you can exercise each capability before wiring up a real client.
| Capability | What it is | Controlled by |
|---|---|---|
| Tools | Actions the model can invoke (functions with a name, description, and input schema). | Model-driven — Claude decides when to call. |
| Resources | Data/content the client can read (files, records, documents), addressed by URI. | App-driven — the application decides what to load. |
| Prompts | Reusable prompt templates the server offers. | User-driven — surfaced for the user to pick. |
Key concept · Defining tools with MCP
In an MCP server you register a tool with its name, a clear description (what Claude matches against), and a JSON input schema; your handler runs the logic and returns a result. Because the server owns the definition and execution, the same tool is instantly available to any client that connects — you're not re-implementing it per app. The inspector lets you call the tool directly and confirm it behaves before a model is ever in the loop.
Discovering and using a server
The other half is the client — the code that connects to a server, discovers its capabilities, and makes them available to the model.
Key concept · Implementing a client, and using resources and prompts
A client connects to a server over a transport, then lists what it offers (tools, resources, prompts) — dynamic discovery in action. From there: it exposes the server's tools to Claude so they join the agent loop; it can access resources by URI and feed their content into context (app-driven — you choose what to pull in); and it can retrieve the server's prompts and surface them to the user. The course closes by reviewing how host, client, and server fit together — the mental model you carry into the advanced course.
Chapter 25 quiz
Fourteen questions on MCP architecture, servers, and clients. Answer first, then expand Show answer.
Part A · Multiple choice
MCP is:
- A An open standard for connecting AI apps to external tools and data
- B A new Claude model
- C A billing system
- D A prompt style
Show answer
A. "USB-C for AI."
What problem does MCP solve?
- A The M×N integration problem — reusable servers make it M+N
- B Slow models
- C Expensive tokens
- D Nothing
Show answer
A. Write a tool once; any client can use it.
The three roles in MCP are:
- A Host, client, server
- B Model, index, cache
- C User, admin, guest
- D Chat, Cowork, Code
Show answer
A.
What three capabilities does an MCP server expose?
- A Tools, resources, prompts
- B Models, keys, logs
- C HTML, CSS, JS
- D Read, write, delete
Show answer
A.
MCP tools are:
- A Actions the model can invoke (name, description, input schema)
- B Data the client reads
- C Prompt templates
- D API keys
Show answer
A. Model-driven — Claude decides when to call.
MCP resources are:
- A Data/content the client can read, addressed by URI
- B Actions Claude executes
- C A transport
- D A model
Show answer
A. App-driven — the application decides what to load.
What tool lets you exercise a server before wiring a real client?
- A The server inspector
- B The Console
- C git diff
- D A linter
Show answer
A.
Part B · True or false
MCP shifts the burden of defining and executing tools off your agent code and into the server.
Show answer
True. Making integrations reusable and swappable.
MCP is tied to a single transport mechanism.
Show answer
False. It's transport-agnostic — local process or remote HTTP.
A client discovers a server's capabilities at runtime.
Show answer
True. Dynamic discovery — tools can change without touching the app.
A tool written for one MCP client only works with that client.
Show answer
False. Because it's a standard, any MCP-speaking client can use it.
Prompts exposed by a server are reusable templates surfaced for the user.
Show answer
True. User-driven, versus model-driven tools.
Part C · Short answer
What does a client do first after connecting to a server?
Show answer
Lists/discovers the server's capabilities (tools, resources, prompts).
Match each capability to who drives it: tools, resources, prompts.
Show answer
Tools — model-driven; resources — app-driven; prompts — user-driven.