MCP Primitives Explained: Tools, Resources, and Prompts

TL;DR:

• The three primitives: an MCP server exposes three things, tools, resources, and prompts. Together they are how a server gives an AI application capabilities.
• The mental model is "who controls it": tools are model-controlled, resources are application-controlled, and prompts are user-controlled. That single distinction is the fastest way to tell them apart.
• Tools are actions: executable functions the model can call to do something or fetch live data, like create a ticket or query a database.
• Resources are context, prompts are templates: resources are read-only data the app loads for context, and prompts are reusable templates a user invokes, often as slash commands.
• Tools carry the risk: because tools take actions, they are where governance matters most, so control which tools an agent can call at the gateway, which is what DigitalAPI provides.

If you have read anything about the Model Context Protocol, you have seen the words tools, resources, and prompts. They are the three primitives every MCP server is built from, but most explanations list them in a sentence and move on, which leaves people unsure when to use which. This guide does the opposite: it explains each primitive, gives the one mental model that separates them cleanly, shows examples, and covers how to decide which to build.

What are MCP primitives?

An MCP server exposes its capabilities through three building blocks, called primitives: tools, resources, and prompts. They are the vocabulary every server speaks. When an AI application connects to a server, what it discovers is some combination of these three, and everything the server can offer is expressed as one of them.

The clearest way to keep them straight is to ask who is in control of each:

• Tools are model-controlled: the model decides when to call them.
• Resources are application-controlled: the host application decides when to load them.
• Prompts are user-controlled: the user explicitly chooses to invoke them.

That control axis maps neatly onto what each one is for. Tools do, resources inform, and prompts guide. Hold on to that and the rest of this guide is just detail.

The three MCP primitives at a glance

Tools: the action primitive (model-controlled)

Tools are the most used primitive, and the one most servers are built for. A tool is an executable function the model can call to take an action or fetch live data. Each tool has a name, a description, and an input schema, so the model knows what it does and how to call it.

Examples of tools are easy to picture because they are verbs: create a ticket, send a message, query a database, look up an order, run a calculation. When the model decides one of these is needed, it calls the tool through the client, the server runs it, and the result comes back.

Two things make tools distinct. First, they are model-controlled: the model invokes them on its own initiative, as part of solving the user's request. Second, because they take actions, tools are the primitive that actually changes things, and therefore the one that carries risk. A tool can create, modify, or delete data, which is exactly why tool access is the part of MCP that needs governing.

Resources: the context primitive (application-controlled)

Resources are read-only data that a server exposes for context. Where a tool is a verb, a resource is a noun: a document, a configuration value, a database record, a log file. Resources do not take actions, they provide information the model or user can read.

Each resource is addressed by a URI, such as config://version or file:///path/to/doc, so it can be requested by reference. The important distinction is control: resources are application-controlled, meaning the host application decides when to pull a resource into context, rather than the model calling it autonomously the way it calls a tool.

A useful analogy: if a tool is like a POST request that does something, a resource is like a GET request that returns data to read. When you want to give an AI application background information without letting the model trigger an action, you expose it as a resource.

Prompts: the template primitive (user-controlled)

Prompts are reusable templates a server offers that a user can explicitly invoke. They are usually surfaced in the host as slash commands or menu items, and they package a known-good way to ask the model to do something, optionally taking arguments.

For example, a server might offer a "/summarize" prompt that wraps whatever text you give it in a consistent instruction, or a "/review-pr" prompt that sets up a structured code review. Instead of every user retyping the same instructions, the prompt captures the pattern once.

Prompts are user-controlled: the user deliberately chooses to run them, which is what separates them from tools (the model decides) and resources (the app decides). Prompts and resources often work together, since a prompt can pull in a resource as part of the template it builds.

Tools vs resources vs prompts: when to use each

The "who controls it" axis is not just for telling the primitives apart, it is also the design decision when you build a server. Ask who should be in control:

• Build a tool when the model should be able to do something on its own, take an action or fetch live data.
• Expose a resource when you want to provide read-only context the application or user pulls in, without the model triggering it.
• Offer a prompt when there is a repeatable interaction you want the user to invoke deliberately.

A simple rule of thumb: if it changes something or needs to run on demand, it is a tool; if it is data to read, it is a resource; if it is a saved way to ask, it is a prompt. Most servers lead with tools, add resources where context helps, and offer prompts for the common workflows their users repeat.

Beyond the big three: sampling, roots, and elicitation

Tools, resources, and prompts are the three core primitives, and they cover the vast majority of what servers do. For completeness, the MCP specification also defines a few more advanced capabilities:

• Sampling: a server can ask the host's model to complete something, so the server can use the model rather than only the other way around.
• Roots: the host tells the server which parts of the filesystem or workspace it is allowed to access.
• Elicitation: a server can ask the user for additional input in the middle of a task.

These are used less often than the big three, but they round out what MCP can express. For most purposes, understanding tools, resources, and prompts is enough.

Governing what your tools can do

There is a practical reason the control model matters beyond definitions. Of the three primitives, tools are where governance concentrates, because tools take actions. A resource is read-only and a prompt is user-invoked, but a tool can create, change, or delete things on the model's initiative. As you connect more servers, the real question becomes which tools each agent is actually allowed to call.

That is an access-control decision, and it is best enforced centrally rather than trusting each application. A gateway in front of your MCP servers can control which identities reach which tools and audit every call. DigitalAPI provides that governed gateway and registry, so tool access is controlled and auditable across all your servers. If you are rolling out MCP across teams and need that control, book a demo and we will map it to your stack.

Frequently asked questions

What are the MCP primitives? The three building blocks an MCP server exposes: tools (executable functions), resources (read-only data), and prompts (reusable templates). Everything a server offers is one of these three.

What is the difference between tools and resources in MCP? Tools are executable functions the model calls to take actions or fetch live data, and they are model-controlled. Resources are read-only data the application loads for context, and they are application-controlled. Tools do, resources inform.

What is the difference between resources and prompts in MCP? Resources are read-only data exposed for context and loaded by the application. Prompts are reusable templates the user explicitly invokes, often as slash commands. The difference is who triggers them: the app loads resources, the user runs prompts.

Who controls MCP tools, resources, and prompts? Tools are model-controlled, resources are application-controlled, and prompts are user-controlled. That control distinction is the cleanest way to tell the three primitives apart.

What is an example of an MCP tool, resource, and prompt? A tool is a function like "create_ticket." A resource is read-only data like a config value at config://version. A prompt is a reusable template like a "/summarize" command.

Are tools, resources, and prompts the only MCP primitives? They are the three core ones and cover most use cases. The specification also defines more advanced capabilities, sampling, roots, and elicitation, which are used less often.

Should I build a tool or a resource? If the model should take an action or fetch live data on its own, build a tool. If you are providing read-only context the application or user loads, expose a resource. The deciding question is whether the model should be able to trigger it.