Classify tool / resource / prompt
What you'll learn
Tools are what the model decides to use, resources are data the app/user attaches, prompts are templates the user picks from a menu.
- Three primitives, defined by *invoker*: tools (model), resources (app/user), prompts (user).
- Tools = executable / side-effecting. Resources = read-only data references. Prompts = reusable templates.
- Misclassification has real costs: tool clutter, hidden workflows, user confusion.
MCP defines three core primitives — **tools**, **resources**, and **prompts** — and the exam tests whether you can match a real-world capability to the right one. The trap is that all three look like 'things a server exposes to the client' until you focus on *who invokes them and what their semantics are*. The invocation model is the defining axis.
**Tools** are model-invoked, executable, side-effecting (or computing) operations. The model sees their schema and chooses to call them mid-conversation. Examples: 'send_email', 'run_query', 'create_ticket'. If the model could plausibly say 'now I want to do X to satisfy this request,' it's a tool.
**Resources** are data references — read-only content the model can be pointed at. They're typically *application/user-invoked* (the host app or user picks which resource to attach), not model-invoked. They're addressed by URI and are the right primitive when the model needs to *consume* a piece of data without executing anything. Examples: a file's contents, a database row, an OpenAPI doc.
**Prompts** are reusable, *user-invoked* templates — pre-authored prompt structures with parameters that the user (or app) selects from a menu. They're the right primitive when there's a recurring task you want to make one-click reusable. Examples: 'summarise_meeting', 'write_release_notes'. The user picks the prompt and fills in the slots; the model then executes the templated request.
The classification rule is mechanical: *who decides this gets used?* Model decides → tool. App/user attaches data → resource. User picks a template → prompt. Misclassification produces real bugs: exposing a static doc as a tool clutters the model's tool list and triggers spurious calls; exposing a workflow as a resource buries it in attachments where users won't find it; exposing data as a prompt requires the user to select something they shouldn't have to think about.
Key points
- Three primitives, defined by *invoker*: tools (model), resources (app/user), prompts (user).
- Tools = executable / side-effecting. Resources = read-only data references. Prompts = reusable templates.
- Misclassification has real costs: tool clutter, hidden workflows, user confusion.
- Sampling and roots are emerging additions but not the focus of D3 questions.
Examples
If the model should decide when to query (mid-conversation, given the user's question): tool. If the user picks a query template from a menu and fills in parameters: prompt. If the model needs to read a specific table's schema as data context: resource.
Resource. The model consumes its content; the model doesn't 'execute' the doc. Wrong choice: defining a `read_policy_doc` tool — every time the model wants the doc it has to invoke a tool, where attaching the resource once would be enough.
Pitfalls
- Defaulting to 'everything is a tool' because tools feel familiar from function-calling. Resources and prompts exist precisely because not everything model-callable belongs in the tool list.
- Exposing a workflow ('summarise this meeting in 5 bullets') as a resource. Users need to *pick* it; resources don't have a picker UX in most clients.
- Exposing static reference data as a tool. Forces the model to make a tool call for content that should already be in context.
Source notes: 00-academy-basics/notes/05-mcp-intro.md
Ask Claude
Build a prompt with this lesson + your question, copy it, and open the Claude Project in a new tab.