Почему в MCP промпт после вызова инструмента?

MCP разделяет роли: mcp инструмент возвращает только данные, а промпт формирует mcp сервер (или клиент) после выполнения tools/call — это даёт контроль над валидацией, безопасностью и контекстом. Такой порядок уменьшает связанность между инструментами, упрощает аудит и позволяет модели выбирать следующий шаг на основе валидного структурированного вывода. Встраивание текстового промпта в output инструмента технически возможно, но даёт риски (prompt‑injection, жёсткая связка логики и сложность переиспользования).

Содержание

• Почему в MCP промпт после вызова инструмента
• Можно ли включить промпт в вывод инструмента — плюсы и минусы
• Практические рекомендации для mcp сервер и mcp инструмент рабочих процессов
• Пример: split_task_raw → формирование next_step_prompt → execute_task
• Техническая реализация и практические замечания на mcp сервер
• Источники
• Заключение

Почему в MCP промпт после вызова инструмента

Зачем делать дополнительный шаг с промптом после tools/call, если результат инструмента уже содержит нужные параметры? Короткий ответ — разделение ответственности и контроль.

• Разделение обязанностей. В спецификации MCP инструмент возвращает результат как данные — либо текст, либо typed JSON в поле structuredContent — а не готовую инструкцию для модели. Такое разделение (tool → data, prompt → instruction) описано в официальной спецификации MCP и специально предназначено для упрощения трассировки и валидации Tools - Model Context Protocol.
• Валидация и безопасность. Клиент/сервер получает результат, проверяет его по outputSchema и только затем формирует промпт, подставляя чистые, проверенные значения. Это снижает риск prompt‑injection и уязвимостей, если инструмент работает с внешними источниками данных.
• Переиспользуемость инструментов. Если инструмент возвращает только данные, вы можете использовать его в разных сценариях: один и тот же split_task_raw подойдёт для разных стратегий планирования. Встроенный в вывод текстовый промпт жёстко привязывает инструмент к конкретной логике.
• Аудит и трассировка. Отдельные сообщения (tools/call → client → prompts/get → model) дают прозрачную историю: что было вызвано, что вернулось, какие правила применились перед отправкой следующего промпта. Это важно для отладки и соответствия политике.
• Гибкость агентного поведения. После получения результата модель (или контроллер) может решить разные пути: вызвать другой инструмент, попросить уточнение у пользователя, объединить несколько ответов и т.д. Если промпт вкладывать заранее — гибкость теряется.

Официальные разъяснения и практические кейсы от проектов-практиков подтверждают этот подход: подробные руководства и разборы приводят именно поток “tools/call → проверка → формирование промпта” как рекомендуемый паттерн Composio guide, обзорный материал.

Можно ли включить промпт следующего шага в вывод инструмента? Плюсы и минусы

Коротко: можно, но чаще не стоит. Разберём подробнее.

Плюсы такого подхода

• Меньше сообщений — одно возвращение содержит и данные, и инструкцию; кажется, что система проще и быстрее (меньше roundtrip).
• Быстрая прототипизация: для локальных экспериментов и «песочницы» такой трюк ускоряет разработку.

Минусы и риски

• Сильная связанность: инструмент становится не просто адаптером для данных, а носителем логики рабочего процесса. Это уменьшает повторное использование.
• Безопасность: текстовый промпт внутри output — потенциальный вектор prompt‑injection. Любые данные, полученные извне, могут превратиться в команды модели.
• Сложность валидации и тестирования: текст сложно валидировать по схеме, а значит вы теряете гарантии корректности формата аргументов для следующего инструмента.
• Непредсказуемость поведения: модель может интерпретировать встроенный текст неожиданно; поддерживать стабильное поведение сложнее.
• Несоответствие спецификации: официальная документация подчёркивает, что embedding промптов в ответ инструмента усложняет модульность и трассировку и потому не рекомендуется Model Context Protocol spec.

Когда embedding может быть оправдан

• Внутренние, доверенные системы для ускорения prototyping.
• Когда инструмент сам рассчитывает точные аргументы для следующего инструмента и возвращает их как строго типизированный объект (не как свободный текст). То есть вместо “встроенного промпта” лучше вернуть structuredContent: { suggested_call: { tool: “execute_task”, args: {…} } } — это уже данные, и их проще валидировать.

Итог: если вы хотите сократить шаги, возвращайте структурированные подсказки (JSON‑hint), а не готовый текстовый промпт. Так сохранится контроль и уменьшится риск.

Практические рекомендации для mcp сервер и mcp инструмент рабочих процессов

На практике несколько простых правил дают большую устойчивость и безопасность рабочего процесса.

1. Держите инструменты «тонкими» — они возвращают данные, а не политику исполнения.

• Формат результатов описывайте через outputSchema; используйте structuredContent для типизированных ответов.
• Проверьте isError и валидируйте схему перед формированием промпта.

2. Формируйте промпты на стороне клиента/сервера после валидации.

• Используйте шаблоны промптов (prompt templates) с явными плейсхолдерами. Храните версии шаблонов отдельно (ресурсы промптов), чтобы можно было отследить изменения.

3. Санитизируйте все свободные текстовые поля.

• Любые строки из внешних источников следует экранировать или вставлять в промпт как «данные» (в кавычках, в явном JSON), а не как инструкции.

4. Если нужно пропустить модельный шаг — возвращайте структурированные подсказки.

• Вместо текстового промпта можно вернуть suggested_call в формате JSON. Это позволит клиенту напрямую вызвать следующий инструмент, при этом сохранив валидацию и трассировку.

5. Логируйте цепочки вызовов.

• Записывайте tools/call, structuredContent, верификацию и итоговые промпты. Это полезно для отладки, соответствия требованиям и воспроизведения.

6. Весомая причина оставить промпт за моделью — гибкость.

• Если вы хотите, чтобы модель принимала агентные решения (выбор следующего шага, ветвление), давайте ей валидный структурированный результат и чёткие инструкции в промпте, а не жёстко закодированную последовательность.

Эти практики собраны из официальной спецификации и практических гайдов по MCP Model Context Protocol spec, Composio guide и разборов внедрений dailydoseofds.

Пример: split_task_raw → формирование next_step_prompt → execute_task

Ниже — пошаговая иллюстрация типичной цепочки.

1. Контекст: пользователь просит разбить задачу.
2. Модель генерирует вызов инструмента split_task_raw:

• model → tools/call { name: “split_task_raw”, arguments: { task: “…тут текст…” } }

3. Сервер выполняет инструмент и получает структурированный ответ:

{
 "result": {
 "structuredContent": {
 "tasks": [
 {"id":"t1","title":"Сбор требований","est_hours":2},
 {"id":"t2","title":"Прототип UI","est_hours":5}
 ]
 },
 "isError": false
 }
}

4. Сервер валидирует structuredContent по outputSchema и формирует промпт-шаблон:

Шаблон (next_step_prompt):
"У тебя есть список подзадач: {tasks}. Учитывая приоритет {priority} и лимит времени {limit_hours}, выбери следующую подзадачу и верни аргументы для вызова инструмента execute_task в виде JSON."

5. Сервер подставляет переменные и отправляет промпт модели (prompts/get или обычное сообщение). Модель возвращает либо текстовую инструкцию, либо напрямую генерирует tools/call для execute_task:

• model → tools/call { name: “execute_task”, arguments: { task_id: “t1”, mode: “detailed” } }

6. Сервер выполняет execute_task и продолжает цепочку.

Вариант без промпта: если split_task_raw умеет вычислять точные аргументы, оно может вернуть сразу:

{
 "structuredContent": {
 "suggested_call": {
 "tool": "execute_task",
 "args": {"task_id":"t1","mode":"detailed"}
 }
 }
}

Тогда сервер может напрямую вызвать execute_task. Но учтите: вы теряете контроль над моделью и гибкость ветвления.

Техническая реализация и практические замечания на mcp сервер

Нюансы, которые обычно всплывают при внедрении:

• Используйте outputSchema и strict JSON для критичных интеграций. Строки — плохо; структурированный JSON — хорошо.
• Всегда проверяйте isError и обрабатывайте частичные результаты или таймауты.
• Разделяйте права: не давайте инструменту, который работает с внешними данными, возможность возвращать необработанные инструкции для модели без премодерации.
• Логируйте цепочку вызовов и версий промптов; это облегчает воспроизведение инцидентов.
• Для параллельных инструментов собирайте их результаты и объединяйте в единый промпт, чтобы модель видела полную картину.
• При необходимости детерминизма: вместо того, чтобы полагаться на LLM для оркестрации, используйте контроллер (rules engine) на стороне сервера, который принимает структурированные результаты и решает, когда и как вызывать следующий инструмент.

Если нужна формальная спецификация механики вызовов и форматов — смотрите официальные заметки и спецификацию MCP, где подробно описаны поля result, structuredContent и поток tools/call → prompts/get Model Context Protocol spec. Также полезны практические примеры и разборы внедрений в блогах Composio и dailydoseofds.

Источники

• Официальная спецификация MCP — Tools - Model Context Protocol
• Практическое руководство по промптам, ресурсам и инструментам в MCP — Composio: How to effectively use prompts, resources, and tools in MCP
• Разбор рабочего процесса MCP и примеры — Building a Full-Fledged MCP Workflow
• Статья‑обзор и обсуждение в русском сообществе — Habr: Model Context Protocol (MCP): Стандартизация взаимодействия AI-приложений
• Объявление и миссия протокола от автора инициативы — Anthropic — Model Context Protocol

Заключение

Промпт после вызова инструмента в MCP — не случайная задержка, а сознательный архитектурный выбор: он сохраняет модулированность mcp инструментов, даёт контроль над валидацией и безопасностью на стороне mcp сервер и повышает гибкость агентного поведения. Если вам нужно сэкономить шаги — возвращайте структурированные подсказки (typed suggested_call), но помните о компромиссе между скоростью и контролем.