MCP tools vs resources vs prompts: which to use

In the Model Context Protocol (MCP), tools are actions the model chooses to call, resources are data the application feeds into the model's context, and prompts are templates the user explicitly invokes. The fastest way to pick the right one is to ask who is in control.

All three are capabilities an MCP server can expose, and it is easy to reach for a tool for everything. But the three primitives exist precisely because they answer different questions. Getting the mapping right makes servers that models use correctly and that hosts can render sensibly.

When should something be a tool?

Make it a tool when the model should be able to decide, mid-conversation, to perform an action. Tools carry a name, a description, and a JSON Schema for their inputs, and the model reads those to choose when and how to call them. Running a query, creating an issue, sending a message, searching an index: all tools.

Because the model invokes tools autonomously, a tool that has side effects deserves the same care as an API endpoint that mutates data. Describe it precisely, validate the input schema, and mark read-only versus write behavior clearly. A vague tool description is the single most common reason a model calls the wrong tool.

When should something be a resource?

Make it a resource when you are exposing data for context rather than an action to take. Resources are addressed by URI and are meant to be selected by the application (or the user through the app), not called spontaneously by the model. A file's contents, a database record, the current git diff, a documentation page: all resources.

The distinction is about control, not content. The same Postgres row could be reachable through a read-only query tool (the model asks for it) or a resource (the app pins it into context). If you want deterministic control over what the model sees, use a resource; if you want the model to fetch on demand, use a tool.

// A tool advertises an action the model may call:
{ "name": "query", "description": "Run a read-only SQL query", "inputSchema": { "...": "..." } }

// A resource advertises data the app can load, addressed by URI:
{ "uri": "postgres://main/orders/1042", "name": "Order 1042", "mimeType": "application/json" }

When should something be a prompt?

Make it a prompt when you want to give the user a reusable, parameterized workflow they trigger deliberately. Prompts are user-controlled. Hosts commonly surface them as slash commands or menu items. "Summarize this PR," "draft a release note," "start an incident review" are prompts: the user picks them, the server returns a well-formed message sequence, and the conversation proceeds.

Prompts are the most under-used primitive. If your users keep typing the same multi-step instruction by hand, that instruction wants to be a prompt: encode it once, expose it, and let the host offer it as a first-class command.

Tools vs resources vs prompts at a glance

Primitive   Controlled by   Answers the question        Typical example
---------   -------------   -------------------------   ------------------------
Tool        The model       "What can I DO?"             run a query, send a message
Resource    The app/user    "What context should I SEE?" a file, a DB row, a diff
Prompt      The user        "What workflow do I START?"  a slash-command template