Letting a server borrow the client's model
Sampling flips the usual direction: instead of the client calling the server, the server asks the client to run an LLM completion on its behalf. The server sends a sampling request with messages; the client runs it and returns the generated text.
Key concept · Agentic servers, with the client in control
Sampling lets a server do its own reasoning — summarize, classify, decide a next step — without shipping its own model or API key; it leans on whatever model the host already has. Crucially, the client stays in control: it can review the request, choose or constrain the model, and approve before running (a human-in-the-loop point). This is what makes MCP servers genuinely agentic rather than just passive tool endpoints — while keeping cost and trust decisions on the client side.
Progress reports and operating boundaries
Two features make long-running, well-scoped servers practical: notifications (one-way status messages) and roots (a declared boundary for where a server may work).
Key concept · Log and progress notifications
Notifications are one-way messages — no response expected — that a server sends the client mid-operation. Logging notifications carry messages at severity levels (debug, info, warning, error) for visibility into what the server is doing. Progress notifications report advancement on a long task: the client includes a progress token with its request, and the server sends updates (progress out of an optional total) so the client can show a live progress bar instead of a frozen spinner.
Key concept · Roots — the server's sandbox
Roots are filesystem paths or URIs the client declares to tell a server the boundary it should operate within — for example, "you may work inside this project folder." The server can query the roots and confine its file operations to them, and the client can update the set (with a notification) as scope changes. Roots are a scoping-and-safety mechanism: the client, not the server, decides how far the server's reach extends.
How messages travel — and where servers run
MCP is transport-agnostic, but the two transports it defines determine whether a server runs locally beside your app or remotely over the network.
Key concept · JSON-RPC message types
Under the hood, MCP speaks JSON-RPC, with three message shapes: requests (carry an id and expect a response), responses (return a result or an error for that id), and notifications (no id, no response — the one-way messages above). Everything — listing tools, calling a tool, sampling, progress — is one of these three.
| Transport | How it works | Best for |
|---|---|---|
| STDIO | The server runs as a local subprocess; client and server talk over stdin/stdout. No network. | Local, single-user servers (file access, local tools). |
| StreamableHTTP | Remote server over HTTP; supports streaming responses (server-sent events) from a single endpoint. | Hosted, shared, or remote servers reached over the network. |
Key concept · State and StreamableHTTP
StreamableHTTP can run stateful or stateless. Stateful servers issue a session id (returned on initialize, sent on subsequent requests) so a server can keep per-client context across calls and even resume a stream; stateless servers treat each request independently, which scales more simply behind load balancers. Choosing between them — and between STDIO and StreamableHTTP — is the main deployment decision for a production MCP server.
Chapter 26 quiz
Fourteen questions on sampling, notifications, roots, and transports. Answer first, then expand Show answer.
Part A · Multiple choice
What does sampling let an MCP server do?
- A Ask the client to run an LLM completion on its behalf
- B Bill the user directly
- C Bypass the client
- D Train a model
Show answer
A. So the server reasons without its own model/API key.
During sampling, who stays in control?
- A The client — it can review, choose the model, and approve
- B The server alone
- C No one
- D The end user's browser
Show answer
A. A human-in-the-loop / trust point.
A notification is:
- A A one-way message with no response expected
- B A request that returns a result
- C A tool call
- D A resource
Show answer
A. Used for logs and progress.
Progress notifications rely on:
- A A progress token the client includes, with progress/total updates
- B A new API key
- C A larger model
- D Nothing
Show answer
A. So the client can show a live progress bar.
Roots are:
- A Client-declared paths/URIs bounding where a server may operate
- B The server's tools
- C A transport
- D A model list
Show answer
A. A scoping-and-safety mechanism.
MCP's wire protocol is:
- A JSON-RPC (requests, responses, notifications)
- B SOAP
- C GraphQL
- D Plain text
Show answer
A.
The STDIO transport is best for:
- A Local servers running as a subprocess (stdin/stdout, no network)
- B Remote hosted servers
- C Streaming to browsers
- D Training
Show answer
A.
StreamableHTTP is best for:
- A Remote servers over HTTP, with streaming support
- B Local-only tools
- C Offline use
- D Nothing
Show answer
A.
Part B · True or false
Sampling makes MCP servers agentic while keeping cost/trust decisions on the client.
Show answer
True.
Logging notifications carry severity levels like debug, info, warning, and error.
Show answer
True.
The server, not the client, decides its own roots.
Show answer
False. The client declares roots; the server confines itself to them.
A stateful StreamableHTTP server uses a session id to keep per-client context.
Show answer
True. Stateless servers treat each request independently.
MCP is locked to one transport.
Show answer
False. It's transport-agnostic — STDIO or StreamableHTTP.
Part C · Short answer
Name the three JSON-RPC message types and the two MCP transports.
Show answer
Messages: requests, responses, notifications. Transports: STDIO and StreamableHTTP.