Практические подходы к разработке инструментов для Model Context Protocol. Почему прямой экспорт API приводит к ошибкам агентов и как контекстная инженерия решает эту проблему.
3 мин
Специалисты Amazon Web Services опубликовали подробный разбор типичных ошибок при проектировании инструментов для протокола контекста моделей (Model Context Protocol, MCP). Главный вывод заключается в том, что низкая производительность MCP-инструментов редко связана с самим протоколом. Чаще всего проблема кроется в архитектуре: разработчики просто открывают доступ к существующему программному интерфейсу (API) и ожидают, что агент сам разберется с его использованием. Для сложных систем такой подход не работает.
Исторически сложилось так, что API создавались для детерминированных программных систем. Когда разработчики начали подключать большие языковые модели (LLM) к внешним данным, самым очевидным шагом казался прямой перенос существующих интерфейсов. Однако модели воспринимают информацию иначе. Если не адаптировать инструменты под специфику работы LLM, система столкнется с ошибками вызова, неверными параметрами и бесконечными повторными попытками, которые сжигают контекст.
Исследователи выделяют две фундаментальные проблемы, ведущие к сбоям: раздувание контекста (bloat) и путаницу (confusion). Раздувание происходит из-за того, что описания инструментов загружаются в контекст модели при каждом вызове, даже если они не используются. Если подключено несколько серверов MCP, значительная часть окна контекста заполняется еще до того, как пользователь задаст первый вопрос. По мере заполнения контекста способность модели к рассуждению снижается.
Kiro CLI showing fractions assessment search results from the v2-descriptions agent, with the /agent swap v3-schema command being entered
Путаница возникает как следствие ухудшения логики и избытка информации. Модель начинает выбирать неправильные инструменты или подставлять некорректные параметры. Попытки исправить ошибку через дополнительные инструкции в описании часто создают замкнутый круг: более подробные описания снижают путаницу, но усугубляют раздувание контекста.
Для решения этого конфликта AWS предлагает применять методы контекстной инженерии (context engineering). Это процесс управления тем, что именно видит модель и в какой момент времени.
Первый шаг — оптимизация схем и ограничений. Вместо того чтобы полагаться на способность LLM угадать нужный формат, необходимо использовать строгие ограничения схемы: перечисления (enums) и значения по умолчанию. Параметры следует переименовывать так, чтобы они соответствовали предметной области, понятной модели, а не внутренним названиям столбцов в базе данных. Рекомендуется оставлять не более восьми параметров для одного инструмента.
Kiro context view for the v1-passthrough agent showing 4% context used, broken down by agent files, tools, Kiro responses, and prompts
Второй подход — ленивая загрузка (lazy loading). Вместо передачи всех описаний сразу, создается отдельный инструмент обнаружения. Сложные инструменты подгружаются в контекст только по запросу. По данным исследований Anthropic, загрузка определений только в релевантных случаях может сократить потребление токенов на 85%.
Третий метод — серверный логический вывод (server-side inference). Разработчик не всегда может контролировать, какая именно LLM будет вызывать его MCP-сервер на стороне клиента. Описание, идеальное для одной модели, может запутать другую. Решением становится добавление инструмента интроспекции, который использует небольшую, быструю модель на стороне сервера. Клиент передает запрос на естественном языке, а серверная модель переводит его в точные параметры для внутреннего API.
Переход к контекстной инженерии означает сдвиг парадигмы в разработке интеграций для искусственного интеллекта. Создание инструментов для LLM требует балансировки между полнотой информации и экономией токенов.
В ближайшем будущем мы, вероятно, увидим стандартизацию паттернов проектирования для MCP. Простые трансляторы API уступят место полноценным агентным инструментам (agentic tools), где сервер MCP будет не просто передавать данные, но и самостоятельно интерпретировать намерения пользователя, управляя всем циклом взаимодействия скрыто от клиентского приложения.
Kiro context view for the v2-descriptions agent showing 3% context used, with tools consuming a larger share than in V1
Kiro context view for the v4-lazy agent showing 2% context used, the leanest baseline of the versions
Прямой перенос традиционных API в среду MCP неэффективен. Для корректной работы LLM необходимо проектировать инструменты с учетом ограничений контекста, используя методы контекстной инженерии.
Использование дополнительной, небольшой LLM на стороне сервера для перевода естественного языка в параметры API оказывается более надежным и дешевым решением, чем попытки написать идеальное описание инструмента для всех возможных клиентских моделей.
