Что такое MCP и зачем он нужен AI-агентам
Содержание курса
Когда MCP оправдан: критерии выбора для реального проекта
Понимание MCP — это одно, а решение «нужен ли он мне прямо сейчас» — совсем другое. MCP добавляет инфраструктурный слой, и тащить его в каждый проект нет смысла. Вот четыре вопроса, которые помогают принять это решение. Сколько внешних инструментов нужно агенту?
Если агент работает ровно с одним API и это не изменится — прямая интеграция проще и быстрее. MCP начинает окупаться, когда инструментов больше двух, и особенно когда их список будет расти. Каждый новый сервис без MCP — новый уникальный коннектор внутри агента; с MCP — регистрация нового сервера. Есть ли готовые MCP-серверы для нужных сервисов?
Экосистема MCP уже содержит серверы для популярных сервисов: файловая система, базы данных, системы контроля версий, планировщики задач. Если для вашего стека готовые серверы существуют, вы получаете готовую интеграцию вместо написания её с нуля. Если нет — придётся написать MCP-сервер самому, что дороже, чем прямой вызов API в простом случае. Нужна ли переносимость агента между хостами?
Если сегодня агент запускается в Claude Desktop, а завтра вы хотите запустить его в своём приложении или в другом LLM-окружении — MCP даёт эту переносимость из коробки. Клиент остаётся тем же; меняется только хост. Без MCP переносимость — это ручной рефакторинг. Важна ли изоляция инструментов?
MCP-серверы — это отдельные процессы. Это значит, что каждый инструмент работает в своём окружении, с собственными правами доступа и зависимостями. Если вопросы безопасности и разграничения прав критичны, архитектура с серверами даёт их почти бесплатно. На практике сигналом к применению MCP служит комбинация: инструментов больше двух, список будет расти, и важна возможность подключать их не переписывая агента. Если все три условия выполнены — MCP оправдан. Если задача разовая, инструментов мало, и масштабирования не планируется — начните с прямых вызовов и добавляйте MCP тогда, когда сложность действительно этого потребует. Следующий урок переводит эту общую картину в конкретную схему: Host, Client и Server, и показывает, где заканчивается ответственность каждого.
Как отличить протокол подключения от логики агента
Возьмём инструмент поиска товара по артикулу. В обычном приложении функция find_product(sku) читает каталог. MCP-сервер может предоставить её клиенту как tool с описанием и схемой аргументов. Агент решает, нужен ли поиск, а сервер исполняет разрешённую операцию. MCP не превращает результат базы в истинное утверждение и не выбирает бизнес-цель за пользователя.
Проверьте три отдельных сбоя. Если сервер недоступен, это проблема соединения или транспорта. Если клиент передал строку вместо ожидаемого объекта аргументов, это ошибка контракта вызова. Если инструмент вернул устаревшую цену, это проблема источника данных. Смена системного промпта не лечит все три класса.
При проектировании запишите вход, выход и ошибки каждого tool. Для поиска по каталогу полезны идентификатор товара, цена с валютой и признак отсутствия. Универсальная команда «выполни любой запрос» затрудняет и контроль доступа, и тестирование. Отдельно определите, каким credential сервер обращается к каталогу и что вправе читать конкретный пользователь.
Продолжите разбор: Как создать MCP-сервер на Python и TypeScript.