# Elicitation: вопрос пользователю

> Elicitation в MCP 2026-07-28 - как сервер запрашивает данные у пользователя, режимы form и url, три варианта ответа, запрет на секреты в форме и правила работы со ссылками

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

Elicitation - способ, которым сервер через клиента спрашивает что-то у пользователя прямо во время выполнения запроса. Режимов два: `form` - клиент показывает форму, и ответ проходит через него; `url` - пользователь переходит по ссылке, и данные идут мимо клиента.

Пароли, ключи и платёжные данные запрашивать формой запрещено: для них есть режим `url`.

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

Источник - страница [Elicitation](https://modelcontextprotocol.io/specification/2026-07-28/client/elicitation) спецификации.

## Как это устроено в редакции 2026-07-28

Сервер не отправляет вопрос отдельным запросом. Он возвращает результат «нужны данные», внутри которого лежит `elicitation/create`, а клиент присылает ответ в повторе исходного запроса. Весь порядок описан на странице [«Многошаговые запросы»](https://mcpdoc.ru/protocol/mrtr/).

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

Клиент, который умеет задавать вопросы пользователю, объявляет возможность `elicitation` в `_meta` каждого запроса.

```json
{
  "_meta": {
    "io.modelcontextprotocol/clientCapabilities": {
      "elicitation": { "form": {}, "url": {} }
    }
  }
}
```

Пустой объект `"elicitation": {}` означает поддержку только режима `form`. Сервер не должен использовать режим, который клиент не объявил.

## Общие параметры вопроса

| Параметр | Значение |
|---|---|
| `mode` | `form` или `url`; если не указан, считается `form` |
| `message` | понятное человеку объяснение, зачем нужны данные |

## Режим form

Сервер присылает схему ожидаемого ответа в параметре `requestedSchema`.

```json title="Вопрос"
{
  "method": "elicitation/create",
  "params": {
    "mode": "form",
    "message": "Please provide your GitHub username",
    "requestedSchema": {
      "type": "object",
      "properties": { "name": { "type": "string" } },
      "required": ["name"]
    }
  }
}
```

```json title="Ответ клиента"
{
  "action": "accept",
  "content": { "name": "octocat" }
}
```

Схема намеренно ограничена: только плоский объект с простыми полями. Вложенные объекты и списки объектов не поддерживаются.

| Тип поля | Что можно задать |
|---|---|
| строка | длину, формат (`email`, `uri`, `date`, `date-time`), значение по умолчанию |
| число или целое | минимум, максимум, значение по умолчанию |
| логическое | значение по умолчанию |
| выбор одного | перечень значений, с подписями или без |
| выбор нескольких | список из перечня, с ограничением количества |

## Режим url

Сервер присылает ссылку. Пользователь открывает её и вводит данные на странице, которой доверяет. Клиент видит только саму ссылку.

```json title="Вопрос"
{
  "method": "elicitation/create",
  "params": {
    "mode": "url",
    "url": "https://mcp.example.com/ui/set_api_key",
    "message": "Please provide your API key to continue."
  }
}
```

```json title="Ответ клиента"
{ "action": "accept" }
```

Ответ `accept` здесь значит только согласие открыть ссылку. Чем закончилось действие на странице, клиент не знает. Он повторяет исходный запрос, и сервер сам решает: вернуть итог или снова ответить «нужны данные».

Режим `url` появился в редакции `2025-11-25`. Спецификация отдельно предупреждает, что его устройство может поменяться в следующих редакциях. В `2026-07-28` из него убраны уведомление `notifications/elicitation/complete` и поле `elicitationId`.

Режим `url` не служит для доступа клиента к самому серверу MCP - этим занимается [авторизация](https://mcpdoc.ru/auth/). Он нужен, когда серверу требуются секреты пользователя или разрешение в стороннем сервисе.

## Три варианта ответа

| Действие | Что произошло | Поле `content` |
|---|---|---|
| `accept` | пользователь согласился и отправил данные | в режиме `form` - данные; в режиме `url` - отсутствует |
| `decline` | пользователь явно отказался | обычно отсутствует |
| `cancel` | пользователь закрыл окно, не выбрав | обычно отсутствует |

Серверу не следует рассчитывать, что вопрос всегда получит ответ. Отказ и отмену он обязан обрабатывать.

## Требования к серверу

- Формой нельзя запрашивать пароли, ключи API, токены и платёжные данные. Для них обязателен режим `url`.
- Имя, почту и другие обычные сведения запрашивать формой не запрещено.
- Вопрос обязан быть привязан к клиенту и пользователю.
- Нельзя полагаться на сведения о личности пользователя, полученные от клиента, без собственной проверки. Пример из спецификации: ответ «я joe@example.com» ничего не доказывает, личность определяется через [авторизацию](https://mcpdoc.ru/auth/).
- В ссылке не должно быть чувствительных сведений о пользователе (учётных и персональных данных) и готового доступа к защищённому ресурсу.
- Сервер обязан убедиться, что ссылку открыл тот же пользователь, для которого она создана. Иначе возможна подмена: ссылку передают другому человеку, и его разрешение привязывается к чужой учётной записи.
- Учётные данные стороннего сервиса не должны проходить через клиента и не должны ему передаваться.

## Требования к клиенту

- Показывать, какой сервер задаёт вопрос.
- Давать понятные варианты «отказаться» и «отменить».
- В режиме `form` - позволить просмотреть и исправить ответ до отправки.
- В режиме `url`: не загружать ссылку заранее, не открывать без явного согласия, показывать адрес целиком и открывать так, чтобы ни клиент, ни модель не видели содержимое страницы и ввод пользователя.
- Не следует делать нажимаемыми ссылки из других полей вопроса: это рекомендация, остальные пункты списка - требования.

## Что читать дальше

- [Многошаговые запросы](https://mcpdoc.ru/protocol/mrtr/) - как вопрос попадает к клиенту и возвращается.
- [Модель доверия](https://mcpdoc.ru/security/best-practices/) - почему ответ пользователя нельзя считать проверенным.