Use a tool when the model should be able to do something, a resource when the application should load read-only context, and a prompt when the user should trigger a reusable workflow. The three primitives differ mainly in who controls them: the model, the application, or the person at the keyboard.
The three building blocks
The Model Context Protocol (MCP) documentation describes three things a server can offer. Tools are functions the model can call, and the model decides when. Resources are passive data sources such as file contents, database schemas or documentation. Prompts are pre-built instruction templates.
The official server concepts page lists a controller for each: tools are model controlled, resources are application controlled, and prompts are user controlled. That one column answers most design questions.
When a tool is the right choice
Pick a tool when the work has side effects or needs live computation. Sending a message, creating a ticket, running a query and calling an API are all tool shaped. Each tool has a name, a description and a JSON Schema for its inputs, so the model knows what arguments to supply.
Because the model chooses when to call a tool, tools carry the most risk. The specification says there should always be a human in the loop with the ability to deny tool invocations. If your use case is "read this reference page", a tool is more power than you need.
When a resource is the right choice
Pick a resource when you have data that gives context and the application, not the model, should decide how to use it. A resource has a URI and a MIME type. The application can show a picker, filter by search, or pull a slice in with embeddings before anything reaches the model.
Resources also support templates with parameters, such as a city and a date in the URI. That suits lookups where the shape is fixed but the values change.
When a prompt is the right choice
Pick a prompt when you want a repeatable workflow that a person starts on purpose. In many clients these show up as slash commands or a command palette entry. A prompt can take arguments, for example a destination and a budget, and can refer to the tools and resources the server also offers.
If you find yourself writing a long instruction block and hoping the model calls the right tools in the right order, a prompt may be cleaner.
A quick decision table
- The model needs to change something or call a live service. Primitive: Tool.
- The app should attach a document or schema as context. Primitive: Resource.
- A user runs the same multi step task often. Primitive: Prompt.
- You are not sure. Primitive: Start with a resource, which is read only.
A note on client support
Not every client implements all three primitives. Many agent clients focus on tools. Check what your target client supports before you design around resources or prompts, and test with the same client your team will use.
For how these pieces fit with other agent features, see MCP vs skills vs hooks vs rules. For the basics, see what is the Model Context Protocol.
Quick check
Who decides when a tool is called?
The model decides based on the conversation, which is why the specification recommends a human approval step for tool calls.
Can a resource change data?
Resources are described as read-only, passive sources of information. Actions belong in tools.
Sources
Last reviewed: 19 October 2026.
