Explain why MCP separates Tools and Resources into distinct primitives. What security or design concern motivates this split?
Free · 2 AI evals / day
MCP gives a server three ways to expose capability, and two of them are **Tools** and **Resources**. They look similar, but they differ on two axes: who starts the call, and whether it changes anything.
A Tool is an action the model decides to invoke. It can have side effects: send an email, write a row, delete a file. Because the model picks when to fire it, and because it can change the world, a tool call often needs the user to approve it.
A Resource is read only data the host application chooses to pull, like a file or a query result. It never mutates state, and the host decides whether to include it in context. The model does not trigger it directly.
So why keep them separate rather than one read or write abstraction? Because the risk and the control direction differ. Reads are safe and host driven; actions are risky and model driven. Splitting them lets a host grant data access without granting action access, and ask for consent only where it matters.
MCP splits capability along two axes: who initiates the call, and whether it has side effects.
Tools are model initiated and potentially side effecting. The LLM decides to call one, and it may write, delete, or trigger an external action. Resources are application controlled and read only. The host decides when to pull one, and it never mutates state. The model does not invoke a resource directly; it references data the host supplies.
Collapsing both into one read/write abstraction would erase that boundary. You would lose the clean place to enforce least privilege.
Keeping them distinct buys two things. First, security scoping. A host can grant read data access through Resources without granting action execution access through Tools. Those are different trust levels and deserve different grants.
Second, consent modeling. Users can treat a resource pull as harmless context loading. A tool call may demand explicit approval because it can change the world. The interview grade phrasing is control direction plus side effect risk. Tools are the dangerous, model driven plane; Resources are the safe, host driven plane. The split makes that difference enforceable rather than implicit.
Quick reference
TL;DR
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.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Exposing data the model must actively fetch on its own initiative mid-reasoning Resources are host-pulled, so model driven fetch belongs in a read tool instead, even though it carries no side effects.
A capability that both reads and writes in one indivisible operation It cannot be a pure Resource; model it as a Tool so the side effect and consent gate applies to the whole call.
Tiny single-vendor app with one hard coded read path and no plug in story The full primitive distinction adds protocol ceremony with little payoff when there is no multi host reuse.
Quick scan · 2–4 min
Everything important, quickly.
4 min: two axes (control direction plus side effect risk) + read only vs side effecting + security scoping + consent modeling + tie to the MCP threat model.
Side-by-side
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-world examples
Real products, models, and research that use this idea.
1Claude Code gates each MCP tool call behind user approval while letting the host load file Resources by URI without a prompt per file.
2Anthropic's filesystem MCP server exposes file contents as read only Resources and separately exposes write or edit operations as Tools.
3The OWASP MCP Top 10 (2025) centers tool poisoning and rug pull risks on the Tools plane, validating why Resources stay read only.
4Cursor and Zed both surface MCP Tool calls for confirmation in 2026 while treating Resource reads as ambient context.
Interviewer follow-ups
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?
Sign in or go Pro to see the approach for this follow-up.
QWhy are Resources URI-addressed and host-pulled rather than just exposed as read only tools?
Sign in or go Pro to see the approach for this follow-up.
QIf a model needs to read a file before writing it, how do Tools and Resources cooperate?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Saying the split is just cosmetic naming. It encodes a real control direction and side effect boundary that drives permissioning and consent.