# Resources: ресурсы

> Ресурсы MCP в редакции 2026-07-28 - resources/list, resources/read и шаблоны адресов, подсказки для кэша, уведомления об изменениях, ошибки и требования безопасности

Страница: https://mcpdoc.ru/protocol/resources/
Указатель сайта: https://mcpdoc.ru/llms.txt

Ресурс - данные, которые сервер отдаёт как контекст: файл, схема базы, запись приложения. У каждого ресурса есть адрес (URI). Клиент получает список запросом `resources/list` и читает содержимое запросом `resources/read`.

описана редакция 2026-07-28, сверено со спецификацией 4 октября 2026

Источник - страница [Resources](https://modelcontextprotocol.io/specification/2026-07-28/server/resources) спецификации. В примерах для краткости опущено поле `_meta`; в настоящем запросе оно [обязательно](https://mcpdoc.ru/protocol/stateless/).

## Кто решает, что попадёт в контекст

Ресурсами управляет приложение. Хост сам решает, как показывать их и когда подставлять в контекст: списком для выбора, поиском или автоматически. Протокол способ не предписывает.

## Объявление возможности

Сервер с ресурсами обязан объявить возможность `resources`. У неё два необязательных признака.

```json
{
  "capabilities": {
    "resources": { "listChanged": true, "subscribe": true }
  }
}
```

| Признак | Что означает |
|---|---|
| `listChanged` | сервер сообщит, когда изменится список ресурсов |
| `subscribe` | сервер умеет сообщать об изменении отдельных ресурсов |

## Список

```json title="Запрос"
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "resources/list",
  "params": {}
}
```

Каждый ресурс в ответе описан полями:

| Поле | Что это |
|---|---|
| `uri` | уникальный адрес ресурса |
| `name` | имя |
| `title` | необязательное название для показа человеку |
| `description` | необязательное описание |
| `mimeType` | необязательный MIME-тип |
| `size` | необязательный размер в байтах |
| `icons` | необязательные значки |

Как и [список инструментов](https://mcpdoc.ru/protocol/tools/), список ресурсов не зависит от соединения, но может зависеть от прав, с которыми пришёл запрос. Запрос поддерживает постраничную выдачу.

## Чтение

```json title="Запрос"
{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "resources/read",
  "params": { "uri": "file:///project/src/main.rs" }
}
```

```json title="Ответ"
{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "resultType": "complete",
    "contents": [
      {
        "uri": "file:///project/src/main.rs",
        "mimeType": "text/x-rust",
        "text": "fn main() {\n    println!(\"Hello world!\");\n}"
      }
    ],
    "ttlMs": 60000,
    "cacheScope": "private"
  }
}
```

Содержимое бывает текстовым (поле `text`) или двоичным (поле `blob`, данные в Base64). На один запрос сервер может вернуть несколько элементов, например файлы каталога.

Сервер может ответить и просьбой о дополнительных данных - см. [«Многошаговые запросы»](https://mcpdoc.ru/protocol/mrtr/).

## Шаблоны адресов

Запрос `resources/templates/list` возвращает шаблоны по [RFC 6570](https://datatracker.ietf.org/doc/html/rfc6570) - адреса с параметрами, например `file:///{path}`. Клиент подставляет значения и читает получившийся адрес обычным `resources/read`.

## Подсказки для кэша

Результаты `resources/list`, `resources/templates/list` и `resources/read` обязаны нести два поля из раздела [Caching](https://modelcontextprotocol.io/specification/2026-07-28/server/utilities/caching).

| Поле | Значение |
|---|---|
| `ttlMs` | сколько миллисекунд клиент может считать результат свежим; `0` - сразу устаревает |
| `cacheScope` | `"public"` - в ответе нет данных конкретного пользователя, его может хранить общий кэш; `"private"` - кэш нельзя делить между разными учётными данными |

Срок жизни - подсказка, а не гарантия: данные могут измениться раньше. И это не интервал опроса: клиент проверяет свежесть, когда данные ему понадобились.

`cacheScope` не заменяет разграничение доступа. Сервер обязан проверять права на каждый ресурс сам.

## Уведомления об изменениях

| Уведомление | Когда приходит |
|---|---|
| `notifications/resources/list_changed` | изменился список ресурсов |
| `notifications/resources/updated` | изменился ресурс, за которым клиент следит |

Чтобы следить за ресурсами, клиент открывает поток запросом `subscriptions/listen` и перечисляет в нём адреса. Отдельных запросов `resources/subscribe` и `resources/unsubscribe` в редакции `2026-07-28` нет: поток `subscriptions/listen` их заменил.

## Аннотации

Ресурсы, шаблоны и блоки содержимого могут нести подсказки для клиента.

| Аннотация | Значение |
|---|---|
| `audience` | для кого содержимое: `"user"`, `"assistant"` или оба |
| `priority` | важность от 0.0 до 1.0 |
| `lastModified` | время последнего изменения в формате ISO 8601 |

## Схемы адресов

| Схема | Назначение |
|---|---|
| `https://` | ресурс, который клиент может загрузить из сети сам, без сервера MCP |
| `file://` | ресурс, похожий на файл; настоящей файловой системы за ним может не быть |
| `git://` | работа с системой контроля версий Git |
| своя схема | разрешена, если соответствует [RFC 3986](https://datatracker.ietf.org/doc/html/rfc3986) |

Схему `https://` серверу следует использовать только тогда, когда клиент действительно может получить ресурс напрямую.

## Ошибки

| Ситуация | Код |
|---|---|
| ресурс не существует | `-32602` |
| внутренняя ошибка | `-32603` |

До редакции `2026-07-28` для отсутствующего ресурса использовался код `-32002`. Клиенту следует принимать и его, чтобы работать со старыми серверами.

Пустой список `contents` для несуществующего ресурса возвращать нельзя: он неотличим от ресурса без содержимого.

## Требования безопасности

- Сервер обязан проверять все адреса ресурсов.
- Сервер обязан очищать пути файлов, чтобы запрос не вышел за пределы разрешённого каталога.
- Двоичные данные обязаны быть корректно закодированы.
- Для чувствительных ресурсов следует разграничивать доступ и проверять права перед операцией.