Server primitives — Cheat Sheet

Curso MCP Engineering · M1

This guide explains, from scratch and taking nothing for granted, the three primitives that every MCP server exposes: tools, resources and prompts. Read it slowly: if you understand what each one is and —above all— who controls it, you've already understood the heart of Module 1.

In one sentence

An MCP server doesn't expose "just anything": it offers exactly three types of capabilities, and we call those three types primitives. A primitive is simply a basic building block of the protocol. The most important idea in the whole lesson is this: each primitive has a different controller — the model, the application or the user. That separation is no accident: it's the design.

The three primitives at a glance

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 (search an API, write to a database, send a message). The model reads the list of available tools, picks one and runs it with whatever data is needed.

• Who's in charge? The model. That's why tools are said to be model-controlled.
• The two methods: tools/list (ask for the list of tools available) and tools/call (run one, passing it a name and its arguments).
• 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 create_event with date="Tuesday 10:00" and title="meeting". You didn't press any button or pick the function: the model decided it from your request.

2. Resources — controlled by the application

A resource is read-only data: a file, an image, a JSON, a text. It runs no actions; it only delivers information to provide context. Each resource is identified by a URI (a unique address, similar to a web address).

• Who's in charge? The application (the host decides which resources to load and when). They are application-controlled.
• The two methods: resources/list (which resources are available) and resources/read (read the content of one, specifying its URI).
• Beginner example: the file file:///return-policy.md from a store. The application attaches it to the model as context so it answers well about returns. The resource itself does nothing: it's only read. Think of it as a note that the app hands to the model, not as a button the model presses.

3. Prompts (templates) — controlled by the user

A prompt is a reusable template of instructions, designed for the user to trigger 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.
• The two methods: prompts/list (which templates are available) and prompts/get (fetch one, ready to use, with its data filled in).
• Beginner example: a prompt /summarize-meeting that, when invoked, assembles a message like "Summarize this transcript into 5 points and a task list". You choose it, with a click or by typing the command; 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 (actions, more or less automatic).
• Resources → the application decides (read-only context).
• Prompts → the user decides (templates on demand).

Why does this separation matter so much?

Because it makes a server predictable and safe. If everything were decided by the model, you'd never know what it's going to touch or when. By splitting control, each actor has its lane: the user triggers templates when they want, the app decides what data enters as context, and the model can only act through tools someone exposed to it. That clarity of "who can do what" is exactly what makes an MCP server trustworthy.

⚠️ Watch out for tool design: exposing too many tools inflates the model's context and confuses it — less is more. How many and which to expose is a debated topic among those who build servers; it's covered in depth in an advanced module. For now, keep it on your radar.

One-line examples

• Tool: create_event(date, title) — the model calls it on its own when you ask it to "schedule Tuesday".
• Resource: file:///return-policy.md — the app reads it to provide context.
• Prompt: /summarize-meeting — the user invokes it to assemble a ready-made message.

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 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, e.g. file:///notes.txt).
• Slash command: command that starts with /; the typical form of a prompt.
• .../list and .../call/.../read/.../get: by convention, each primitive has a method to list what's available and another to use a specific item.

To remember

1. A server exposes three primitives: tools, resources and prompts.
2. What distinguishes them is who controls them: Tools = model, Resources = application, Prompts = user.
3. Each one has its pair of methods: list what's available + use a specific one.
4. That separation of control is on purpose: it's what makes the server predictable and safe.

Turning Point Academy · MCP Engineering Course · Module 1 · Server primitives