MCP в 2026 году: как проектировать инструменты для агентов, а не для людей

Model Context Protocol (MCP) — стандарт, который Anthropic выпустил в конце 2024 года, чтобы унифицировать способ подключения языковых моделей к внешним инструментам, данным и сервисам. По замыслу, MCP должен стать для агентов тем же, чем HTTP стал для веба: единым протоколом взаимодействия. Но по мере того как компании начали его внедрять, выяснилось, что сам протокол — лишь часть задачи.

Дэвид Сориа Парра из Anthropic в своём докладе сформулировал ключевую проблему: разработчики воспроизводят привычный паттерн и просто оборачивают существующий REST API в MCP-сервер. Это выглядит логично — у вас уже есть GET /users, POST /orders, PATCH /documents/:id, и кажется, что достаточно добавить MCP-обёртку. Но REST API проектировался для разработчиков, которые понимают контекст и сами комбинируют вызовы. Агент же работает иначе: ему нужно не набор низкоуровневых методов, а осмысленное действие — «найди договор и проверь риски», «подготовь черновик ответа клиенту», «создай отчёт за период». Хороший MCP-интерфейс должен быть нативным для агента, а не переупакованным API.

Вторая системная проблема — перегрузка контекста. Многие MCP-интеграции выгружают агенту полный список доступных инструментов сразу. Это засоряет контекстное окно модели: она хуже выбирает нужный tool, растёт стоимость каждого запроса, увеличивается latency, повышается риск ошибочного вызова. Anthropic предлагает реализовывать progressive discovery — агент получает инструменты постепенно, по мере необходимости, а не весь каталог при старте. Это требует отдельного проектирования: нужен механизм поиска инструментов по запросу, а не просто их перечисление.

MCP и Skills — не конкуренты, а инструменты для разных задач. Skills подходят для локальных, процедурных сценариев: взять ffmpeg, обработать видео, положить результат в каталог. MCP уместен там, где нужны авторизация, RBAC, аудит действий и стабильный контракт между агентом и внешней системой. Общая рекомендация — использовать самый простой механизм, который решает задачу. MCP-сервер не нужен везде, но если инструмент работает с чувствительными данными в корпоративной среде, Skills становятся менее надёжным выбором.

Для enterprise-сценариев Сориа Парра формулирует отдельный тезис: нельзя позволять каждой команде поднимать собственный набор MCP-серверов и gateway. Без единого слоя управления через год разработки компания получит не ИИ-платформу, а распределённую коллекцию небезопасных интеграций, которые никто не контролирует. Нужен общий connectivity-слой с единой точкой подключения инструментов, политиками доступа, лимитами, логированием и контролем жизненного цикла.

Отдельная нерешённая задача — идентичность агента. Большинство систем сегодня работают по схеме: пользователь авторизовался → нажал кнопку → система выполнила действие. С агентами цепочка усложняется: агент действует от имени пользователя, но асинхронно, иногда через несколько систем, иногда продолжительное время. Возникают вопросы, на которые пока нет стандартных ответов: кто именно вызвал инструмент, с какими правами, можно ли агенту продолжить задачу без подтверждения, как отозвать доступ и как показать аудитору, что произошло. Это отдельный пласт инженерной работы, который в большинстве реализаций остаётся за скобками.