MCP servers expose three primitives: tools (model-initiated, side-effectful), resources (app-initiated, read-only), and prompts (user-initiated templates). Each has a distinct initiator.
Picture a kitchen with three drawers. The first drawer holds appliances the chef reaches for on their own to cook something, which changes the meal. Those are tools, the model decides to use them. The second drawer holds recipe cards, read-only references someone hands the chef when needed, and the chef never rewrites them. Those are resources, the app decides what to pass in. The third drawer holds pre-written order forms a diner picks from a menu to start a request. Those are prompts, the user picks them. The whole trick is remembering who opens each drawer: the chef, the kitchen staff, or the diner. Mixing up who initiates what is the classic mistake.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Concept explanation~2 min read
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
MCP gives a server exactly three ways to offer capability to a host: tools, resources, and prompts. Candidates lose points not because they forget the names, but because they blur who initiates each one and whether it changes state. That single axis, the initiator, is what every well-formed exam option probes.
The mental model is a control question. For any capability, ask: does the model decide to invoke it, does the host application pull it in, or does the user pick it from a surface? Tools answer model, resources answer application, prompts answer user. Layer one more question on top, does this change external state, and you can classify any option in the bank correctly.
This deep dive walks each primitive in turn, then dissects the two distractors in the question, the resource-writes-back trap and the universal-approval trap, because both encode misconceptions interviewers love to plant.
Tools: model-initiated and side-effectful
Tools are the primitive closest to classic function calling. A tool is a named, callable function the server advertises through tools/list. The model decides, mid-reasoning, that calling a tool is the right move, and the host dispatches tools/call with the arguments the model produced.
Two properties define tools. First, they are model-initiated: nothing happens until the model emits a call. Second, they may have side effects. Calling send_email actually sends mail; calling run_query can mutate a database. That is why hosts gate tool calls behind permission prompts.
The enabling detail is the inputSchema. Each tool definition carries a JSON Schema describing its arguments. The host translates that schema into the model vendor's function-calling format, and the model uses it to form valid arguments. So the schema does double duty: it documents the contract and it steers generation toward well-typed calls.
A tool result is also more than a yes-or-no. The server returns a content array, which can include text, structured data, or even an isError flag when something goes wrong. The host hands that result back into the next model turn, so the model can react to a failed call rather than silently proceeding. This closes the loop: the model proposes, the tool acts, and the result re-enters the model's reasoning. That feedback path is exactly why tools, not resources, are the right home for anything that touches the outside world.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Primitive | Initiator | Side effects | Key field |
|---|---|---|---|
| Tools | Model | Yes, may mutate state | inputSchema |
| Resources | Application | No, read-only | URI |
| Prompts | User | No, expands a template | arguments / slots |
Real products, models, and research that use this idea.
- Claude Desktop discovers tools, resources, and prompts from each configured MCP server and gates tool calls behind user approval.
- Anthropic's filesystem MCP server exposes file contents as read-only resources by URI and edit actions as side-effectful tools.
What an interviewer would ask next. Try answering before peeking at the approach.
QWhy does MCP separate resources from tools instead of treating every fetch as a tool call?
Resources are addressable read-only data the host can page by URI; modeling reads as tools would force a round-trip per fetch and burn latency on large context.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Red flags & common mistakes
The phrases that signal junior thinking. Click to expand.
Thinking resources are model-initiated or writable. Resources are read-only and pulled by the host application, never invoked by the model.
60 second bullets to scan on the way to the call.
Who initiates each of the three primitives
Why resources are read-only and not model-invoked
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.