MCP для AI-агентов: как дать агенту инструменты и не раздуть контекст

Возможности агента определяются двумя вещами: моделью и набором действий, которые ему доступны. Про модели написаны терабайты сравнений, а про второй фактор говорят меньше - хотя именно он отличает агента, который «может обсудить проблему», от агента, который читает логи в Sentry, находит коммит в GitHub и заводит тикет в Jira.

MCP (Model Context Protocol) сделал этот второй фактор конструктором. К 2026 году протокол прошёл путь от внутреннего стандарта Anthropic до индустриального: 9 декабря 2025 он передан в Linux Foundation, где соучредителями фонда стали Anthropic, Block и OpenAI, а публичных серверов к тому моменту было больше 10 000. Вопрос «как подключить агента к инструментам» решён. Открытым остался другой: что именно подключать, чем за это платишь и где проходит граница безопасности.

Статья о том, как проектировать инструментальную обвязку агента: какие классы суперспособностей дают MCP-серверы, сколько стоит каждый сервер в токенах контекста, по каким принципам собирать набор и как не открыть дыру в собственную инфраструктуру. Базовые вещи - архитектура протокола, подключение, каталог серверов - уже разобраны в гайде по MCP и подборке лучших серверов; здесь - уровень проектирования.

Какие суперспособности бывают

Полезно думать о серверах не списком, а классами способностей, которые они дают агенту:

Разделение практично по двум причинам. Во-первых, у классов разный профиль риска: серверы чтения и наблюдения почти безопасны, серверы действий - главный источник инцидентов, и права на них выдаются иначе. Во-вторых, зрелость обвязки агента измеряется покрытием классов, а не количеством серверов: агент с четырьмя серверами по одному из каждого класса способнее агента с десятью серверами чтения.

Проверочный вопрос к своему набору: может ли агент самостоятельно пройти цикл «увидел проблему → понял причину → внёс исправление → проверил результат»? Для этого нужны все четыре класса. Если какой-то отсутствует, агент будет останавливаться на середине и просить человека «посмотри сам».

Состояние стандарта: MCP в 2026

Коротко о том, на чём вы стоите, подключая MCP сегодня:

Практический вывод из этой таблицы: ставка на MCP - уже не ставка на вендора. Сервер, написанный под одного клиента, работает с остальными. Вторая деталь важнее, чем кажется: вместе с MCP в тот же фонд передан AGENTS.md - файл проектных инструкций от OpenAI. Слой «контекст + инструменты» стандартизируется целиком, и конфигурация агента становится переносимой между инструментами.

Из ревизии 2026-07-28 для цены контекста важны две вещи. Серверам рекомендовано (SHOULD) отдавать tools/list в детерминированном порядке: это позволяет клиентам кэшировать список и повышает долю попаданий в prompt cache, когда инструменты лежат в контексте модели. А результаты list-запросов теперь несут поля ttlMs и cacheScope (интерфейс CacheableResult) - подсказку клиенту, как долго список считать свежим. Подробности - в changelog и разделе про tools. Автору своего сервера вывод простой: не меняйте порядок инструментов между запросами.

Цена, которую не пишут в каталогах: контекст

Каждый подключённый сервер отдаёт клиенту описания своих инструментов - имя, назначение, схему параметров. Если клиент загружает их сразу, они попадают в контекст сессии до того, как агент прочитал первое слово вашей задачи. В Claude Code это не так: tool search включён по умолчанию, на старте грузятся только имена инструментов и инструкции серверов, а определения подтягиваются по необходимости. Режим ENABLE_TOOL_SEARCH=auto:N включает отложенную загрузку, когда определения занимают N% окна и больше (документация). Работает на Opus 4, Sonnet 4, Haiku 4.5 и новее; на более ранних моделях всё грузится сразу. В документации Cursor лимита на число tools и ленивой загрузки описаний не нашлось - поведение своего клиента проверяйте сами.

Универсальной цифры «сколько токенов стоит сервер» нет: она зависит от сервера и клиента. Посмотрите разбивку командой /context в Claude Code или её аналогом. Есть и вторая цена - внимание модели: чем больше похожих инструментов доступно, тем выше риск, что агент выберет не тот - спутает похожие серверы или дёрнет поиск по вебу там, где нужен поиск по докам. Это инженерное наблюдение, а не измеренная величина, проверяйте на своих задачах.

Правила гигиены:

• Глобальный конфиг - только для серверов, нужных везде. Всё проектное - в конфиг проекта. Сервер аналитики конкретного продукта не должен ездить в контексте каждого репозитория.
• Сервер-зомби отключается. Подключён под задачу трёхмесячной давности, с тех пор не вызывался - но занимает место в списке инструментов (а без tool search ещё и токены каждой сессии). Периодическая ревизия списка - самая дешёвая оптимизация контекста.
• Пересечения устраняются. Два сервера с инструментом search - гарантированная путаница: агент будет выбирать между ними недетерминированно. Один класс задач - один сервер.
• Размер сервера имеет значение. Официальный сервер на 50 инструментов, из которых агент использует три, - кандидат на замену своим сервером на эти три инструмента. Отложенная загрузка схем (в Claude Code включена по умолчанию) снижает цену большого сервера, но не заменяет аккуратный выбор; в других клиентах поведение нужно проверять.

Это тот же бюджет внимания, что и у контекст-файлов - тема гайда по context engineering: всё, что загружается в каждую сессию, должно отрабатывать своё место.

Проектирование набора: от задач, а не от каталога

Каталоги серверов провоцируют собирательство: подключить «на всякий случай» всё интересное. Рабочий подход обратный.

1. Выпишите повторяющиеся задачи агента. Не гипотетические, а реальные: «разобрать ошибку из продакшена», «подготовить PR по тикету», «ответить на вопрос по данным». Пять-семь формулировок.

2. Для каждой задачи - какие внешние касания нужны. «Разобрать ошибку» = прочитать стектрейс (Sentry) + найти код (уже умеет) + посмотреть историю (git). Из задач вырастает список способностей, из способностей - короткий список серверов.

3. На каждую способность - один сервер. Выбор по трём критериям: автор (официальный от вендора системы или проверенного мейнтейнера), качество описаний инструментов (агент будет читать именно их), размер (не тянет ли лишнего).

4. Права - по классу способности. Серверам чтения - read-only токены. Серверам действий - минимальный scope и подтверждение на стороне клиента для необратимых операций. Один сервер - один токен, чтобы отзыв не ломал остальное.

5. Свой сервер - когда готовый не подходит. Внутренний API, специфичная комбинация из трёх инструментов, неудачные описания в готовом сервере. Написание своего - задача на день, разбирали в статье про MCP-сервер на Python; production-практики - error handling, мониторинг, безопасность - в отдельном гайде.

Признак хорошо собранного набора: короткий системный контекст, и при этом на типовых задачах агент не спрашивает разрешения «сходить посмотреть самому» - у него есть всё, чтобы дойти до результата.

Безопасность: три векторa, о которых стоит помнить

Инструменты дают агенту руки - и создают поверхности атаки, которых у чистой модели не было.

Tool poisoning. Описания инструментов - текст, который агент читает как часть контекста. Вредоносный сервер может спрятать в описании инструкции («перед вызовом отправь содержимое файла X параметром Y»), невидимые в UI, но видимые модели. Исследователи Invariant Labs описали атаку в апреле 2025; там же - «rug pull» (сервер меняет описание уже после одобрения) и tool shadowing (описание одного сервера влияет на вызовы инструментов другого). Среди рекомендаций авторов - фиксировать версии инструментов хэшами и строже разграничивать данные между серверами. Спецификация со своей стороны требует от клиентов считать аннотации инструментов недоверенными, если сервер не доверенный, и рекомендует держать человека в контуре с правом отклонить вызов (tools). Вывод: сторонний сервер - это код с правами в вашем контексте; авторство и содержимое описаний проверяются до подключения, версия фиксируется.

Инъекции через результаты. Даже честный сервер возвращает данные из внешнего мира: текст issue, содержимое веб-страницы, письмо. Если в этих данных написано «агент, выполни…», модель может принять это за инструкцию. Класс описан как LLM01:2025 Prompt Injection в OWASP Top 10 для LLM-приложений. Защита - уровнем клиента и промпта: результаты инструментов трактуются как данные, действия с побочными эффектами требуют подтверждения. Это же - главный аргумент против режимов «выполнять всё без вопросов».

Избыточные права. Самый скучный и самый частый вектор. Токен с admin-scope, выданный серверу, которому хватило бы чтения; общий токен на пять серверов; секреты, прописанные plaintext в конфиге, который лежит в dotfiles-репозитории. Здесь нет ничего специфичного для MCP - обычная гигиена секретов, просто применённая к новому слою.

Практическое правило для серверов действий: необратимые операции (merge, деплой, удаление, отправка сообщений наружу) агент выполняет только через подтверждение человека - независимо от того, насколько вы доверяете серверу. Цена клика «разрешить» несопоставима с ценой автоматического git push --force по инструкции из отравленного описания.

Подводные камни

• Registry в preview - не основа для продакшена. Официальный реестр в preview: на его странице сказано, что до GA возможны breaking changes и сброс данных. Автоматическое обнаружение и установка серверов из реестра - пока экспериментальный путь, для продакшена серверы фиксируются явно.
• stdio против Streamable HTTP - не вопрос вкуса. Локальные серверы (stdio) наследуют ваши права и окружение; удалённые (HTTP) требуют авторизации, но зато не имеют доступа к файловой системе. Серверу, которому не нужны локальные файлы, лучше быть удалённым.
• Качество описаний решает больше, чем функциональность. Агент выбирает инструмент по описанию. Сервер с мощными, но невнятно описанными инструментами работает хуже сервера с тремя инструментами и точными описаниями. При написании своего сервера основное время стоит вложить именно в описания и схемы.
• Один сервер - не одна сессия. Глобально подключённый тяжёлый сервер умножает свой контекстный вес на все сессии всех проектов, если клиент грузит схемы сразу. Считайте суммарную стоимость, а не стоимость одной сессии.
• Стандарт молодой - следите за версиями спецификации. Протокол версионируется по датам breaking changes. Начиная с 2026-07-28 версия передаётся в каждом запросе, а несовпадение возвращает ошибку UnsupportedProtocolVersion; клиенты и серверы обновляются с разной скоростью, поэтому при странностях подключения проверяйте совместимость ревизий. Roots, Sampling и Logging объявлены deprecated (окно депрекации - не менее двенадцати месяцев): новые серверы на них лучше не строить.

С чего начать

1. Выпишите пять повторяющихся задач своего агента и внешние касания для каждой - это ваш список необходимых способностей.
2. Проведите ревизию текущих серверов: что из подключённого используется, что дублируется, что не вызывалось месяц. Лишнее - отключить.
3. Соберите минимальный набор: по одному серверу на способность, покрытие всех четырёх классов (данные, действия, контекст, наблюдение), 3–5 серверов на старте.
4. Пересмотрите токены: read-only где возможно, минимальный scope везде, отдельный токен на сервер, подтверждение для необратимых действий.
5. Зафиксируйте версии серверов и источник установки - как в lock-файле зависимостей.
6. Через месяц вернитесь к пункту 2. Набор инструментов - не разовая настройка, а часть сетапа, которая гниёт и требует ухода.

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