MCP Resources
The protocol-level mechanism for exposing read-oriented, addressable context to MCP
clients — files, schemas, policies, operational views, skill instructions, or any
other application-specific information. MCP standardizes the resource lifecycle
(listing, reading, templates, updates, subscriptions) but does not prescribe a URI
scheme or information architecture.
The three MCP primitives
| Primitive | Answers | Best use |
|---|---|---|
| Resources | ”What context should an agent/user inspect or attach?” | Read-oriented knowledge, state, files, schemas, policies |
| Tools | ”What operation may the agent perform?” | Search, computation, API calls, workflows, writes |
| Prompts | ”What repeatable guided workflow should the host offer?” | Reusable interaction patterns, guided task entry points |
The resource/tool boundary
- Use a resource when the object is durable, read-oriented, addressable, and
meaningful outside one particular tool call. - Use a tool when selection needs a free-form query, filtering, ranking,
computation, external API activity, or any state change. - Use a prompt for a reusable interaction recipe the host should offer as an
intentional guided workflow.
A resource is a context object, not raw API output. Good examples:
company://brand/voice-and-messaging, crm://account/acme/brief,
obsidian://vault/guides/mcp-guide.md, skill://ai-audit/SKILL.md. A resource that
accepts an arbitrary natural-language query or triggers expensive/side-effecting
execution should be a tool instead — data://anything/{freeFormQuery} is an
anti-pattern.
Why resources matter for agents
They prevent an agent from treating every fact as an arbitrary, disposable tool
result. Resources are objects that can be linked, selected by a human, attached by a
client, cached, reread, subscribed to, and governed. A single resources/read
response can bundle multiple resource contents — the basis for briefing packs and
context packs (below).
Strongest resource patterns
- Context contract — a good resource states what it is, whether it’s
authoritative, who owns it, its provenance/last-review date, its intended audience
or sensitivity, and valid next steps — not a raw field dump. A
crm://account/{id}/briefresource should return a concise account brief
(objectives, decision-makers, risks, open decisions), not every CRM field. - Resource templates for bounded objects — parameterized URIs like
crm://account/{accountId}/briefare strongest when they point at a bounded
business object, not a disguised open-ended search endpoint. - Read model + command model — a resource exposes current state, a tool makes a
change, the agent rereads the resource afterward. Cleanly separates understanding
from mutation, and improves permission design, auditability, and reasoning quality. - Live operational views + subscriptions — resources like
ops://inbox/action-required
represent changing state rather than a static document; MCP supports list-change
notifications and update subscriptions so a client rereads content when it changes. - Context packs / artifact bundles — a deliberate, bounded collection of context
for one role, task, client, or workflow (e.g.
thirdbrain://context-packs/acme-ai-audit-discovery), reducing irrelevant retrieval
and giving an audit-friendly record of what informed an agent’s output.
Resource metadata worth adding
Where the SDK/client supports it: human-readable name/description, MIME type,
last-modified/reviewed timestamp, version, authoritative source/owner, confidentiality
classification, audience/role/client scope, priority for context selection, intended
audience (user/assistant/both), related resource links, content hash for packaged
assets. MCP resource annotations can convey intended audience, priority, and
modification time so clients select context intelligently instead of injecting
everything indiscriminately.
See also
- Skills Over MCP — the
skill://convention layered on this same resource mechanism - MCP Security with a Gateway — host-level OAuth/auth; complements the resource-level authorization discussed here
- Model Context Protocol