Agent Skills и MCP: как собрать один управляемый процесс

Как Agent Skills и MCP работают вместе?

В рабочей схеме Agent Skill описывает цель, порядок шагов, критерии качества и точки остановки, а MCP предоставляет типизированные tools, resources и иногда prompts для внешних систем. Это практическое разделение ответственности, а не правило стандартов. Разрешения, подтверждения и фактическое выполнение зависят от клиента, конфигурации и подключённого сервера.

Статья не отвечает повторно на вопрос, какой механизм выбрать вообще. Здесь задача уже известна: собрать один конкретный процесс, которому нужны и повторяемые инструкции, и доступ к внешним данным или действиям.

Общее сравнение механизмов находится в статье AGENTS.md, CLAUDE.md, SKILL.md и MCP.

Где провести границу ответственности?

Проводите границу по владению и изменчивости. В skill храните бизнес-порядок, критерии перехода, обработку ошибок и формат отчёта. В MCP tool оставляйте одну внешнюю операцию с валидируемыми аргументами и понятным результатом. Resources передают контекст, prompts дают пользовательские шаблоны, а клиент применяет собственную модель разрешений.

Как описать процесс до подключения MCP?

Сначала нарисуйте процесс без названий серверов: вход, шаги, решения, внешние данные, изменяющие действия, критерий готовности и fallback. Затем отметьте, где действительно нужен внешний вызов. Если начать с каталога tools, skill обычно превращается в демонстрацию возможностей интеграции, а не в решение задачи с измеримым результатом.

1. 1. Назовите результат

   Опишите файл, запись, решение или отчёт, который должен получить пользователь.

2. 2. Разложите шаги

   Отделите рассуждение и проверку от внешнего чтения и записи.

3. 3. Отметьте последствия

   Выделите действия, меняющие данные, права, деньги или коммуникацию.

4. 4. Добавьте fallback

   Опишите результат при недоступном server, пустом ответе или отказе пользователя.

5. 5. Определите evidence

   Зафиксируйте, что подтверждает успешное завершение каждого критичного шага.

Если основой служит существующий процесс, используйте руководство как превратить регламент в Agent Skill.

Каким должен быть контракт MCP tool?

Один tool должен выполнять одну понятную операцию, принимать минимальный набор типизированных аргументов и возвращать результат, который skill может проверить. Разделяйте read и write, не прячьте несколько необратимых действий за общим названием и не полагайтесь только на аннотации сервера. Фактические права определяются credential, реализацией и политикой клиента.

• Название описывает наблюдаемое действие, а не внутренний модуль.
• Input schema отмечает обязательные аргументы и явно запрещает лишние там, где это нужно; сервер валидирует вход до выполнения операции.
• Read не вызывает скрытую запись или отправку.
• Write возвращает идентификатор, статус и достаточное evidence.
• Ошибки различают недоступность, отказ в правах и неверный вход.
• Чувствительные поля не дублируются в лишние логи и ответы.

Перед подключением проверьте server по отдельному чек-листу MCP.

Где поставить подтверждения и ограничения?

Подтверждение ставят перед последствием, а не в начале длинной сессии. Чтение ограничивают нужным tenant, каталогом и набором полей; запись получает отдельный credential и узкую область. Skill должен подготовить понятный preview, но сам текст инструкции не заменяет техническую политику клиента, проверку server и решение пользователя.

Путь credential подробнее разобран в статье секреты и разрешения в Agent Skills.

Как работать с недоверенными данными из MCP?

Считайте содержимое tools и resources данными, а не продолжением инструкций skill. Не позволяйте тексту из письма, issue или страницы самостоятельно расширять права, выбирать следующий write-вызов или отменять подтверждение. Для чувствительного шага извлекайте только нужные поля, валидируйте их по схеме и показывайте человеку итоговое действие отдельно.

• Разделяйте инструкции процесса и внешнее содержимое.
• Ограничивайте объём передаваемых данных до нужных полей.
• Не исполняйте команды, найденные внутри resource.
• Повторно подтверждайте адресата, сумму, права или публикуемый текст.
• Сохраняйте источник данных, вызванный tool и наблюдаемый результат.

Отдельная модель угроз описана в материале indirect prompt injection в MCP-цепочке.

Как проверить связку Skill и MCP?

Тестируйте полный путь, а не только доступность tool. Нужны успешное чтение, пустой результат, отказ в правах, недоступный server, вредоносный текст в resource, отменённое подтверждение и успешная запись с проверкой конечного состояния. Сравните полученный результат с критериями skill и убедитесь, что fallback не маскирует ошибку как успех.

1. 1. Зафиксируйте тестовый tenant

   Не используйте рабочие записи и живых получателей.

2. 2. Проверьте read

   Сопоставьте возвращённые данные с правами и ожидаемой схемой.

3. 3. Проверьте отказ

   Сервер недоступен, аргумент неверен или credential не имеет права.

4. 4. Проверьте подтверждение

   Отмена не должна выполнять write или оставлять частичный результат.

5. 5. Проверьте состояние

   После write откройте целевую систему и сравните фактическое изменение.

Для оценки поведения skill используйте trigger-тесты, evals и evidence.

С какого интеграционного пилота начать?

Начните с одного процесса, одного доверенного MCP server и read-only сценария с полезным итоговым отчётом. Затем добавьте один ограниченный write только после проверки прав, preview, подтверждения, журналирования и отката. Пилот оценивают по качеству результата, числу ручных исправлений, ошибкам интеграции и соблюдению границ, а не по количеству доступных tools.

Хороший первый пилот легко остановить, проверить и повторить на тестовых данных. Если для результата нужно десять серверов и десятки write-операций, сначала сократите процесс или разделите его на независимые этапы.

Для проектирования ограниченного контура оставьте заявку на внедрение.