Why does MCP separate Tools and Resources rather than using one unified read/write primitive?

MCP servers expose two main capability kinds, and they are deliberately not merged. The cleanest way to tell them apart is to ask: who decides to use it, and can it change anything? **Resources** are read-only context the host application controls. They are addressed by URI, like a file path or a database row. The host decides when to pull a resource and feed its contents to the model. Reading a resource has no side effects. **Tools** are actions the model decides to invoke. The model looks at the task, picks a tool, and the host runs it. A tool can have real side effects: send an email, write a file, charge a card. That difference in control direction and side effects is the whole point. Because they are separate primitives, a host can grant a server permission to expose read-only resources while still gating every tool call behind user approval. One unified read or write primitive would blur that line and make safe consent impossible.

MCP keeps Tools and Resources separate because they sit on opposite sides of two axes: control direction and side effects. **Resources** are host-controlled and read-only. The application decides when to fetch a resource by URI and hand its contents to the model as context. Reading never mutates state. Tools are model-initiated and can mutate state. The model decides when a tool is needed. The call may write a file, hit an API, or trigger an external action. That split is what makes consent meaningful. A host can let a server expose your filesystem as read-only resources. It can still require explicit approval before any tool runs. Merging them into one read or write primitive would collapse that boundary. You could no longer grant read access without implicitly granting execute access. The distinction also clarifies who is in charge. Resources put the host in the driver seat for context selection. That is great for paging large context without a model round trip. Tools hand the wheel to the model for agency. Naming them separately at the protocol level lets each side reason about trust independently.