Explain why MCP separates Tools and Resources into distinct primitives. What security or design concern motivates this split?
Tools are model initiated, possibly side effecting actions; Resources are host controlled read only context. Splitting them lets hosts scope read access apart from action access and simplifies consent.
Picture a library with two desks. At the reference desk you read any book on the shelf, and reading never changes anything, so the librarian lets you browse freely. At the second desk you can ask staff to mail a letter, charge your card, or shred a file, and those actions change the world, so staff check with you before doing each one. MCP works the same way. Resources are the books you read, and the host decides which to hand over. Tools are the actions the model asks to perform, and each one may need your approval first. Lumping them into one read or write desk would force the same caution onto harmless reads, or worse, let a risky action slip through unguarded.
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 exposes server capability through three primitives: Tools, Resources, and Prompts. This question zeroes in on the first two, and specifically on why they are separate kinds rather than one unified read/write abstraction. It is a deceptively deep question, because the answer is not about convenience. It is about encoding a security and control boundary directly into the protocol.
The short version: Tools and Resources differ on two orthogonal axes. The first is control direction, who initiates the call, the model or the host. The second is side effect risk, whether the operation can change the world or only observe it. Once you see those two axes, the design choice becomes obvious, and so does its payoff for permissioning, consent, and defense against the MCP threat landscape.
This deep dive unpacks each axis, shows what collapsing the two primitives would cost, and connects the split to least privilege and real attacks like tool poisoning.
Axis one: control direction (who initiates)
The first axis is about who holds the steering wheel. With Tools, the model is in control. The host advertises tool schemas into the model's context, and the LLM decides, on its own, when to call one and with what arguments. The model is the initiator.
With Resources, the host application is in control. Resources are URI-addressed data references. The host decides which URIs exist, which to read, and which to inject into the model's context. The model can reference a resource's contents, but it does not get to reach out and pull arbitrary data on its own initiative.
This is a real safety property, not a naming convention. A misaligned, jailbroken, or confused model can reach every Tool you expose, because invocation is model driven. It cannot reach beyond the Resources the host already chose to load, because the read plane is host driven. Control direction therefore determines how far an untrusted model's reach extends, which is exactly the kind of thing a protocol should make explicit rather than leave to each app's convention.
Think about what an attacker actually manipulates. Prompt injection, poisoned tool descriptions, and adversarial tool outputs all work by bending the model's reasoning. Because Tool invocation flows through that reasoning, those attacks can trigger Tool calls. Resource reads do not flow through model reasoning at all. The host's own application logic decides them. So an attacker who fully owns the model's reasoning still cannot make the host fetch a resource it did not intend to fetch. That asymmetry is the whole reason control direction earns its own axis: it bounds the blast radius of a compromised model.
Situations where this technique stops working.
2–4 min · Everything important, quickly.
| Aspect | Tools | Resources |
|---|---|---|
| Who initiates | Model decides to call it | Host application selects it |
| Side effects | May write, delete, or trigger actions | Read-only, never mutates state |
| Addressing | Named function with JSON Schema args | URI-addressed data reference |
| Consent | Often needs explicit user approval | Usually loaded without per item prompt |
| Risk plane | Action plane, the dangerous surface | Read plane, the safe surface |
Real products, models, and research that use this idea.
- Claude Code gates each MCP tool call behind user approval while letting the host load file Resources by URI without a prompt per file.
- Anthropic's filesystem MCP server exposes file contents as read only Resources and separately exposes write or edit operations as Tools.
What an interviewer would ask next. Try answering before peeking at the approach.
QHow does the Tools versus Resources split interact with the MCP threat model, like tool poisoning or rug pulls?
Those attacks target the action plane; keeping Tools narrow and consent gated, separate from the broad read only Resource surface, shrinks the attack surface and gives audit logs a clean boundary.
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.
Saying the split is just cosmetic naming. It encodes a real control direction and side effect boundary that drives permissioning and consent.
60 second bullets to scan on the way to the call.
Who initiates a Tool call versus a Resource read
Whether each primitive can have side effects
Primary sources. Browse if you want the original framing.
Same topic, related formats. Practice these next.