Посмотрел доклад David Soria Parra из Anthropic про будущее MCP.
В 2026 году узким местом для AI-агентов становятся уже не модели, а связность между разными компонентами ИИ-системы: как агент подключается к инструментам, данным, приложениям, какие права доступа у него есть, как вокруг всего этого строить UX и бизнес-сценарии.
Основые тезисы из доклада Дэвида с моими дополнениями 👇🏻
MCP — не серебряная пуля, а важный компонент агентной системы
Лучшие агенты будут использовать не только MCP, но и:
CLI
браузер и другие приложения
API сервисов
платформенные решения
Основная мысль в том, чтобы дать агенту правильный интерфейс доступа к нужному действию. Иногда проще предоставить CLI, а в других ситуациях сделать полноценный MCP-сервер с авторизацией, аудитом и контролем доступа. Где-то же понадобится полноценный gateway между агентами и корпоративными системами.
REST API → MCP 1:1 — плохая идея
Не стоит брать REST API и превращать его в MCP-сервер просто обернув суще API-методы.
REST API обычно спроектирован для разработчиков и CRUD-операций:
• GET /users
• POST /orders• PATCH /documents/:id
А агенту чаще нужен не набор низкоуровневых методов, а осмысленное действие:
создай отчёт за период
найди договор и проверь риски
подготовь черновик ответа клиенту
сравнить версии документа
Хороший MCP-интерфейс должен быть нативным для агента, а не оберткой поверх когда-то разработанного API. Это важный сдвиг в мышлении при проектировании агентных систем.
Информация о тулах должна быть доступна модели по требованию
Одна из проблем, с которой мы сейчас сталкиваемся на практике — многие интеграции через MCP выгружают агенту огромный список tools, который затем утекает в контекстное окно модели. Как следствие:
модель хуже выбирает нужный инструмент
растёт стоимость запроса
растёт latency ответа
повышается риск неправильного tool call
контекст забивается описаниями инструментов вместо полезной информации
Anthropic предлагает реализовывать progressive discovery: агент должен постепенно получать нужные инструменты, а не весь список доступных tools сразу.
Для разработчика это означает, что нам нужно думать не только о том, какие tools предоставлять модели, но и как модель будет их находить.
Skills и MCP не конкуренты
Skills хорошо подходят для локальных, процедурных, CLI-based сценариев. Например, «возьми ffmpeg, обработай видео, положи результат сюда». MCP лучше подходит там, где нужны:
авторизация
RBAC
аудит действий и observability
управление доступом к инструментам
стабильный контракт между агентом и внешней системой
Общая рекомендация сейчас: используйте самый простой механизм, который решает вашу задачу. MCP-сервер не нужен для каждого shell-скрипта. Но если инструмент живёт в enterprise-среде и работает к чувствительными данными, то Skills — менее надёжное решение.
Enterprise-агентам нужен gateway
Для компаний главный вывод такой: нельзя позволять каждой команде поднимать свой зоопарк MCP-серверов и гейтвеев.
Нужен общий слой, который решает следующие задачи:
единая точка подключения инструментов
авторизация и политики доступа
аудит tool calls
лимиты
логирование
observability
контроль того, какие агенты к чему имеют доступ
контроль жизненного цикла инструментов
Иначе через год разработки получится не AI-платформа, а распределённая коллекция небезопасных интеграций, которые никто не понимает и не контролирует.
В докладе это формулируется как движение к общему connectivity/gateway-слою, т. е. не каждый агент сам знает обо всех системах, а платформа даёт ему управляемый доступ.
Идентичность агентов
Сейчас большинство систем всё ещё реализуют такую цепочку действий: пользователь авторизовался → пользователь нажал кнопку → система выполнила действие.
Но с агентами появляется новая проблема — агент действует от имени пользователя, но не всегда синхронно, не всегда сразу, его действия могут выполняться продолжительное время, иногда через несколько систем.
Возникают вопросы:
кто именно вызвал tool
от чьего имени
с какими правами
можно ли агенту продолжить задачу без подтверждения пользователя
как отозвать доступ
как показать аудитору, что произошло
Это отдельный пласт инженерной работы. И он пока решён хуже, чем хотелось бы.
TLDR;
MCP — это не просто новый стандарт для тулов. Это сигнал, что разработчикам придётся учиться проектировать интерфейсы для агентов, а не только API для людей и frontend-приложений.
Практические советы:
Не делайте глупую 1-1 обертку REST-to-MCP. Сначала подумайте, какое действие реально должен выполнить агент.
Проектируйте тулы как атомарные действия, которые можно соединять в более крупную задачу. Не createUser, updateUser, deleteUser, а «подготовить пользователя к онбордингу», «проверить доступы к X», «собрать контекст по клиенту».
Ограничивайте набор тулов для задачи. Чем больше инструментов вы добавите в контекст, тем хуже может работать агент (а точнее модель).
Думайте о discovery инструментов по запросу. Агенту не обязательно знать обо всех тулах сразу. Лучше сделать каталог тулов и progressive discovery.
Сразу закладывайте аудит и работу с правами доступа. Особенно если инструмент может читать документы или менять данные.
Используйте CLI там, где этого достаточно. Не стоит реализовывать MCP ради MCP.
Для enterprise-сценариев нужен gateway. Без него MCP быстро превращается в shadow IT для агентов.
P.S. Пишу про прикладную ИИ разработку у себя в канале и блоге.