Server primitives: tools, resources and prompts
Server primitives: tools, resources, and prompts
Level: from scratch — no prior experience needed. If you're coming from the previous lesson, you already know what an MCP server is. Now we're going to open the box and see what's inside. Watch the video above and follow this guide at your own pace.
In Module 0 we learned that a server is the program that exposes capabilities to an AI via MCP. But what kind of capabilities? A server doesn't expose "just anything": it offers exactly three types of things, and we call those three types primitives. A primitive is simply a "basic building block" of the protocol. Understanding these three means understanding almost everything a server can do.
What you'll learn
- The three primitives that every MCP server exposes: tools, resources, and prompts.
- The most important idea of the module: each primitive has a different controller (the model, the application, or the user). That separation is the point.
- The protocol methods that correspond to each one (the
.../list,.../call, etc.). - A simple example of each primitive so it doesn't stay purely theoretical.
1. Tools — controlled by the model
A tool is a function that the server makes available and that the LLM decides to invoke on its own when it thinks it needs it. They are actions: they do something. The model reads the list of available tools, picks one, and runs it.
- Who's in charge? The model. That's why we say tools are model-controlled.
- Protocol methods:
tools/list(request the list of tools) andtools/call(run one). - Beginner example: a tool
create_event(date, title)in your calendar. You write to the AI "schedule a meeting on Tuesday at 10"; the model, on its own, decides to call that tool with that data. You didn't press any button: the model decided.
2. Resources — controlled by the application
A resource is read-only data: files, images, JSON, a piece of text. It doesn't run
actions; it only delivers information to provide context. Each resource is identified by a
URI (a unique address, similar to a web address, for example file:///notes.txt).
- Who's in charge? The application (the host decides which resources to load and when). They are application-controlled.
- Protocol methods:
resources/list(what resources exist) andresources/read(read one). - Beginner example: the file
return-policy.mdof a store. The application passes it to the model as context so it answers well, but the resource itself does nothing: it only gets read.
3. Prompts (templates) — controlled by the user
A prompt is a reusable template of instructions, designed so that the user
triggers it on purpose. The typical case is a slash command (a command that starts with
/) that assembles a ready-made message.
- Who's in charge? The user. They are user-controlled: you choose to use them.
- Protocol methods:
prompts/list(what templates exist) andprompts/get(fetch one). - Beginner example: a prompt
/summarize-meetingthat, when invoked, assembles a message like "Summarize this transcript in 5 points and a task list". You choose it; neither the model nor the application decides it.
The key idea: three different controllers
Notice the pattern. The three primitives differ above all by who decides to use them:
- Tools → the model decides (automatic actions).
- Resources → the application decides (read-only context).
- Prompts → the user decides (templates on demand).
That separation of control is exactly the design MCP proposes. It's not a minor technical detail: it's what makes a server predictable and safe.
Note for later: tool design is a debated topic among those who build servers. Adding too many tools bloats the model's context and confuses it. How to choose how many and which ones we'll cover in an advanced module — for now, just keep it on your radar.
Key moments in the video
- 10 — Deep dive into the three primitives: tools, resources, and prompts explained one by one. It's the heart of this lesson; watch it with this guide alongside.
Quick glossary
- Primitive: basic building block that an MCP server exposes. There are three.
- Tool: function/action that the model decides to invoke (
tools/list,tools/call). - Resource: read-only data identified by a URI, controlled by the application
(
resources/list,resources/read). - Prompt (template): reusable template triggered by the user (
prompts/list,prompts/get). - URI: unique address that identifies a resource (like a web address).
- Slash command: command that starts with
/; the typical form of a prompt.
To download
- 📄 Cheat sheet — Server primitives (1-page PDF: the tools/resources/prompts table with who controls each one and their methods).
- 📝 Exercises (PDF): for each primitive, write an example from your own life or work and indicate who would control it (model, application, or user).
Before you continue
If you keep one idea, let it be this: a server exposes three primitives — tools, resources, and prompts— and each one is controlled by someone different (model, application, user). In the next lesson we continue on the conceptual side: the client primitives (the other half of the protocol). Building your first tool with code arrives in Module 2.