MCP Resources
MCPDefinition
The application-controlled MCP primitive. The host application determines what data to provide to Claude by reading resources. Resources are identified by URIs and can be text, JSON, binary data, or template-generated content. Claude reads but does not autonomously request resources.
Example Usage
Expose current_user_context as an MCP resource that the application reads and injects into Claude's context at conversation start.
Why It Matters for the CCA-F Exam
Resources are tested primarily through classification scenarios: given a description of data being surfaced to Claude, identify it as a Resource (not a Tool) because the application controls when it is fetched. Also watch for questions about URI-addressed content and the app-controlled injection pattern versus model-initiated retrieval.
In Depth
The Resources primitive is the application-controlled face of MCP. Unlike Tools — where the model decides when to act — Resources flip the control: the host application decides what data Claude should see, retrieves it by calling the server's resources/read endpoint, and injects the content into Claude's context. Claude reads and reasons over that content but does not autonomously request resources by URI.
This application-controlled pattern is precisely what makes Resources the right primitive for ambient context — information that should always be present or that the application determines is relevant based on its own logic. A few canonical examples: the currently authenticated user's profile, the document open in an editor, the current state of a deployment environment, or a company's style guide that should always inform Claude's responses.
Resources are identified by URIs, which can be static (config://app-settings) or dynamic (file:///workspace/src/main.ts). Content can be text, JSON, structured data, or binary. Servers can also expose URI templates that let the application parameterise which resource to read — for example file:///{path} where the application fills in the path at runtime.
A common exam trap is conflating Resources with MCP Tools (Primitive) just because both involve the server returning data. The distinguishing question is: *who decides when the data is fetched?* If the application's code calls resources/read on a schedule or in response to application events, it is a Resource. If the model decides it needs data and triggers a fetch autonomously, that pattern should be modelled as a Tool — even if the underlying operation is a read.
Resources also have a subscription mechanism for live data: the server can push resource/updated notifications to the client, which can then re-read and re-inject the updated content. This is useful for resources that change during a session, like a live log stream or a file being edited.
For the exam, remember the three-primitive control model from MCP Primitives: Tools = model decides, Resources = app decides, Prompts = user decides. Resources are most easily tested by scenarios that describe "context the system always provides" or "data the application injects at conversation start."
Frequently Asked Questions
Can Claude ask to read a specific Resource by URI?
Not autonomously through the Resources primitive — that is the key distinction. Claude cannot call resources/read itself; only the host application can. If you want Claude to decide when to fetch data from a URI, model that as a Tool that wraps the read operation. The Resources primitive is specifically for app-initiated context injection.
What is the difference between a Resource and a Tool that returns data?
The control model. A Resource is read by the application and pushed into Claude's context — Claude receives the data passively. A Tool that returns data is called by Claude autonomously when it decides it needs the information. If the timing of the data fetch must be controlled by the application, use a Resource. If Claude should decide when to look something up, use a Tool.
Can Resource content change during a session?
Yes. Servers support a subscription mechanism: the client subscribes to a resource URI, and the server sends resource/updated notifications when the content changes. The client can then re-read the resource and update Claude's context accordingly. This is used for live data sources like an open file being edited or a continuously updating log stream.