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

> Как проектировать набор MCP-серверов для AI-агента: классы суперспособностей, цена инструментов в контексте, безопасность и состояние стандарта в 2026.
> Author: Roman Belov · Published: 2026-10-03 · Source: https://futurecraft.pro/ru/blog/mcp-for-ai-agents/

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

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

Статья о том, как проектировать инструментальную обвязку агента: какие классы суперспособностей дают MCP-серверы, сколько стоит каждый сервер в токенах контекста, по каким принципам собирать набор и как не открыть дыру в собственную инфраструктуру. Базовые вещи - архитектура протокола, подключение, каталог серверов - уже разобраны в [гайде по MCP](https://futurecraft.pro/ru/blog/mcp-servers-explained/) и [подборке лучших серверов](https://futurecraft.pro/ru/blog/best-mcp-servers-2026/); здесь - уровень проектирования.

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

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

| Класс | Что агент получает | Типичные серверы |
|---|---|---|
| Чтение данных | Реальное состояние систем вместо предположений | PostgreSQL, Supabase, аналитика, поиск по вебу |
| Действия | Изменение внешнего мира: тикеты, PR, сообщения, деплой | GitHub, Jira/Linear, Slack, CI/CD |
| Контекст | Знания, которых нет в модели: доки, внутренние вики | Notion, Confluence, документация библиотек |
| Наблюдение | Диагностика: логи, ошибки, метрики | Sentry, Grafana, облачные логи |

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

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

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

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

| Параметр | Состояние на ноябрь 2026 |
|---|---|
| Governance | Передан в Linux Foundation 9 декабря 2025 ([Anthropic](https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation), [Linux Foundation](https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation)) как проект Agentic AI Foundation. Соучредители - Anthropic, Block, OpenAI; платиновые участники - AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, OpenAI. По словам Anthropic, модель управления самим MCP не изменилась |
| Спецификация | Ревизия 2026-07-28 (версии по дате), предыдущая - 2025-11-25 ([changelog](https://modelcontextprotocol.io/specification/2026-07-28/changelog)) |
| Протокол | Stateless: убраны рукопожатие initialize/initialized и заголовок Mcp-Session-Id, версия протокола и capabilities клиента идут в каждом запросе, добавлен метод server/discover и поток subscriptions/listen |
| Транспорты | stdio (локальные серверы) и Streamable HTTP (удалённые); HTTP+SSE переведён в статус Deprecated |
| Авторизация | Для HTTP-транспортов, на базе черновика OAuth 2.1 ([спецификация](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization)); регистрация клиентов через Client ID Metadata Documents, Dynamic Client Registration помечена как deprecated. Для stdio спецификация авторизацию не предписывает: учётные данные берутся из окружения |
| Deprecated | Roots, Sampling и Logging: пока работают, но новым реализациям их добавлять не рекомендуется; окно депрекации - не менее двенадцати месяцев |
| Tasks | Вынесены из ядра в официальное расширение io.modelcontextprotocol/tasks |
| Официальный registry | В preview: на странице реестра указано, что до GA возможны breaking changes и сброс данных ([источник](https://modelcontextprotocol.io/registry/about)) |
| Экосистема | На декабрь 2025 по данным Anthropic: более 10 000 активных публичных серверов и более 97 млн загрузок SDK в месяц (Python и TypeScript). Более свежих официальных цифр найти не удалось |
| Клиенты | По данным Anthropic: ChatGPT, Cursor, Gemini, Microsoft Copilot, VS Code; облака - AWS, Cloudflare, Google Cloud, Microsoft Azure |

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

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

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

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

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

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

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

Это тот же бюджет внимания, что и у контекст-файлов - тема [гайда по context engineering](https://futurecraft.pro/ru/blog/context-engineering-guide/): всё, что загружается в каждую сессию, должно отрабатывать своё место.

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

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

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

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

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

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

5. **Свой сервер - когда готовый не подходит.** Внутренний API, специфичная комбинация из трёх инструментов, неудачные описания в готовом сервере. Написание своего - задача на день, разбирали в статье [про MCP-сервер на Python](https://futurecraft.pro/ru/blog/build-mcp-server-python/); production-практики - error handling, мониторинг, безопасность - в [отдельном гайде](https://futurecraft.pro/ru/blog/mcp-production-custom-servers/).

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

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

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

**Tool poisoning.** Описания инструментов - текст, который агент читает как часть контекста. Вредоносный сервер может спрятать в описании инструкции («перед вызовом отправь содержимое файла X параметром Y»), невидимые в UI, но видимые модели. Исследователи Invariant Labs описали атаку [в апреле 2025](https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks); там же - «rug pull» (сервер меняет описание уже после одобрения) и tool shadowing (описание одного сервера влияет на вызовы инструментов другого). Среди рекомендаций авторов - фиксировать версии инструментов хэшами и строже разграничивать данные между серверами. Спецификация со своей стороны требует от клиентов считать аннотации инструментов недоверенными, если сервер не доверенный, и рекомендует держать человека в контуре с правом отклонить вызов ([tools](https://modelcontextprotocol.io/specification/2026-07-28/server/tools)). Вывод: сторонний сервер - это код с правами в вашем контексте; авторство и содержимое описаний проверяются до подключения, версия фиксируется.

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

**Избыточные права.** Самый скучный и самый частый вектор. Токен с 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 снял техническое трение: подключить агента к чему угодно стало просто. Значит, преимущество переехало на уровень выше - к тем, кто проектирует набор осознанно. Агент с пятью правильными серверами и жёсткими правами обгонит агента с двадцатью случайными: меньше контекста, точнее выбор инструмента, уже поверхность атаки. Суперспособности - это не количество плагинов, а соответствие рук задачам.