MCP Resources Explained

An MCP resource is a piece of data a server shares as context for an AI model, such as a file, a database schema or a customer record. Each resource has a unique URI, like file:///project/src/main.rs. The client reads it with resources/read and decides how to use it.

Status in the 2026-07-28 spec: core. Resources are one of the three server features, with tools and prompts. A server opts in by declaring the resources capability.

The key difference from tools: resources are for reading context, and the host app decides when to use them. This page is based on the 2026-07-28 Resources page, checked on 28 October 2026.

What a resource is

The spec says resources "allow servers to share data that provides context to language models, such as files, database schemas, or application-specific information." Each one is "uniquely identified by a URI."

A resource definition has these fields:

• uri: the unique identifier.
• name: the resource name.
• title: an optional display name.
• description: optional text.
• mimeType: the optional content type, such as text/markdown.
• size: optional size in bytes.
• icons: optional images for the interface.

Contents are either text (a text field) or binary (a base64 blob field).

Why resources exist

Tools let a model act. Resources let an app give the model the right background. A coding assistant might attach a project's README. A support app might attach a customer's account record.

The spec calls resources application-driven. The host app decides how to use them. It might show a picker where users choose files, let users search and filter, or include context automatically based on heuristics or the model's choice. The spec does not require any specific interface.

If you are new to the three building blocks, read how MCP works and compare with MCP tools explained.

How it works

Listing resources

The client sends resources/list and gets back a page of resources, with caching hints:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "complete",
    "resources": [
      {
        "uri": "file:///project/src/main.rs",
        "name": "main.rs",
        "title": "Rust Software Application Main File",
        "description": "Primary application entry point",
        "mimeType": "text/x-rust"
      }
    ],
    "nextCursor": "next-page-cursor",
    "ttlMs": 300000,
    "cacheScope": "public"
  }
}

The list supports pagination through cursor and nextCursor. The ttlMs field says how many milliseconds the client may treat the result as fresh. The cacheScope says whether shared caches may store it (public) or only the same authorization context (private), per the caching page.

Reading a resource

The client sends resources/read with a URI. The server returns a contents array, which may hold several items. For example, reading a directory resource could return several files. A server may also return an input_required result if it needs user input first, following the multi-round-trip request pattern.

Templates and subscriptions

Parameterized resources, like file:///{path}, are listed through resources/templates/list. See MCP resource templates. Clients that want to know when a resource changes use subscriptions/listen. See MCP resource subscriptions.

Annotations

Resources, templates and content blocks can carry three optional annotations:

• audience: user, assistant or both.
• priority: 0.0 to 1.0, where 1 means effectively required.
• lastModified: an ISO 8601 timestamp.

Clients can use them to filter, prioritize or sort what goes into context.

URI schemes

The spec names a few standard schemes and allows custom ones that follow RFC 3986:

The https:// rule surprises people. If the client would still need the server to fetch the content, the spec says the server SHOULD use another scheme or a custom one.

What changed across spec versions

The error change is easy to miss. In 2026-07-28, a missing resource MUST return -32602 (Invalid Params). Clients SHOULD still accept -32002 from older servers. And servers MUST NOT return an empty contents array for a resource that does not exist, because that is ambiguous.

Common mistakes

1. Using resources for actions. Reading should not change anything. If it writes, sends or deletes, make it a tool.
2. Skipping path checks. Servers MUST sanitize file paths to prevent directory traversal on file:// resources. A request for ../../etc/passwd should fail.
3. Returning an empty array for a missing resource. Return the -32602 error.
4. Using https:// for content only the server can reach. Use a custom scheme instead.
5. Assuming every client shows resources. Support varies by app. Our guide to AI apps that support MCP covers what each client offers.

The spec's security list also says servers must validate all resource URIs and should check permissions before operations. See the MCP security center.

Next step

Most real servers expose more than a fixed list of files. Read MCP resource templates next, or return to the MCP specification reference.

Frequently asked questions