- In short
- MCP resources are read-only data that a server exposes to a client so the model can see what information exists without calling a tool. Each resource has a URI and is discovered through a list request and fetched through a read request, which lets an agent orient itself on a content catalog before it acts.
What MCP resources are and why they exist
MCP resources are the part of the Model Context Protocol that lets a server share data with a client, as opposed to sharing actions. The specification describes resources as a standardized way for servers to expose context to language models: files, database schemas, issue summaries, documentation hierarchies, anything the model might want to read. Each resource is uniquely identified by a URI, which gives the agent a stable handle it can point to and fetch.
The problem mcp resources solve is exploration cost. Without them, an agent that needs to know what data is available has only one move: call a tool, see what comes back, call another tool, and slowly map the territory one request at a time. Every one of those exploratory calls spends tokens and adds a round trip. By exposing a content catalog as resources, you hand the agent a table of contents up front, so it can orient itself on what exists before deciding what to do. That is why this knowledge point lives at the understand Bloom level: the exam wants you to explain the mechanism and the efficiency argument, not just name it.
- MCP resource
- A read-only piece of context a server exposes to a client, identified by a URI and retrieved through the protocol's list and read messages. Resources give a model visibility into available data without requiring it to invoke a tool to discover that data.
Resources versus tools: the distinction the exam tests
The single most important comparison for this topic is resources against tools, and the difference is about who is in control.
- Resources are application-driven. The host application decides how to incorporate them, whether by showing the user a picker, letting them search, or including them automatically based on heuristics. The protocol deliberately does not mandate a single interaction model. Crucially, reading a resource has no side effects; it is data retrieval.
- Tools are model-invoked. The model itself chooses to call a tool, passes arguments, and the tool runs code that can change state, send an email, write a row, or open a pull request.
A clean mental test: if the agent needs to see something, that is a resource; if the agent needs to do something, that is a tool. A catalog of database schemas is reference data the agent should be able to browse, so it is a resource. Running a parameterized query against those tables is an action, so it is a tool.
How discovery and retrieval work
Resource access is a two-step protocol exchange, and keeping the two steps distinct is what makes resources efficient.
First, discovery. The client sends a resources/list request and the server returns an enumeration of available resources, each with its URI, a human-readable name, an optional description, and a MIME type. This is the table of contents. The agent now knows what exists without having fetched any of the actual content, which is cheap.
Second, retrieval. Once the agent has chosen a resource, the client sends a resources/read request with the specific URI, and the server returns the contents as text or binary data. Only the resources the agent actually needs get fetched, so the expensive part, pulling real content into context, happens selectively rather than indiscriminately.
The protocol also supports resource templates, which expose parameterized resources through URI templates, and optional subscriptions that notify the client when a resource changes. For the foundations exam you mainly need the list-then-read flow and the efficiency it buys; the templates and subscriptions are useful context but secondary.
The efficiency argument in practice
Think about an agent working in a large issue tracker. If the only affordance is a search tool, the agent has to guess queries, inspect results, refine, and repeat, each iteration a tool call that consumes tokens and time. Expose the project's issue summaries and component hierarchy as resources instead, and the agent reads the catalog once, sees the structure, and jumps straight to the relevant items. The exploratory loop collapses into a single oriented read.
This is also why resources interact with context-management knowledge points elsewhere in the exam. Reducing exploratory tool calls means fewer bulky tool results landing in the conversation, which keeps the context window leaner and reduces the need to trim history later. Visibility up front is cheaper than discovery after the fact.
Templates, subscriptions, and freshness
Two protocol features extend resources beyond a static list, and knowing they exist rounds out your understanding even though the foundations exam centers on the list-then-read flow. Resource templates expose parameterized resources through URI templates, so instead of enumerating a thousand fixed files, a server can advertise a pattern that the client fills in to address any file under a directory. Templates keep a large or open-ended catalog describable without forcing the server to list every item up front.
Subscriptions address freshness. A client can subscribe to a specific resource and receive a notification when it changes, and a server that declares the list-changed capability can announce when the set of available resources itself grows or shrinks. These are optional; a server may support neither, either, or both. The reason they matter conceptually is that they let an agent rely on a resource as a live view rather than a one-time snapshot, which is what makes resources trustworthy for data that moves.
Resource metadata and annotations
Every resource a server lists carries a small set of metadata, and knowing the fields clarifies what the agent actually sees during discovery. A resource definition has a required uri that uniquely identifies it and a required name, plus several optional fields: a title for display, a description, a mimeType, and a size in bytes. The description is what the agent reads to judge relevance, while the mimeType tells a client whether it is about to read text or binary content and how to render it, which is why omitting it for non-obvious content types is a common pitfall.
Resources can also carry annotations that hint at how a client should treat them, and two are worth knowing for the exam. The audience annotation is an array whose valid values are user and assistant, signalling whether a resource is meant for the human, the model, or both. The priority annotation is a number from 0.0 to 1.0, where 1 marks the most important resources and 0 the least, letting a server rank which resources are worth surfacing first.
For a content catalog these annotations turn a flat list into a guided one. Priority lets the host or the agent lead with the resources most likely to matter rather than treating every entry as equal, and audience keeps assistant-only context out of what a user browses. Used well, metadata and annotations are how a catalog tells the agent not just what exists but what to look at first.
Designing a resource catalog worth reading
The efficiency win from resources is only realized if the catalog is actually legible to the agent, and that is a design responsibility, not an automatic outcome. Three habits separate a useful catalog from a noisy one. First, write a clear description for every resource, because the description is what the agent reads during discovery to decide whether a resource is relevant; a catalog of URIs with empty descriptions forces the agent back into guessing. Second, choose sensible granularity: one resource per chapter or per table is browsable, while a single resource that dumps an entire knowledge base defeats the point by making every read enormous. Third, give resources stable, meaningful URIs so the agent can refer back to the same data reliably across a task.
These choices echo the same principle that governs tool descriptions elsewhere in this domain: the model acts on the text you give it, so the quality of your names and descriptions is the quality of the agent's decisions. A well-described resource catalog is, in effect, a map drawn for a reader who has never seen the territory, and the clarity of that map determines how efficiently the agent moves through it.
Resources and tools in the same server
Resources and tools are not rival designs you must choose between; a single MCP server commonly exposes both, and the strongest integrations use each for what it is good at. The server publishes resources so the agent can see the shape of the data, and it publishes tools so the agent can act once it knows what it is looking at. An issue-tracker server, for example, might expose the project's component hierarchy and issue summaries as resources for orientation, while offering create-issue and update-issue tools for the actions that change state. Seen this way, resources and tools are complementary halves of one capability: visibility first, action second.
Why it matters for the exam
Task statement 2.4 frames resources as a deliberate design choice for content catalogs. A scenario will typically describe an agent that is slow, expensive, or unreliable because it keeps making exploratory calls to figure out what data is available, and ask you for the architectural improvement. The intended answer is to expose that data as MCP resources so the agent gains visibility without the exploration. The trap is to reach for yet another tool, which adds to the agent's tool count and selection burden rather than removing the exploration problem at its root.
Worked example
A documentation assistant agent answers questions about a 400-page internal handbook. Today it has a single search_docs tool, and users complain it is slow and sometimes misses the right section because it keeps guessing search terms.
Diagnose the cost first. With only search_docs, every question forces the agent into an exploration loop: guess a query, read the snippets, decide they are not quite right, guess again. Each iteration is a tool call, and the agent never has a stable picture of how the handbook is organized, so it is effectively searching blind.
Now redesign with resources. Expose the handbook's structure as MCP resources: one resource per chapter or section, each with a clear URI and a description summarizing what it covers. The agent issues a single resources/list and immediately sees the full table of contents, the same orientation a human gets from flipping to the index. When a user asks about, say, the parental-leave policy, the agent reads the catalog, identifies the benefits chapter by its description, and issues one resources/read for that URI.
The payoff is concrete. The exploratory guess-and-refine loop disappears, replaced by one cheap list and one targeted read. Fewer tool calls means lower token spend and lower latency, and accuracy improves because the agent is choosing from a described catalog rather than gambling on search strings. Note what you did not do: you did not add a second tool. You changed the kind of affordance from an action the model has to drive blindly to data it can see, which is exactly the resources-over-tools instinct this knowledge point teaches.
Common misreadings to avoid
Misconception
Resources and tools are basically the same thing, so it does not matter which one you use to expose a data catalog.
What's actually true
Misconception
Adding more search tools is the way to fix an agent that keeps making exploratory calls to find data.
What's actually true
How it shows up on the exam
An analytics agent repeatedly calls a list_tables tool and then a describe_table tool just to learn what database objects exist before it can answer anything, which is slow and token-heavy. Which MCP design change most directly removes this exploration overhead?
People also ask
What is the difference between MCP resources and tools?
How does an agent discover MCP resources?
When should I use a resource instead of a tool?
Do MCP resources reduce token usage?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
Defining resources
Why watch: Exposing catalogs and documents as MCP resources gives agents visibility into data without exploratory tool calls, the exact purpose of this KP.
More videos for this concept
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.