Промпты (prompts) в MCP

Промпт (prompt) в Model Context Protocol (MCP) - шаблон сообщений для языковой модели, который предлагает сервер и явно выбирает пользователь. Клиент узнаёт о промптах через prompts/list, заполняет их аргументы и получает готовые сообщения через prompts/get. Затем хост добавляет эти сообщения в диалог с моделью.

Промпты - один из трёх примитивов сервера, наряду с инструментами (tools) и ресурсами (resources). Они входят в спецификацию с её первой версии, 2024-11-05. Текущая версия спецификации - 2026-07-28; протокол развивается в Agentic AI Foundation, входящем в Linux Foundation. Основные понятия MCP (хост, клиент, сервер, примитивы) описаны в статье Что такое MCP.

Кратко

Какую задачу решают промпты

Автор сервера лучше всех знает, как пользоваться его инструментами и данными. Пользователь ИИ-приложения обычно этого не знает. Без стандартного механизма пользователь пишет инструкции к каждой задаче сам, а знание о том, как работать с сервером, остаётся в его документации.

Промпты переносят эти инструкции в сам сервер. Автор сервера публикует готовые шаблоны для типовых задач своей области, например для ревью кода или сводки по встречам. Документация MCP называет два назначения промптов: параметризованные промпты для предметной области и демонстрация того, как лучше всего использовать сервер.

Промпты - часть протокола, поэтому один и тот же шаблон работает в любом хосте, который их поддерживает. Хост получает список промптов во время работы, показывает его пользователю и запрашивает значения аргументов. Сервер возвращает готовые сообщения, и хосту не нужно знать, как устроен шаблон.

История

В таблице - изменения промптов от версии к версии спецификации.

Как работают промпты

Возможность сервера

Сервер, который предлагает промпты, объявляет возможность (capability) prompts в результате server/discover. Необязательный флаг listChanged означает, что сервер отправляет уведомления, когда меняется его список промптов.

{
  "capabilities": {
    "prompts": {
      "listChanged": true
    }
  }
}

Сервер, объявивший эту возможность, обязан отвечать на prompts/list списком промптов, доступных клиенту в данный момент. Список может быть пустым и может меняться со временем. Он не должен зависеть от соединения или от отправленных ранее запросов. Зависеть от авторизации запроса он может, например от прав (scopes) токена: учётные данные - часть каждого запроса. Клиент, который вызывает prompts/list у сервера без этой возможности, получает ошибку JSON-RPC -32601 (Method not found).

Список промптов

Клиент запрашивает список промптов методом prompts/list. Как и в любом запросе версии 2026-07-28, поле _meta содержит версию протокола, данные о клиенте и его возможности. Список выдаётся постранично: если в результате есть nextCursor, клиент передаёт его как cursor в следующем запросе.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "prompts/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "example-client", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "complete",
    "prompts": [
      {
        "name": "code_review",
        "title": "Request Code Review",
        "description": "Asks the LLM to analyze code quality and suggest improvements",
        "arguments": [
          { "name": "code", "description": "The code to review", "required": true },
          { "name": "language", "description": "Programming language of the code" }
        ],
        "icons": [
          { "src": "https://example.com/review-icon.svg", "mimeType": "image/svg+xml", "sizes": ["any"] }
        ]
      }
    ],
    "ttlMs": 600000,
    "cacheScope": "public"
  }
}

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

• name: идентификатор промпта, уникальный в пределах сервера. Клиент указывает его в prompts/get.
• title: необязательное отображаемое имя для интерфейса. Если его нет, хост показывает name.
• description: необязательное описание того, что делает промпт.
• icons: необязательные значки для интерфейса, у каждого URI источника и необязательные тип MIME, размеры и тема.
• arguments: необязательный список аргументов.
• _meta: необязательные метаданные.

Аргументы

Аргумент промпта - именованный параметр, который пользователь заполняет до того, как сервер соберёт сообщения. У аргумента есть name, необязательные title и description и необязательный флаг required. Аргумент без required: true необязателен.

JSON Schema у аргументов промпта нет. В prompts/get клиент передаёт их объектом arguments, где каждое значение - строка. Числа, даты и списки тоже передаются строками, а сервер сам их разбирает. У инструментов иначе: их параметры описаны JSON Schema в inputSchema, см. статью Инструменты (tools) в MCP.

Серверу следует проверять аргументы, прежде чем собирать промпт. Отсутствие обязательного аргумента и неизвестное имя промпта возвращаются ошибкой JSON-RPC -32602 (Invalid params).

Автодополнение аргументов

Автодополнение аргументов (completion) - механизм, через который сервер предлагает значения аргумента, пока пользователь его вводит. Он определён отдельным вспомогательным механизмом спецификации и работает для аргументов промптов и для параметров шаблонов ресурсов. Сервер, который его поддерживает, объявляет возможность completions.

Клиент отправляет completion/complete со ссылкой на промпт (ref/prompt и имя промпта), именем аргумента и уже введённым значением. Если у промпта несколько аргументов, клиент может передать уже выбранные значения в context.arguments, чтобы сервер сузил варианты. В примерах ниже поле _meta для краткости опущено, как и на страницах самой спецификации.

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "completion/complete",
  "params": {
    "ref": { "type": "ref/prompt", "name": "code_review" },
    "argument": { "name": "language", "value": "py" }
  }
}

{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "resultType": "complete",
    "completion": {
      "values": ["python", "pytorch", "pyside"],
      "total": 10,
      "hasMore": true
    }
  }
}

Сервер возвращает не больше 100 значений, упорядоченных по релевантности. Необязательное поле total сообщает число всех совпадений, а hasMore - есть ли значения сверх тех, что вошли в ответ. Спецификация рекомендует серверам сортировать варианты по релевантности и ограничивать частоту запросов автодополнения. От клиентов ожидается, что они не отправляют запрос на каждое нажатие клавиши и кешируют результаты, где это уместно.

Получение промпта

Когда пользователь выбрал промпт и заполнил аргументы, клиент отправляет prompts/get с именем промпта и значениями:

{
  "jsonrpc": "2.0",
  "id": 3,
  "method": "prompts/get",
  "params": {
    "name": "code_review",
    "arguments": {
      "code": "def hello():\n    print('world')",
      "language": "python"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "example-client", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

{
  "jsonrpc": "2.0",
  "id": 3,
  "result": {
    "resultType": "complete",
    "description": "Code review prompt",
    "messages": [
      {
        "role": "user",
        "content": {
          "type": "text",
          "text": "Please review this Python code:\ndef hello():\n    print('world')"
        }
      }
    ]
  }
}

Результат содержит необязательное описание description и массив messages. На транспорте Streamable HTTP клиент дополнительно передаёт имя промпта в заголовке Mcp-Name, чтобы шлюзы могли маршрутизировать запрос, не разбирая тело. Заголовки описаны в статье Транспорты MCP.

Сообщения промпта и типы содержимого

Сообщение промпта - один элемент массива messages: роль role и один блок содержимого content. Роль - user или assistant. Поэтому промпт может содержать сообщения не только от имени пользователя, но и от имени модели.

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

Встроенный ресурс (embedded resource) помещает содержимое ресурса сервера прямо в сообщение: документацию, пример кода, файл конфигурации. Ссылка на ресурс (resource link) только называет ресурс по URI, а клиент решает, читать ли его через resources/read. Все типы содержимого поддерживают необязательные аннотации, например предполагаемую аудиторию и приоритет. Ответ из двух сообщений, текстовой инструкции и встроенного файла, выглядит так:

{
  "jsonrpc": "2.0",
  "id": 4,
  "result": {
    "resultType": "complete",
    "messages": [
      {
        "role": "user",
        "content": { "type": "text", "text": "Review the following file for correctness and style." }
      },
      {
        "role": "user",
        "content": {
          "type": "resource",
          "resource": {
            "uri": "file:///project/src/main.rs",
            "mimeType": "text/x-rust",
            "text": "fn main() {\n    println!(\"Hello\");\n}"
          }
        }
      }
    ]
  }
}

Спецификация определяет формат сообщений. Как именно хост вставляет их в диалог с моделью, она не определяет.

Промпты, которым нужны дополнительные данные

С версии 2026-07-28 сервер может ответить на prompts/get не сообщениями, а результатом InputRequiredResult. Это механизм Multi Round-Trip Requests (MRTR), многоэтапные запросы: сервер перечисляет в inputRequests, чего ему не хватает, например вопрос пользователю через elicitation. Клиент собирает ответы и повторяет prompts/get с inputResponses и, если сервер его передал, неизменённым requestState. Механизм одинаков для инструментов, ресурсов и промптов и описан в статье MCP без состояния.

Ошибки

Для промптов спецификация рекомендует стандартные ошибки JSON-RPC:

Кто вызывает промпт

Промпты управляются пользователем (user-controlled): сервер предоставляет их для того, чтобы пользователь выбирал их явно. Спецификация уточняет, что речь о том, кто решает, когда использовать промпт, а не о том, кто пишет его содержимое. Содержимое определяет сервер.

Типичным примером спецификация называет слеш-команды: пользователь вводит / и видит доступные промпты. Документация MCP перечисляет и другие варианты: палитру команд с поиском, отдельные кнопки для частых промптов и контекстные меню. Конкретный интерфейс протокол не предписывает.

В Visual Studio Code, согласно его документации, промпт сервера вызывается вводом /<server>.<prompt> в чате. В общем виде последовательность в хосте такая:

1. Хост запрашивает prompts/list у подключённых серверов и показывает промпты пользователю.
2. Пользователь выбирает промпт. Хост запрашивает значения его аргументов и может использовать completion/complete для подсказок.
3. Хост отправляет prompts/get и получает сообщения.
4. Хост добавляет сообщения в диалог, и модель на них отвечает. При ответе модель может вызывать инструменты того же или других серверов.

Этим промпты отличаются от инструментов, которые выбирает сама модель, и от ресурсов, которые к контексту добавляет приложение.

Изменения списка и кеширование

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

Серверу, объявившему listChanged: true, следует уведомлять клиентов об изменении списка промптов. С версии 2026-07-28 уведомления приходят только тем клиентам, которые их запросили. Клиент открывает долгоживущий поток subscriptions/listen и указывает в фильтре promptsListChanged: true:

{
  "jsonrpc": "2.0",
  "id": 5,
  "method": "subscriptions/listen",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "example-client", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": {}
    },
    "notifications": { "promptsListChanged": true }
  }
}

Сначала сервер подтверждает подписку уведомлением notifications/subscriptions/acknowledged. После этого каждое изменение списка приходит уведомлением с идентификатором подписки, который равен id запроса subscriptions/listen:

{
  "jsonrpc": "2.0",
  "method": "notifications/prompts/list_changed",
  "params": {
    "_meta": { "io.modelcontextprotocol/subscriptionId": 5 }
  }
}

Данных об изменении уведомление не несёт. Клиент заново запрашивает prompts/list.

Подсказки для кеширования

С версии 2026-07-28 результат prompts/list обязан содержать две подсказки для кеширования:

• ttlMs: сколько миллисекунд клиент может считать результат актуальным. Это подсказка, а не гарантия, что список не изменится.
• cacheScope: кто может использовать результат повторно. public означает, что в результате нет данных конкретного пользователя и общие шлюзы и прокси могут отдавать его любому пользователю. private означает, что результат можно использовать повторно только в том же контексте авторизации.

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

Типовые сценарии

Спецификация и документация MCP приводят такие виды промптов:

• Шаблоны задач предметной области. Примеры из документации: ревью кода, планирование отпуска, сводка по встречам, черновик письма.
• Демонстрация сервера. Промпт показывает, как задумано использовать сервер, и пользователю не нужно сначала изучать его инструменты.
• Промпты с контекстом. Промпт встраивает ресурс или ссылается на него, например на файл для ревью или документацию API.
• Последовательности действий. Промпт направляет модель на совместное использование ресурсов и инструментов. В документации после промпта «Plan a vacation» модель читает календарь и историю поездок, которые добавил пользователь, а затем вызывает инструменты для поиска рейсов и бронирования отеля.

Безопасность

Спецификация требует проверять все входные и выходные данные промптов, чтобы не допустить атак через внедрение и несанкционированного доступа к ресурсам. Текст промпта приходит от сервера и попадает в контекст модели, обычно как сообщения с ролью user. Поэтому промпт от недоверенного сервера - канал для prompt injection: инструкций, которые пользователь не писал и может не увидеть. Атака и её тестирование описаны в статье Prompt injection.

У автодополнения аргументов свои требования. Реализации обязаны проверять входные данные автодополнения, ограничивать частоту запросов и контролировать доступ к чувствительным вариантам, чтобы автодополнение не раскрывало данные. Общие риски MCP описаны в статье Безопасность MCP.

Промпты, инструменты и ресурсы

Три примитива сервера различаются тем, кто решает их использовать и что они возвращают. Сравнение - в таблице.

Промпт сам не выполняет действий и не поставляет данные. Он подготавливает диалог: даёт модели инструкции, встраивает ресурсы и может указать модели, какими инструментами пользоваться. Инструменты - средство действовать, ресурсы - средство читать данные. Они описаны в статьях Инструменты (tools) в MCP и Ресурсы и шаблоны ресурсов.

Три примитива используют вместе. В примере из документации MCP пользователь вызывает промпт, добавляет ресурсы, а затем модель вызывает инструменты нескольких серверов. Промпт ставит задачу, ресурсы дают контекст, инструменты выполняют действия.

Навыки агента (agent skills) - тоже инструкции для модели, но в MCP они построены не на промптах. Официальное расширение Skills (io.modelcontextprotocol/skills) отдаёт навыки через примитив ресурсов и добавляет методы skills/list и skills/get. В отличие от промпта, навык может выбрать как модель, так и пользователь. Расширения описаны в статье Расширения MCP.

Термины

Источники

• Prompts, спецификация 2026-07-28(откроется в новой вкладке) (на английском)
• Completion, спецификация 2026-07-28(откроется в новой вкладке) (на английском)
• Caching, спецификация 2026-07-28(откроется в новой вкладке) (на английском)
• Subscriptions, спецификация 2026-07-28(откроется в новой вкладке) (на английском)
• Обзор возможностей сервера, спецификация 2026-07-28(откроется в новой вкладке) (на английском)
• Ключевые изменения 2026-07-28(откроется в новой вкладке) (на английском)
• Схема MCP 2026-07-28 (schema.ts)(откроется в новой вкладке) (на английском)
• Understanding MCP servers, документация MCP(откроется в новой вкладке) (на английском)
• Обзор расширения Skills(откроется в новой вкладке) (на английском)
• Add MCP servers in VS Code, документация Visual Studio Code(откроется в новой вкладке) (на английском)