Use a resource when the application should control context
A resource is a named or templated data source that a client can discover and read. It fits file contents, database schemas, API documentation, records, or other reference material. Resource interaction is read-oriented, but do not call the underlying world immutable: the backing file, database, or API can change between reads.
Use a tool when the model must request an operation
A tool has a name, description, input schema, and execution result. It fits calculations, searches, live queries, file changes, messages, deployments, and downstream API calls. Mark read-only behavior precisely, validate arguments server-side, and put human approval in front of consequential operations.
Model the same domain both ways
For a support system, `support://policies/refunds` can be a resource the application attaches as policy context. `lookup_order` can be a read-only tool using an order ID. `issue_refund` is a consequential tool with a separate scope and confirmation. A `resolve_refund_case` prompt can guide the user through the sequence without owning the underlying authority.
Caching, pagination, tokens, and errors
Use resources when application-controlled selection and caching match the data. Use tools when a parameterized operation or fresh computation is required. Both lists can be paginated and both paths can produce errors. Token use depends on the host: loading a large resource can cost more than a narrow tool result, while loading many tool definitions can cost more than a focused resource. Measure your client/model path.
Avoid common anti-patterns
Do not expose an arbitrary SQL or shell tool when a narrow resource or typed query tool is enough. Do not hide a write inside a tool described as 'get' or 'sync'. Do not make every static document a tool merely because tools are familiar. Do not split the same primitive comparison into separate near-duplicate URLs; prompts belong in this three-way decision.
Decision tree
If the user is choosing a reusable workflow, start with a prompt. If the application needs to supply named context without asking the model to execute an operation, use a resource. If the model must request a parameterized query, computation, or action, use a tool. When a task spans all three, keep their permissions and control semantics distinct.