AWS опубликовала 6 подходов к оптимизации MCP-инструментов для экономии контекста

AWS 12 июля 2026 года опубликовала техническое руководство о проблемах дизайна MCP-инструментов и предложила 6 практических подходов к их решению — от оптимизации описаний до серверного анализа параметров с помощью AI. Исследование основано на реальном тестировании API поиска образовательного контента (K-12).

Почему MCP-инструменты снижают качество моделей

Model Context Protocol помогает LLM использовать внешние инструменты, но дизайн определений часто неудачен. AWS выявила две основные проблемы:

Bloat (раздутие): каждый MCP-сервер загружает определение инструментов в контекстное окно, даже если они не используются. При нескольких активных серверах окно переполняется определениями раньше, чем пользователь задаст первый вопрос.

Confusion (путаница): переполненный контекст деградирует рассуждения модели. LLM путает похожие инструменты, ошибается в параметрах, неправильно интерпретирует ограничения. Семантическое сходство инструментов и неясные имена параметров усугубляют проблему.

6 подходов: полный спектр решений

AWS протестировала шесть реализаций на реальных запросах типа «Найди тест по дробям для 7-го класса» и «Мне нужен контент, выровненный по TEKS»:

• V1 (Raw Passthrough): exposes backend API как есть — высокие ошибки параметров
• V2 (Rich Descriptions): подробные docstrings с примерами — улучшает точность, но растёт размер
• V3 (Schema & Defaults): переименованные параметры (discipline → subject), Literal enums, sensible defaults — хороший компромисс
• V4 (Lazy Loading): детали (taxonomy) за отдельным инструментом — минимальный baseline, дополнительные запросы
• V5 (Server-side Introspection): Amazon Nova 2 Lite анализирует параметры на сервере — стабильное поведение, но дополнительные inference calls
• V6 (Agent-as-Tool): один параметр question: str, вся логика внутри — максимум контроля, требует инфраструктуры

Ключевые рекомендации AWS

AWS Prescriptive Guidance рекомендует держать параметры инструмента «примерно восьмерых или менее». Anthropic's исследование показало: сдвиг на on-demand подробный вывод сокращает response токены примерно на две трети.

Дополнительно: писать специфичные, actionable error messages (не просто «no results», а точное описание, что попробовать). Использовать domain-appropriate имена параметров вместо названий БД колонок — это резко снижает путаницу модели.

Как выбрать подход для вашей задачи

Нет универсального решения. Выбор зависит от количества параметров (мало → V3, много → V4-V5), стабильности словаря, требований к latency и нужна ли единообразность для разных моделей. Для большинства search и filter задач достаточно V3. Специализированные приложения (сложные taxonomy, multi-step reasoning) выигрывают от V4-V5.

Что это значит

MCP-инструменты сейчас часто замедляют LLM-агентов, но AWS показала: проблема решаема через context engineering. Инженеры теперь имеют практический playbook для балансирования контекста и точности вместо того, чтобы слепо добавлять описания.