Посмотрел доклад 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-серверов и гейтвеев.

Нужен общий слой, который решает следующие задачи:

• единая точка подключения инструментов
• авторизация и политики доступа
• аудит вызова tools
• лимиты
• логирование, 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 для агентов.