платформенные решения<\/li>\n<\/ul>\nОсновная мысль в том, чтобы дать агенту правильный интерфейс доступа к нужному действию. Иногда проще предоставить CLI, а в других ситуациях сделать полноценный MCP-сервер с авторизацией, аудитом и контролем доступа. Где-то же понадобится полноценный gateway между агентами и корпоративными системами.<\/p>\n
REST API → MCP 1:1 — плохая идея<\/h3>\n
Не стоит брать REST API и превращать его в MCP-сервер просто обернув суще API-методы.<\/p>\n
REST API обычно спроектирован для разработчиков и CRUD-операций:<\/p>\n
GET \/users\nPOST \/orders\nPATCH \/documents\/:id<\/code><\/pre>А агенту чаще нужен не набор низкоуровневых методов, а осмысленное действие:<\/p>\n
\n- создай отчёт за период<\/li>\n
- найди договор и проверь риски<\/li>\n
- подготовь черновик ответа клиенту<\/li>\n
- сравнить версии документа<\/li>\n<\/ul>\n
Хороший MCP-интерфейс должен быть нативным для агента, а не оберткой поверх когда-то разработанного API. Это важный сдвиг в мышлении при проектировании агентных систем.<\/p>\n
Информация о тулах должна быть доступна модели по требованию<\/h3>\n
Одна из проблем, с которой мы сейчас сталкиваемся на практике — многие интеграции через MCP выгружают агенту огромный список tools, который затем утекает в контекстное окно модели. Как следствие:<\/p>\n
\n- модель хуже выбирает нужный инструмент<\/li>\n
- растёт стоимость запроса<\/li>\n
- растёт latency ответа<\/li>\n
- повышается риск неправильного tool call<\/li>\n
- контекст забивается описаниями инструментов вместо полезной информации<\/li>\n<\/ul>\n
Anthropic предлагает реализовывать progressive discovery: агент должен постепенно получать нужные инструменты, а не весь список доступных tools сразу.<\/p>\n
Для разработчика это означает, что нам нужно думать не только о том, какие tools предоставлять модели, но и как модель будет их находить.<\/p>\n
Skills и MCP не конкуренты<\/h3>\n
Skills хорошо подходят для локальных, процедурных, CLI-based сценариев. Например, «возьми ffmpeg, обработай видео, положи результат сюда». MCP лучше подходит там, где нужны:<\/p>\n
\n- авторизация<\/li>\n
- RBAC<\/li>\n
- аудит действий и observability<\/li>\n
- управление доступом к инструментам<\/li>\n
- стабильный контракт между агентом и внешней системой<\/li>\n<\/ul>\n
Общая рекомендация сейчас: используйте самый простой механизм, который решает вашу задачу. MCP-сервер не нужен для каждого shell-скрипта. Но если инструмент живёт в enterprise-среде и работает к чувствительными данными, то Skills — менее надёжное решение.<\/p>\n
Enterprise-агентам нужен gateway<\/h3>\n
Для компаний главный вывод такой: нельзя позволять каждой команде поднимать свой зоопарк MCP-серверов и гейтвеев.<\/p>\n
Нужен общий слой, который решает следующие задачи:<\/p>\n
\n- единая точка подключения инструментов<\/li>\n
- авторизация и политики доступа<\/li>\n
- аудит вызова tools<\/li>\n
- лимиты<\/li>\n
- логирование, observability<\/li>\n
- контроль того, какие агенты к чему имеют доступ<\/li>\n
- контроль жизненного цикла инструментов<\/li>\n<\/ul>\n
Иначе через год разработки получится не AI-платформа, а распределённая коллекция небезопасных интеграций, которые никто не понимает и не контролирует.<\/p>\n
В докладе это формулируется как движение к общему connectivity\/gateway-слою, т. е. не каждый агент сам знает обо всех системах, а платформа даёт ему управляемый доступ.<\/p>\n
Идентичность агентов<\/h3>\n
Сейчас большинство систем всё ещё реализуют такую цепочку действий: пользователь авторизовался → пользователь нажал кнопку → система выполнила действие.<\/p>\n
Но с агентами появляется новая проблема — агент действует от имени пользователя, но не всегда синхронно, не всегда сразу, его действия могут выполняться продолжительное время, иногда через несколько систем.<\/p>\n
Возникают вопросы:<\/p>\n
\n- кто именно вызвал tool<\/li>\n
- от чьего имени<\/li>\n
- с какими правами<\/li>\n
- можно ли агенту продолжить задачу без подтверждения пользователя<\/li>\n
- как отозвать доступ<\/li>\n
- как показать аудитору, что произошло<\/li>\n<\/ul>\n
Это отдельный пласт инженерной работы. И он пока решён хуже, чем хотелось бы.<\/p>\n
TLDR;<\/h3>\n
MCP — это не просто новый стандарт для тулов. Это сигнал, что разработчикам придётся учиться проектировать интерфейсы для агентов, а не только API для людей и frontend-приложений.<\/p>\n
Практические советы:<\/p>\n
\n- Не делайте глупую 1-1 обертку REST-to-MCP<\/b>. Сначала подумайте, какое действие реально должен выполнить агент.<\/li>\n<\/ul>\n
\n- Проектируйте тулы как атомарные действия, которые можно соединять в более крупную задачу<\/b>. Не createUser, updateUser, deleteUser, а «подготовить пользователя к онбордингу», «проверить доступы к X», «собрать контекст по клиенту».<\/li>\n<\/ul>\n
\n- Ограничивайте набор тулов для задачи<\/b>. Чем больше инструментов вы добавите в контекст, тем хуже может работать агент (а точнее модель).<\/li>\n<\/ul>\n
\n- Думайте о discovery инструментов по запросу<\/b>. Агенту не обязательно знать обо всех тулах сразу. Лучше сделать каталог тулов и progressive discovery.<\/li>\n<\/ul>\n
\n- Сразу закладывайте аудит и работу с правами доступа<\/b>. Особенно если инструмент может читать документы или менять данные.<\/li>\n<\/ul>\n
\n- Используйте CLI там, где этого достаточно<\/b>. Не стоит реализовывать MCP ради MCP.<\/li>\n<\/ul>\n
\n- Для enterprise-сценариев нужен gateway<\/b>. Без него MCP быстро превращается в shadow IT для агентов.<\/li>\n<\/ul>\n