MCP Resources Explained: Giving Agents the Right Context
Understand MCP resources, resource URIs, templates, discovery, reading, subscriptions, and safe context selection.
Understand MCP resources, resource URIs, templates, discovery, reading, subscriptions, and safe context selection.
Every MCP resource is identified by a URI.
MCP resources give AI applications a standard way to discover and read contextual data such as files, database schemas, records, documentation, or application-specific information.
Resources are application-driven. The host decides how they are listed, searched, selected, read, trimmed, and placed into model context.
TL;DR
- Every MCP resource is identified by a URI.
- Resources expose readable context; tools expose operations.
- Hosts can let users select resources or include them automatically.
- Resource templates describe parameterized URI patterns.
- Reading data still requires permissions, size limits, provenance, and prompt-injection defenses.
What is an MCP resource?
A resource is a piece of context exposed by an MCP server. Examples include file:///project/README.md, db://catalog/orders/schema, policy://support/refunds/current, or customer://accounts/7842/summary.
The URI identifies the resource within the server domain. It does not necessarily mean the client can fetch that URI directly with a web request. The client asks the MCP server to read it.
Resources may include text or binary content, media types, names, descriptions, and metadata useful to the host.
Resources versus tools
| Question | Resource | Tool |
|---|---|---|
| Primary job | Provide readable context | Perform an operation or computed retrieval |
| Control pattern | Application-driven | Often model-proposed, host-controlled |
| Identity | URI | Tool name plus arguments |
| Example | Current refund policy | Create a refund request |
A stable policy document should usually be a resource. A query that performs computation, applies filters, or changes a system may fit a tool better.
Discovering and reading
A client can list resources from a server. The host might show them in a picker, index metadata for search, or automatically select a relevant item.
After selection, the client sends a read request for a URI. The server verifies access and returns content. The host then decides how much belongs in the model context. Reading a 200-page handbook does not mean sending all 200 pages to the model.
A support-policy example
A customer asks whether a damaged item qualifies for a refund.
- The policy server lists a resource named Current damaged-item policy.
- The host selects policy://support/damaged-items/current.
- The server checks the organization and returns the policy.
- The host extracts the relevant section and preserves the URI as provenance.
- The model explains the rule and cites the source.
If the customer requests a refund, that action should move through a separate authorized tool.
Resource templates
Some sets are too large or dynamic to list individually. A resource template describes a URI pattern with variables, such as customer://accounts/{account_id}/summary.
Templates help a host construct valid identifiers, but do not grant access to every value. The server must enforce tenant and object-level authorization.
Subscriptions and freshness
Servers may support subscriptions or change notifications. A host could refresh an open document when the server reports an update.
Notifications are freshness signals, not a guarantee that every change arrives. Applications requiring strong consistency should combine notifications with explicit reads, version checks, or polling.
Context engineering controls
Resource content can be large, sensitive, stale, or malicious. A production host should:
- Enforce user and tenant authorization.
- Limit content size and media types.
- Select relevant passages instead of including everything.
- Preserve URI, title, version, and retrieval time.
- Treat embedded instructions as data, not trusted commands.
- Redact secrets and personal data where appropriate.
- Separate retrieved facts from model conclusions.
MCP resources versus RAG
MCP resources and retrieval-augmented generation can work together. MCP standardizes the provider boundary and resource access. A RAG pipeline indexes, searches, ranks, chunks, and selects passages.
An MCP server may expose resources that a host indexes, or a search tool backed by retrieval. MCP does not prescribe the retrieval strategy.
Common mistakes
- Turning every read into a tool without considering resources.
- Assuming a URI is safe or globally dereferenceable.
- Sending entire resources into context.
- Ignoring version, freshness, and provenance.
- Letting resource text override host instructions.
- Using templates without object-level authorization.
My Take
Resources make context a first-class, addressable part of MCP. Their value appears when the host selects context carefully instead of treating retrieval as unlimited copy and paste.
Continue learning
Read [Memory in AI Agents](/memory-in-ai-agents/) and [How RAG Works](/how-rag-works/) for the wider context pipeline.
