Quick answer: Use a resource template when the model needs parameterized, read-only access to data that has an address, such as a file path or a record id, and use a tool when the call performs an action, may have side effects, or needs approval. A resource template is a fill-in URI the host reads from; a tool is a named function the model invokes. When a read could be modeled either way, default to a resource for addressable data and a tool for anything that writes or computes.
What each primitive is
Resources are the readable data a server exposes. Each resource has a URI, a name, and an optional MIME type, and the client fetches it with a resources/read call. Tools are functions the model can call: each has a name, description, and input schema, and a tools/call runs it and returns structured content. Resources sit on the read side of that line, while tools cover the operations.
Resource templates in one minute
A plain resource is one fixed URI. A resource template is a parameterized URI following the URI template pattern, such as file:///{path} or https://api.example.com/users/{id}, that the server advertises so the client can fill in the braces and construct a valid address. The model supplies the parameter, the host builds the URI, and the same read path handles every value. This keeps the data addressable: a fetched result points to a real URI that can be referenced, re-read, or cached rather than existing only as the output of a function.
Side-by-side
| Dimension | Resource template | Tool |
|---|---|---|
| Intent | Read data | Do work or compute |
| Input | Parameters in a URI | Structured schema arguments |
| Side effects | None expected | Possible, often approved |
| Addressability | Each result has a URI | Result is not inherently addressable |
| Caching | Reads can be cached | Usually not cached |
| Host control | Treated as data access | Often gated by user consent |
Where they overlap
A read by id is the case where both work. users/{id} as a resource template says "this record lives at this address." A get_user tool says "call this function with an id and take the result." The semantics differ even when the bytes come back identical. Prefer the template when the same data is read repeatedly, linked from elsewhere, or shown in a browser of available data. Prefer the tool when the read is really the start of a workflow, applies logic beyond a simple fetch, or must sit alongside write operations the model already calls.
How the model actually reaches them
Tools are the path models are most reliable at invoking automatically, because tool selection is built into the model's call loop. Resource discovery and automatic reads vary more across hosts; some surface resources through an attachment or picker rather than letting the model fire reads on its own. If a value must be fetched autonomously every time, a tool is often the safer bet. If the goal is addressable, user-browsable data that the host can list and read, resources fit better. To confirm what a server actually returns for either primitive, send the calls and inspect the responses in a local workspace; Powerduck keeps those reads visible so the choice is based on observed behavior.
Honest limits
The protocol defines the shapes, not a hard rule that every read must be a resource, and hosts differ in how they expose resources to the model. A resource being read-only is a convention the server is expected to honor; the protocol does not prove the handler never mutates state. A template also does not validate that the underlying data is current or correct. Connecting a server does not deploy a backend, and these primitives do not replace the real system the data comes from.
Frequently asked questions
Is a resource template just a read-only tool? It is read-only and addressable, but the model reaches it through a constructed URI rather than a function call, and the host treats it as data rather than an action.
Can a parameterized read be a tool instead? Yes. Use a tool when the read involves logic, starts a workflow, or needs the same consent path as write operations.
Do models call resources automatically? Support varies by host; tools are the more consistent path for autonomous invocation, while resources are often surfaced through browsing or attachment UI.
Can a resource template have side effects? It is meant to be read-only, so a handler that mutates state breaks the expected contract.
The bottom line
Choose by intent: addressable, parameterized reads belong in resource templates, and actions that compute or change state belong in tools. If the result has a URI that should be linked or cached, lean resource; if the model must reliably trigger it or it needs approval, lean tool. For more on building these servers, see the MCP server guide hub.
Top comments (1)
The dividing line I use is who has to know the address. A resource template lets the model invent a URI and come back to it later, which is exactly what you want for read-heavy data that changes slowly - and it is also why a sloppy template is dangerous: the model will construct URIs you never intended, and a template that answers them with an empty result teaches it nothing.
Tools are the right shape when the server has to validate intent, because arguments are a contract rather than a namespace.
The practical consequence is caching: resource reads are cacheable and tool calls are not, so anything expressible as a resource also costs fewer tokens across a session.