Resources (MCP)

Resources are one of the three core primitives a Model Context Protocol server can offer, alongside tools and prompts. A resource is a piece of data the server makes readable — a file's contents, a database record, a log, a cached API response — that the client can fetch and place into the model's context window.

Where tools let a model do things, resources let a session know things. They're the protocol's answer to "how does relevant data get in front of the model?"

Every resource has a URI — file:///home/user/notes.md, postgres://db/customers/42, or any scheme the server defines. Clients discover what's available via resources/list and fetch content with resources/read, getting back text or binary data with a declared MIME type.

Servers can also expose resource templates (parameterized URIs like weather://{city}/current) and emit notifications when a resource changes, letting clients keep loaded context fresh without polling.

The boundary is read versus act. Resources are typically read-only and take no arbitrary input arguments — you read what exists at a URI. Tools accept structured arguments, perform computation or side effects, and return results.

Control differs too: in the MCP design, resources are application-controlled — the client (often steered by the user) decides what to load into context — while tools are model-controlled, invoked when the LLM decides mid-task. The same underlying data could be exposed both ways; a server might offer a schema as a browsable resource and a run-query tool that acts on it.

Use resources when the value is the data itself and the user should choose what's relevant: project files, configuration, documentation pages, recent records. Use tools when the client needs to ask questions the server must compute answers to.

In practice many servers skip resources and expose everything as tools, because tool support is universal across MCP clients while resource UI support has historically been spottier. That's a pragmatic call, but it gives up the clean separation between loading context and taking action.

Per-call x402 monetization on platforms like Loomal attaches prices to tool calls, since a tool invocation is the natural billable event — the agent pays in USDC before the handler runs. For servers whose core value is data access, this nudges design: expose the chargeable lookup as a tool, and keep resources for the freely readable surrounding context like schemas and documentation.