MCP Resources

Not everything an agent needs is an action. Often it just needs to read something: a file, a database row, a log, a page of documentation. In the Model Context Protocol those readable things are resources — data a server exposes for the agent to pull into its context, kept separate from the tools that do work.

How resources work
A resource is identified by a URI and described well enough to be chosen sensibly:

• Each has a URI such as file:///project/README.md or a custom scheme like db://orders/4821, plus a name, description and MIME type;
• The client calls resources/list to enumerate them — or expands a URI template for parameterised ones — then resources/read to fetch text or binary contents;
• A server can mark a resource subscribable and push a notification when it changes;
• Reads are application-controlled: the host decides what is attached, often letting the user pick, rather than the model helping itself.

That last point is the real difference from a tool. A tool call is a decision the model makes and may change the world; a resource read is inert context, chosen by the application around it.

Why it matters
It gives grounding a standard shape. Without resources, every request to let an agent see your data becomes a bespoke retrieval tool with its own conventions, and the agent must call a function merely to read a file. With them, context assembly stays auditable — you can see which documents a run was given — and read access can be granted without granting the ability to act.