MCP has three core primitives that you’ll use daily: Tools, Resources, and Prompts:

1. Tools are computation. They do work and take parameters.
2. Resources are static context. They’re retrieved, not executed.
3. Prompts are reusable recipes. They encode a good prompt pattern so users don’t need to improvise every time.

Treat tools like API functions with crisp contracts. Define clear parameter names and types. Write a plain-English description that an LLM will match from natural language. The description matters more than the function name; it’s the bridge between how users speak and how your server operates. Resources carry facts: a settings file, a short spec, or a small JSON schema. Keep them small and relevant so you don’t blow past context limits. Prompts are templates others can call; hand them a battle-tested prompt with variables rather than a wall of instructions.

Figure 1-1: Tools, resources, and templates work together to support capable, grounded agents.

Slow down here and make sure you get the shape right. In practice, sloppy parameter schemas and vague descriptions cause tool misfires. Overstuffed resources inflate cost and degrade answers. Weak prompt templates bury the signal in noise. Do the opposite: make tool descriptions specific, keep resources minimal but sufficient, and use prompts to standardize your best instructions across requests. This is the core of predictable behavior under a limited context window.

Hold this mental model: host, client, server. The host runs your agent experience (for example, an editor chat). The client speaks MCP and keeps a one-to-one session with a server. The server exposes tools, resources, and prompts, and talks to your data sources. Over the wire it’s JSON-RPC messages with requests, results, and occasional errors.

The client can be dumb or smart. A smart client includes an LLM so users can type natural language, and the client maps it to tools. A simpler client can still call tools directly, but you lose that natural language routing. Either way, the session is one client to one server, with discovery (list tools/resources/prompts) and then calls.

Figure 1-2: Hosts run clients, clients connect one-to-one with servers, and the transport layer links the two.

This separation pays off: hosts can swap clients or connect to many servers; servers can move from local to remote transports without changing their contract; clients can learn new capabilities at connect time instead of hardcoding endpoints. In practice, you’ll see the wins when you plug a new server into the same host and the client immediately lists it, negotiates features, and starts using it; there’s no bespoke adaptor layer.

Handshake essentials

Anchor your client-server communication on the handshake: initialize then initialized. The client finds a server and sends initialize with its supported features. The server replies with its own capabilities. Then the client sends initialized, ready for business, and normal calls begin. This is your capability negotiation.

Figure 1-3: The client and server exchange initialize and initialized messages before normal communication begins.

Without a handshake, you guess at features and hit avoidable errors. With it, the client knows exactly what’s available and how to behave. The SDKs hide the wire format, but you should still think in these phases: feature exchange first, then usage. It keeps clients honest and lets servers evolve without breaking callers.

In practice, you’ll see things go wrong when you skip this model mentally. Teams hardcode assumptions about transports, tool names, or optional features. Then, the day a server adds or removes support, the client breaks. Keep the handshake as your mental anchor, the quick “are we aligned?” moment before work starts.

Transports and where to run

Pick the right transport up front—for local development, stdio is the simplest. Your server reads stdin/stdout, the client starts the process, and you iterate quickly. For remote use, prefer Streamable HTTP. SSE exists but is being deprecated; keep it running if you must, but plan to migrate.

Streamable HTTP simplifies life: one endpoint and JSON messages by default. SSE often involves separate routes and string payloads that you then parse, plus it’s not as capable. Streamable HTTP is the recommended path forward and aligns with how you already deploy web services.

A practical way to think about it is to start with stdio to build and test locally, then shape your server to also serve Streamable HTTP when you’re ready to deploy. If you’re on SSE today, keep compatibility for existing consumers but add a Streamable HTTP path. You’ll get clearer behavior, fewer moving parts, and an easier time with gateways and auth later.

Under the hood, every transport carries the same JSON-RPC 2.0 messages. Stdio and Streamable HTTP differ in how bytes move, but the payload is the same: requests like tools/list or tools/call, and responses that return either result or error.

Figure 1-4: An example of a JSON-RPC request message from an action like tools/list and a proper response providing a result (success) or an error (failure).

Define the flagship server

With the mental model and the flagship reference server defined, you’re ready to scaffold a minimal Python MCP server and get the handshake working locally. As mentioned, in this book you’ll build a focused Python MCP reference server that exposes two tools, add() and joke(), one resource, and one prompt template. We’ll keep it boring by design. You want a server you can test end-to-end today and extend tomorrow without reshaping the core.

In use, the client can ask for a quick calculation or a Chuck-Norris-style joke, and can fetch a small resource (for example, a short settings JSON). The prompt template provides a reusable recipe for a clean joke or a consistent calculation explanation. We’ll use the following guardrails: validate parameters for add(); make the joke() tool accept a simple topic string; keep the resource small and static; write explicit tool descriptions so the LLM picks them reliably; avoid hidden side effects.