Саймон Уиллисон ответил на критику Model Context Protocol (MCP) в обсуждении статьи «MCP was always a bad idea?» на Hacker News. В комментарии от 20 сентября 2026 года он признал часть аргумента критиков: если полноценный терминальный агент имеет неограниченный доступ к интернету, ему зачастую проще вызывать API напрямую. Но, по мнению Уиллиссона, из этого не следует, что MCP бесполезен для других AI-продуктов.
Разница — в том, сколько самостоятельности разработчик готов дать агенту. Уиллисон перечислил задачи, которые возникают при более контролируемом доступе к внешним сервисам: определить разрешённые подключения, организовать авторизацию без прямой передачи агенту API-ключей, дать пользователю интерфейс для подключения сервисов и вести аудит действий.
Где прямого вызова API достаточно
Уиллисон приводит в пример терминальных агентов, в том числе Claude Code и Codex. Если такой агент уже работает в среде с широким доступом к сети и необходимыми учётными данными, дополнительный протокол не обязательно упрощает задачу. Агент может обращаться к API доступными ему средствами.
Это оценка конкретной конфигурации, а не вывод обо всех код-агентах. Терминальному агенту тоже можно ограничить сеть, права и доступ к секретам. Поэтому при выборе архитектуры полезнее спрашивать не «умеет ли агент писать код», а «к каким системам он может обращаться и кто контролирует эти обращения».
Сам Уиллисон характеризует альтернативный сценарий как «менее YOLO»: продукт не предполагает, что агенту можно без дополнительных ограничений предоставить все доступные интеграции. Его исходный текст — короткий комментарий в дискуссии, а не сравнительное испытание MCP и прямых вызовов API.
Аргумент в пользу MCP — управляемые подключения
MCP описывает взаимодействие приложения с подключаемыми источниками данных и инструментами. Разработчики могут свериться с документацией проекта и репозиторием спецификации, чтобы отделить возможности протокола от решений конкретной реализации.
В комментарии Уиллисона речь прежде всего об устройстве продукта. Если пользователь подключает внешние сервисы к AI-приложению, команде приходится решать, какие инструменты агент увидит, как пользователь подтвердит доступ и где будут храниться учётные данные. Уиллисон считает, что MCP облегчает построение такой системы по сравнению с набором отдельных интеграций для каждого агента.
При этом протокол сам по себе не гарантирует безопасного хранения ключей, корректного разграничения прав или полного журнала действий. Формулировка «MCP позволяет не давать ключ агенту» описывает возможную архитектуру: доступ к секретам остаётся у компонента, который выполняет запрос к сервису. Будет ли это работать безопасно, зависит от того, как разработчики настроят этот компонент, права и журналирование.
Что проверить перед выбором архитектуры
Для команды, которая решает, подключать ли MCP, спор сводится к проверяемым требованиям. Сначала стоит составить список внешних сервисов, доступных агенту, и выяснить, какие учётные данные он может прочитать напрямую. Затем — проверить, может ли пользователь отозвать доступ к отдельному сервису и можно ли восстановить по журналу, какой инструмент вызвал агент. Если всё это уже решено без MCP и дополнительных подключений не планируется, Уиллисон не утверждает, что протокол нужно внедрять ради самого протокола.
Если же приложение должно предоставлять пользователям набор управляемых интеграций, прямой вызов API не снимает вопросов авторизации и аудита. Именно для такого случая аргумент Уиллисона наиболее применим. Его комментарий не содержит измерений затрат на внедрение и не доказывает, что MCP надёжнее любой альтернативной архитектуры; это позиция разработчика о том, какие задачи остаются за пределами сценария с агентом, которому «разрешено всё».