04.02 · Walkthrough
Exposing data as resources
Serve read-only context without turning it into a tool call.
No video curated for this lesson yet
This lesson is written, ordered and part of the path - the video slot is the only thing still open. We are working through Agents & MCP lesson by lesson; 56 of 60 have their video so far.
The written notes below cover this idea in full - you lose nothing by reading instead of watching.
MCP resources are for read-only context that an agent can address and read without treating the read as an action. They keep passive data access separate from tool execution, make traces easier to interpret, and suit fixed documents, URI-addressed records, and templated data that must not mutate state.
What this lesson answers
- when should MCP data be a resource
- how do MCP resources differ from tools
- how to expose read only context in MCP
Notes
MCP Resources — MCP resources exist to expose read-only context as addressable data, because without them an agent must waste tool calls fetching passive information and the trace stops distinguishing “context read” from “action requested.”
Key Concepts: - In the MCP specification 2025-06-18, `resources` are a first-class server primitive alongside `tools`, `prompts`, and `sampling`. - A resource is identified by a URI such as `file:///repo/README.md`, `postgres://schema/table`, or `docs://policies/refunds`.
Common questions
- What is an MCP resource?
- An MCP resource is addressable read-only data exposed by a server. A client can discover available resources and read a specific URI when assembling context. It is meant for passive information such as documentation, policies, schemas, repository files, or record-shaped data that should not cause side effects.
- When should I use a resource instead of a tool?
- Use a resource when the operation only returns context and does not perform an action. Use a tool when the operation changes state, triggers work, calls an external service with intent, or should be audited as an action. Static text wrapped in a tool is usually a modelling error.
- Why do resources make agent traces clearer?
- Resources separate context reads from action requests. A trace can show that the agent read a policy, schema, or file before deciding what to do, rather than making it look like the agent invoked a tool. That distinction helps with debugging, evaluation, and auditability.
Short definition: what is Exposing data as resources?