MCP resources vs tools vs prompts: when to use each.

The distinction is who controls invocation

The three primitives are easy to confuse because all three are declared by the server and listed over the same protocol. The line that separates them is the control model: the MCP architecture overview defines tools as model-controlled, resources as application-controlled, and prompts as user-controlled. That single property tells you which primitive a given capability belongs to.

• Tools (model-controlled). Functions the language model can discover and invoke automatically based on its understanding of context and the user's prompts. Tools perform actions, interact with external systems, or modify state.
• Resources (application-controlled). Structured, read-only data. The MCP resources specification calls them application-driven: the host application decides how to incorporate the data as context. Resources provide files, database schemas, or app-specific information, not model-invoked actions.
• Prompts (user-controlled). Pre-defined templates the user explicitly selects for use. The specification notes they are typically triggered through user-initiated commands in the interface, for example as slash commands.

Side by side

When to reach for which

Ask one question per capability: who should decide when it happens?

• Reach for a tool when the model should be able to act on its own. Anything with a side effect (writing, deleting, sending, publishing) belongs here, because tools are the primitive the model invokes automatically. The specification adds that there should always be a human in the loop able to deny tool invocations, precisely because tools can modify state.
• Reach for a resource when you are exposing data the application reads, not an action. If the answer is "the client should be able to look this up by an address," it is a resource. Each resource is uniquely identified by a URI, and parameterized lookups are expressed as URI templates via resources/templates/list.
• Reach for a prompt when you want to package a known workflow the user kicks off deliberately. Prompts are templates to use tools or resources in the most effective way, surfaced so the user can pick them, commonly as a slash command.

A worked example: a publish-oriented server

Map the control models onto a concrete server, the kind behind Stacktree, and the three primitives sort themselves. The mapping below is a reasoned application of the specification's control-model definitions, not an example the specification itself prescribes.

• publish is a tool. Publishing HTML changes state in an external system, so the model should be able to invoke it from context. The same goes for updating a site, deleting one, or setting a password, expiry, or link gate. These are model-controlled actions, each gated by the human-in-the-loop approval the specification calls for.
• my-sites is a resource. A listing of the sites you have already published is read-only data the host application pulls in as context. It has a natural URI, the client reads it with resources/read, and it produces no side effects. That is a resource, not a tool.
• publish-privately is a prompt. "Publish this report privately" is a canned workflow that strings together a tool call and the right gating options. The user invokes it deliberately, for instance as a slash command, which makes it user-controlled: a prompt.

Notice the pattern. The action is a tool, the readable list is a resource, and the named workflow that combines them is a prompt. If you find yourself unsure, return to the control-model question. The same capability rarely fits two boxes once you decide who pulls the trigger.

Practical notes

Tools dominate real deployments because the model-controlled surface is what makes an assistant useful without the user micromanaging it. Resources are underused: they are the clean way to give a model context it can address by URI rather than forcing every lookup through a tool call. Prompts are the least common of the three, most valuable for domain-specific helpers where a repeatable workflow is worth naming. The method names listed above (verified against the 2025-06-18 specification) have been stable across recent protocol versions, but if you target a different version, re-confirm before relying on a given method.