Будущее MCP

Посмотрел доклад David Soria Parra из Anthropic про будущее MCP.
В 2026 году узким местом для AI-агентов становятся уже не столько модели, а связность между разными компонентами системы: как агент подключается к инструментам, данным, приложениям, какие права доступа у него есть, как вокруг всего этого строить UX и бизнес-сценарии.
Основые тезисы из доклада Дэвида с моими дополнениями 👇🏻
MCP — не серебряная пуля, а важный компонент агентной системы
Лучшие агенты будут использовать не только MCP, но и:

• CLI
  
• skills
  
• браузер/ресурсы компьютера
  
• 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. Пишу про прикладную ИИ разработку у себя в канале и блоге.-Источник