MCP слишком усложнили: будущее протокола может оказаться в отказе от состояния

Общепринятая логика выглядит убедительно: если модель должна работать с инструментами, серверу нужно знать, кто к нему подключён, какие возможности уже согласованы и на каком шаге находится диалог. Поэтому MCP строится вокруг последовательности инициализации, после которой клиент и сервер обмениваются сообщениями в рамках сессии. Для локального процесса это почти незаметно. Для удалённого сервиса, масштабируемого в облаке, такая архитектура означает хранение состояния, маршрутизацию запросов к правильному экземпляру и дополнительные точки отказа.

Саймон Уиллисон предлагает посмотреть на это с противоположной стороны. А что если MCP-серверу вообще не нужно помнить клиента? В статeless-модели каждый HTTP-запрос содержит всё необходимое для выполнения операции: описание вызова, параметры и ожидаемый формат ответа. Сервер можно запускать как обычный веб-сервис, распределять между экземплярами и уничтожать после обработки запроса. Это не отменяет сам протокол — исчезает только предположение, что любая интеграция обязана быть разговором с памятью.

Именно эта рамка подтолкнула Уиллисона к двум практическим проектам — mcp-explorer и datasette-mcp. Первый позволяет исследовать MCP-инструменты через интерфейс, не превращая знакомство с протоколом в отдельную инфраструктурную задачу. Второй связывает MCP с Datasette, превращая базы данных и запросы к ним в доступные для моделей инструменты. Важен не размер этих проектов, а направление: полезность протокола проверяется не масштабом агентной платформы, а тем, насколько дёшево подключить к нему один конкретный источник данных.

В этом и заключается переворот. Stateful MCP выглядит мощнее, потому что обещает длительный контекст и сложное взаимодействие. Но для множества задач — чтения таблицы, вызова API, поиска документа или выполнения одного SQL-запроса — состояние становится не возможностью, а накладными расходами. Stateless-подход возвращает MCP к роли тонкого стандарта обмена, а не обязательной операционной системы для агентов. Чем меньше сервер знает о клиенте, тем проще его тестировать, разворачивать и повторно использовать.