AnthropicClaude Certified Architect – Foundations2026-102.4 Integrate MCP servers into Claude Code and agent workflows
Expose catalogs before requesting detailed evidence
Completed by the knowledge check
Learning objective
Distinguish application-controlled, URI-addressed MCP resources for context from model-invoked MCP tools for retrieval and actions.
Core idea
A resource identifies context the host can obtain and include; a tool defines an operation the model can request. Use a resource catalog to show which documentation collections, issue summaries, or database schemas exist. Use tools when the workflow needs a parameterized search or an action such as updating an issue.
The useful distinction is control and interface, not “resources contain data, tools do not.” Tools can retrieve data, and a resource still requires a read operation to obtain its contents. A catalog reduces blind exploration by supplying an explicit map of available context; it does not automatically supply every underlying document or prove that a later search covered the entire corpus.
This lesson uses the resource contract in MCP protocol revision 2026-07-28 and Claude Code’s documented resource surfaces. The exact host behavior matters when deciding how catalog content reaches the conversation.
How it works
Address context with a URI
MCP resources have unique URIs. A server can expose a file, schema, or application-specific item with a uri, name, optional description, and optional mimeType. The URI is the address used to read the content; the name is descriptive metadata, not a substitute identifier for that read.
For example, a team-owned server could expose docs://catalog as an index of approved documentation collections. That URI and its catalog structure are example application contracts. MCP does not define a universal catalog URI or require every documentation server to expose one.
A catalog’s contents should identify the resources it describes and explain their scope. A documentation hierarchy can list collection names and URIs; an issue overview can identify projects and summary resources; a schema catalog can identify the databases and tables represented. The host can include this compact orientation before asking Claude which detailed evidence it needs.
The resource declaration alone is not the catalog’s content. Metadata from listing and the actual returned text serve different purposes. A list can reveal that docs://catalog exists, while reading it supplies the index needed for the investigation.
List, read, and parameterize resources
A server supporting resources declares the resources capability. The client uses resources/list to discover entries and resources/read with a uri parameter to fetch content. Listing supports pagination, so a host should follow nextCursor when it needs a complete inventory rather than interpreting the first page as the whole catalog.
The following illustrative read addresses the catalog explicitly:
{
"jsonrpc": "2.0",
"id": 2,
"method": "resources/read",
"params": { "uri": "docs://catalog" }
}The server returns a contents array whose entries identify their uri and content representation, such as text with a mimeType. A JSON catalog can therefore travel as resource text; being structured content does not turn it into a tool call.
Servers can also expose parameterized resource templates through resources/templates/list. A uriTemplate describes how to address a family of resources rather than listing every possible concrete item. Templates are useful when a known identifier determines the resource address. A tool is still appropriate when an operation must search to discover an unknown identifier or perform an action.
Resource capabilities can optionally advertise subscribe and listChanged. notifications/resources/list_changed concerns changes to the available resource list, while subscriptions concern changes to particular resources. Do not assume that every resource server or host implements both. Declaring the base resources capability does not imply either optional feature.
Respect the host’s control model
The MCP specification describes resources as application-driven. The host decides how to incorporate them, for example through explicit selection, search, or automatic inclusion. It describes tools as model-controlled, with the model able to discover and invoke operations from the user’s request and available context. Neither description mandates one universal UI.
Claude Code supplies a concrete resource-selection surface. Typing @ shows resources from connected MCP servers alongside files. The reference format is @server:protocol://resource/path; when referenced, resource content is fetched and included as an attachment. For the example catalog server, @docs:docs://catalog identifies the server and URI separately.
Claude Code also provides ListMcpResourcesTool and ReadMcpResourceTool when resources are supported. Those host-provided tools let Claude request resource listing and reading. This does not reclassify the underlying resource as a server-defined operation: the resource still has a URI and the host still controls how the result enters context. “Application-controlled” does not mean that the model can never help select it.
MCP Apps UI resources are a special boundary. Claude Code excludes resources with ui:// URIs or the text/html;profile=mcp-app media type from @ suggestions and the resource-list tool’s results. They represent pages for a host to render. Reading one by URI still works, so an empty displayed list from a UI-only server does not prove that its protocol resource inventory is empty.
Keep catalog freshness separate from availability
A catalog describes an evidence set at a particular state. Reading the catalog supplies that description, not an automatic guarantee that every linked item is accessible or unchanged. Preserve the server’s scope and freshness information in the context you include, and obtain the required detailed resource before treating its contents as evidence.
Claude Code refreshes tools, prompts, and resources after list_changed in interactive terminal sessions. In claude -p and Agent SDK sessions, it refreshes only the tool list on those notifications. If your automated workflow depends on a refreshed resource inventory, do not assume the interactive refresh behavior applies there. Design the host’s context acquisition around what that execution mode actually supports.
Key distinctions and trade-offs
The following interfaces serve different decisions:
| Need | Interface | Deciding identifier |
|---|---|---|
| Include a known schema or catalog | Resource read | resources/read and uri |
| Discover resource addresses | Resource list or templates | resources/list, resources/templates/list |
| Search by unknown issue terms | Tool invocation | tools/call, tool name, and arguments |
| Change issue state | Action tool | Tool input and execution permissions |
A catalog can save exploratory calls by showing the available scope early. A large catalog can also consume unnecessary context. Prefer a compact orientation followed by targeted reads rather than attaching every available item. The resource interface supports this division without making all retrieval a catalog read.
The host orients Claude with the catalog first, and targeted reads and tool calls follow.
Architecture / decision scenario
A multi-agent research workflow investigates a schema migration’s operational impact. Without orientation, workers repeatedly ask search tools what projects, schemas, and documents exist.
The team exposes a compact schema catalog and a documentation hierarchy as resources. The host lists resources, reads the relevant catalog URI, and includes its scope in the assignment. A Claude Code operator can attach the catalog through @; an automated host uses the resource read path supported by its integration.
The agent then reads the identified schema and calls a search tool for unresolved issue discussions. If it needs to create a follow-up issue, that is a tool action with its own permission decision. The catalog supplies orientation rather than approval for the action. The team verifies automated freshness separately because the SDK does not refresh resource lists on notifications in the same way as interactive Claude Code.
Common exam traps
- Treating resource names as the URI required for reading.
- Assuming every configured server exposes resources or a catalog.
- Calling resources application-controlled and concluding that Claude cannot request a host resource-read tool.
- Treating the first page of
resources/listas a complete inventory. - Answering repeated exploratory calls with a larger context window or another search tool instead of a catalog resource.
- Assuming interactive resource refresh behavior applies to SDK runs.
Where the exam guide differs
The exam guide says catalogs give agents visibility into available data “without requiring exploratory tool calls.” In Claude Code, an @ reference attaches a resource without a model tool call, but when Claude consults a catalog on its own it calls ReadMcpResourceTool. The catalog removes the guessing calls, not every call. When an exam item describes an agent spending calls to learn what data exists, choose exposing a catalog as a resource.
The exam guide (version 1.0, effective July 2026, first drafted in February 2026) names no MCP revision; it was written while revision 2025-11-25 was the published specification. This lesson cites revision 2026-07-28, a later revision, and the differences between the two do not change what it teaches for the exam. Revision 2026-07-28 replaces resources/subscribe and resources/unsubscribe with subscriptions/listen, one long-lived stream for the change notifications a client opts in to; the optional subscribe and listChanged capability flags appear in both revisions.
What to remember
Resources supply URI-addressed context through a host-controlled inclusion path. Tools expose callable operations for retrieval and actions. Use catalogs to orient the workflow, then obtain the specific evidence it needs; discovery metadata, resource contents, action permissions, and freshness remain separate concerns.
Knowledge check
In a multi-agent research workflow, each worker begins by calling search tools with guessed terms to learn which databases and schemas exist, and workers still miss schemas. The schema set changes rarely. Which change best addresses the problem?
Which of these needs should an MCP tool, rather than a resource read, serve?
schema://orders/v3 in the conversation’s context@ mention@ attachment. A search over unknown terms is a parameterized operation the model requests, which is what a tool provides; a resource template helps only when a known identifier determines the address.A host calls resources/list on a documentation server, gets a response with entries and a nextCursor, and reports that the server has no runbooks collection. What is wrong with that conclusion?
nextCursorresources/list instead of calling tools/listname before declaring it missinglistChanged before the server could list everythingresources/list is paginated: a nextCursor means more entries exist, so absence from the first page proves nothing. Tools are listed separately from resources, a read takes the resource’s URI rather than its name, and listChanged is an optional notification about changes to the list, not a condition for listing it.An automated Agent SDK pipeline depends on its documentation server’s resource list. The server adds a collection and sends a list_changed notification. In interactive Claude Code the new collection appears, but the pipeline keeps working from the old list. What explains this?
subscribe before an SDK host refreshes its resource listlist_changed notification, including the tools’ onelist_changed , not the resource list@ mention before the SDK can see itlist_changed ; in claude -p and Agent SDK sessions it refreshes only the tool list. An automated pipeline that depends on a current resource inventory has to re-list or re-read resources itself. subscribe concerns updates to particular resources, and @ mentions are an interactive surface.References
- Model Context Protocol, Resources, protocol revision 2026-07-28
- Model Context Protocol, Tools, protocol revision 2026-07-28
- Anthropic, Connect Claude Code to tools via MCP
- Anthropic, Tools reference
- Model Context Protocol, Key Changes, protocol revision 2026-07-28
- Anthropic, Claude Certified Architect – Foundations Exam Guide