Understanding the three MCP primitives — Tools, Resources and Prompts

When you look at MCP servers, you quickly notice something. Everyone only talks about tools. Tool here, tool there, "my server has 40 tools". Yet the Model Context Protocol defines three different building blocks a server can offer, and tools are only one of them. The other two, Resources and Prompts, are ignored almost everywhere. That's a shame, because they solve exactly the problems people otherwise abuse tools for.

This playbook teaches you the model. Not as a spec lecture, but so that afterwards you can classify any foreign server in thirty seconds and make the right choice when building your own. Ten steps, each with a concrete example. By the end you'll know why a calendar server offers "find free slots" as a tool, "my calendar rules" as a resource and "summarize meeting" as a prompt, and why that's no accident.

Step 1, the one question that decides everything

Remember one question and you've understood the whole model: Who decides that this building block is being used right now? There are three possible answers and exactly three primitives.

Tools are model-controlled. The model itself decides in the middle of a response, now I'll call this. Resources are application-controlled. The app around it, meaning Claude Code or a chat client, decides whether and when they're loaded. Prompts are user-controlled. The human actively selects them, usually via a menu or a slash command.

These three control levels are the whole trick. When you're unsure while building which building block to take, just ask yourself who should have control. The answer shows you the primitive.

Step 2, Tools are actions the model selects

A tool is a function the model can call to do something or to look something up. Fetch the weather, write a file, create an invoice in the CRM, start a search. The model reads the tool's description, decides for itself whether it fits, and calls it with arguments.

The decisive thing is the autonomy. You say "create the customer Meier for me" and the model picks the right one out of twenty tools, fills in the fields and fires. Nobody said beforehand which tool. That's why it's model-controlled.

Because tools can trigger actions that have real consequences, they need confirmation before they run in almost every client. That's the reason Claude Code asks you before a writing tool. A tool can send out an email or change a row in a database, and that shouldn't happen silently.

Step 3, why everyone only builds tools

Tools are the first thing everyone learns, they're the easiest to explain, and honestly you can already build almost anything with tools alone. That's exactly the trap. Because tools are so powerful, people cram everything into tools, including things that would actually be resources or prompts.

A typical example. Someone builds a tool called get_company_guidelines that always returns the same block of text, the company guidelines. The model first has to actively call the tool, it costs a roundtrip, and it sits around in the tool list and distracts. Yet static guidelines are the textbook case for a resource. Someone who knows the three primitives does this more cleanly.

Step 4, Resources are context the app loads

A resource is a piece of context the server provides and that the app can pull into the conversation. A file, a database excerpt, a log, a configuration, an image. Resources are identified via a URI, something like file:///projekt/readme.md or db://kunden/meier.

The difference from a tool is the control. With a resource it isn't the model that decides whether and when the content is loaded, but the application. In practice that often means the user clicks "attach this resource" in a menu, or the app pulls it automatically because it fits the context. The model then gets the content served to it, it didn't fetch it itself.

Why is that better than a tool that delivers the same text? Because a resource costs no roundtrip and demands no decision from the model. It's simply there, cleanly marked as context. For everything that's reference material and not an action, the resource is the right choice.

Step 5, the calendar example for Resources

Picture a calendar server. "My availability for the next two weeks" is a resource. It's context, it triggers no action, and the app can attach it to a conversation when it's about scheduling.

The subtle difference from a tool. "Find free slots between two dates" would be a tool, because the model actively computes and filters with parameters. "Here is my full calendar as context" is a resource, because it only provides material. Same topic, two different building blocks, depending on whether something is being acted on or looked up.

Step 6, Prompts are templates the human starts

A prompt in the MCP sense isn't the text you type. It's a predefined template or a workflow the server offers and that the user deliberately selects. In many clients they appear as slash commands or in a menu of available actions.

That's the user-controlled building block. The human says "I want the code review flow now", picks the prompt, maybe enters a few parameters, and the server returns a ready-structured instruction that sets the conversation in motion. The model didn't pick the prompt itself, and neither did the app, you did.

A prompt can tie resources and tools together. The "summarize meeting" prompt might pull the transcript in as a resource and at the end call a tool that stores the summary. Prompts are therefore often the bracket around a whole flow.

Step 7, all three side by side on one server

Take the calendar server again and lay all three primitives on top of each other, then you see the pattern.

Tool, find free slots, the model decides and computes. Resource, my calendar rules and my next two weeks, context the app attaches. Prompt, schedule me a meeting with team X, a flow I start as a human that internally reads the resource and at the end fires the tool.

That's not an academic construct. A well-thought-out server deliberately uses all three, and whoever sees the split immediately understands how the server is meant to work. Whoever sees only tools knows, someone left the other two building blocks lying here.

Step 8, how to classify a foreign server

When you click in a new MCP server, look at what it offers and sort it in your head. Most clients show you tools anyway, many also show prompts as slash commands, and resources often appear in an attach menu.

For each entry ask yourself, what is this. Does it trigger an action, model-controlled, then tool. Is it reference material that gets pulled in, application-controlled, then resource. Is it a flow you start yourself, user-controlled, then prompt. After three or four servers you do this automatically and understand foreign servers much faster.

Step 9, the design rule for building your own

When you build a server yourself, make the decision deliberately instead of reflexively turning everything into tools. The rule of thumb is short.

Does it act, take a tool. Is it static or queryable context without a side effect, take a resource. Is it a recurring flow that a human initiates, take a prompt. If you notice that a tool actually just always returns the same text, that's a strong signal it should be a resource. And if you want to take a complex, multi-step flow off the user's hands, put it into a prompt instead of hoping the model assembles the steps correctly on its own.

A side effect of this cleanliness is less tool sprawl. Every tool that's actually a resource clogs the tool list and makes the choice harder for the model. Fewer, more targeted tools plus proper resources plus a few prompts, that's a server that feels good.

Step 10, what clients actually support

An honest note to finish. Not every client handles all three primitives equally well. Practically everyone supports tools. Prompts as slash commands are widespread. Resources aren't made equally visible everywhere, some clients show them prominently, others barely.

For you that means, go ahead and build your server cleanly with all three primitives, but for the most important things don't rely on every client showing the resource too. Core functionality that has to run no matter what belongs in tools, because those work everywhere. Resources and prompts are the finishing touch that round out your server where the client plays along. Which client can do what is in the official client overview, and that changes fast, so check once before you rely on a feature.

What's next

Now you have the model in your head and can classify servers. The logical next step is to build one yourself. For that there's the playbook Your first MCP server in 90 minutes, where you pour the whole thing into code. If your server then runs but the client doesn't display it cleanly, Debugging MCP when nothing works helps. And the conceptual foundation for why MCP is built this way at all is in Level 4 lesson What is MCP.

Sources

• Model Context Protocol, Understanding MCP servers (Tools, Resources, Prompts and their control models): https://modelcontextprotocol.io/docs/learn/server-concepts
• Model Context Protocol, official specification: https://modelcontextprotocol.io/specification