What are MCP Resources?

How MCP Resources work

A resource is anything the MCP server exposes under a URI that the client can read. A filesystem server might expose file:///path/to/file. A database server might expose schema://users or table://users/columns. A docs server might expose docs://introduction and docs://api/auth. The client lists available resources, the user or application selects which to load, and the server returns the content. No model decision is required to fetch a resource. That is the design difference from tools, which the model decides to call.

Resources can be static or dynamic. A static resource always returns the same content. A dynamic resource is parameterized through a URI template, so users://{id}/profile lets the client request any user’s profile under the same resource definition. Servers can also send notifications/resources/list_changed so a connected client refreshes the available resource list when state changes server-side.

Why MCP Resources matter for context engineering

Every tool an MCP server declares ships its name, description, and JSON-schema arguments into the host’s system prompt for every model turn the server is mounted. Ten servers with twenty tools each can cost thousands of tokens before the model has done anything. That is the tool-bloat problem the harness ecosystem keeps trying to fix with selection, gating, and tool search at the client layer.

Resources solve the same problem at the protocol layer. They do not cost context on every turn. They cost context only when explicitly loaded. For reference data, that is almost always the right contract.

Common misconceptions about MCP Resources

• “Resources are just static files.” They can be. They can also be dynamic, parameterized through URI templates, and updated via subscription notifications. The protocol does not constrain the implementation.
• “If I want the model to use it, I need a tool.” Not true. Most MCP clients let the user @-mention a resource into the conversation, so the model receives the content as context. The model does not need to call the resource, the user (or the application’s logic) loads it.
• “Resources duplicate what Tools already do.” They handle different problems. Tools are verbs (actions, parameters, side effects). Resources are nouns (addressable, read-only content). A well-designed MCP server uses both.

MCP Resources and Wire

Each Wire container is exposed as a remote MCP server. The container’s five named tools handle the active surface (search, navigate, write, delete, analyze), while the underlying entries are also addressable as resources, so a host can load specific entries directly without going through a tool call. The behavior worth noting is that the same per-container state is reachable through both tool-driven and resource-style access, so agents pay full-context cost only when they actually navigate.