Будущее 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. Пишу про прикладную ИИ разработку у себя в канале и блоге.