MCP: что это и как работает stateless на 3 инструментах заметок в 2026

Что такое MCP и зачем он нужен?

Без MCP модель остаётся советчиком. Она может написать инструкцию, предложить код или объяснить ошибку. Но сама по себе она не знает содержимое базы заметок и не умеет выполнить действие в ней.

MCP добавляет прослойку между моделью и внешней системой. Такой системой может быть локальный файл, база данных или отдельное приложение. Сервер описывает доступные инструменты. Модель получает эти описания и решает, какой инструмент нужен для текущего запроса.

Главная граница здесь простая: инструмент делает конкретное действие. Доступ ограничен отдельными операциями: «создай заметку», «добавь текст», «прочитай заметку». Такой набор возможностей проще проверять и контролировать, чем свободный shell-доступ и произвольные команды.

Например, пользователь пишет: «Создай заметку о встрече и добавь туда три пункта». Модель не открывает файл напрямую. Она выбирает инструмент создания заметки, получает идентификатор, затем вызывает инструмент добавления текста.

Для читателя это выглядит как один разговор. Внутри проходит несколько отдельных действий.

MCP даёт модели заранее определённые рычаги - и не более того. Чем точнее эти рычаги, тем проще понять, что именно произошло, когда результат оказался неправильным.

Кто за что отвечает в связке MCP-клиент и MCP-сервер?

Разложу роли без документации:

• Модель читает сообщение пользователя и выбирает действие. Она видит описание доступных инструментов: название, назначение и аргументы.
• MCP-клиент связывает модель с сервером. Он получает решение модели, оформляет вызов инструмента и отправляет его дальше. Поэтому mcp client - не само приложение с данными и не модель.
• MCP-сервер принимает вызов. Он проверяет аргументы, выполняет конкретное действие и возвращает результат.
• Внешний источник хранит или отдаёт данные. В локальном примере это SQLite или JSON-файл.

Путь запроса выглядит так:

1. Ты пишешь: «Добавь текст в заметку».
2. Модель выбирает append_to_note.
3. MCP-клиент передаёт серверу имя инструмента и аргументы.
4. MCP-сервер добавляет текст в хранилище.
5. Сервер возвращает результат клиенту.
6. Модель показывает итог в чате.

Модель не обязана знать файл и способ записи: это зона ответственности сервера. Клиент не лезет в содержимое базы, его задача - передать вызов.

Такое разделение полезно именно в вайб-кодинге. Когда агент переписал часть приложения, проще искать поломку по границе: модель выбрала не тот инструмент, клиент передал неверные данные или сервер неправильно обработал аргументы.

Почему модель не вызывает инструмент напрямую?

Представь три слоя:

Модель отвечает на вопрос: «Что надо сделать?» Она выбирает инструмент и заполняет его аргументы. Например, передаёт note_id и текст, который нужно добавить.

Клиент отвечает на вопрос: «Куда и в каком формате отправить вызов?» Он знает, к какому MCP-серверу подключаться, и передаёт вызов дальше.

Сервер отвечает на вопрос: «Как выполнить действие?» Он открывает SQLite или JSON-файл, меняет данные и отдаёт результат.

Если убрать клиент и сервер, модели пришлось бы дать свободный доступ к окружению. Тогда она сама решала бы, какой файл открыть, какую команду запустить и куда отправить данные. Такой доступ сложнее ограничить и проверить.

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

Что изменилось при переходе от сессии к stateless?

В старой схеме клиент проходил обязательное начало соединения:

1. Отправлял initialize.
2. Получал Mcp-Session-Id.
3. Передавал этот идентификатор в следующем запросе.
4. Вызывал инструмент внутри созданной сессии.

У нового варианта другая логика. Один вызов инструмента укладывается в один HTTP-запрос. В нём передаётся версия протокола MCP-Protocol-Version, а имя метода и инструмента дублируется в заголовках Mcp-Method и Mcp-Name.

Серверу больше не требуется хранить ID сессии и направлять запросы на тот же backend через sticky routing. Любой запрос должен быть понятен сам по себе.

На этом месте я останавливаюсь на важной границе. Stateless относится к протокольному уровню MCP. Он не означает, что приложение обязано забывать все данные после каждого запроса.

Практический пример у Simon Willison показывает масштаб работы модели: один вопрос к Datasette привёл к 7 отдельным SQL-запросам. В другом примере MCP-инструмент вернул число заметок 151. За разговором пользователя стояла цепочка вызовов, несколько последовательных операций.

Новая спецификация MCP 2026-07-28 убрала обязательные initialize, initialized, Mcp-Session-Id и зависимость от sticky routing. Состояние приложения при этом остаётся задачей самого приложения.

Переход к stateless нужен не ради нового названия. Он убирает лишнюю транспортную сессию. Состояние заметки, корзины или задачи переносится в явный идентификатор.

Как сделать локальный MCP-вызов stateless по шагам?

1. Определи минимальный endpoint.

   Сделай один локальный HTTP endpoint /mcp. Не добавляй сразу авторизацию, десятки инструментов и сложную бизнес-логику: фактура не содержит готовой настройки конкретного клиента или команды запуска.

   Важно разделить две вещи. Endpoint принимает MCP-запрос. Хранилище держит заметки. Сам endpoint не должен связывать вызовы через скрытый Mcp-Session-Id.

   Минимальная схема выглядит так:

   Скопировать

   /mcp
   ├── create_note() -> note_id
   ├── append_to_note(note_id, text)
   └── get_note(note_id)

2. Создай заметку с идентификатором.

   Инструмент create_note создаёт запись и возвращает note_id. Этот ID становится явной связью между будущими вызовами.

   Сервер может хранить запись в SQLite или JSON-файле. Точная схема хранения, конкурентный доступ и обработка ошибок в фактуре не описаны, поэтому я не буду выдавать выдуманный код за готовую реализацию.

   Правило для инструмента простое: связь должна быть видна снаружи. Верни идентификатор наружу.

   json

   Скопировать

   {
     "tool": "create_note",
     "result": {
       "note_id": "созданный сервером идентификатор"
     }
   }

3. Добавь текст по `note_id`.

   Инструмент append_to_note получает note_id и text. Сервер находит запись по этому ID и добавляет текст в SQLite или JSON-файл.

   Следующий вызов не должен рассчитывать на память предыдущего HTTP-запроса. Клиент передаёт note_id явно.

   json

   Скопировать

   {
     "tool": "append_to_note",
     "arguments": {
       "note_id": "идентификатор из предыдущего результата",
       "text": "Первый пункт заметки"
     }
   }

4. Прочитай заметку отдельным вызовом.

   Инструмент get_note получает тот же note_id и возвращает сохранённый текст. Так проверяется состояние приложения поверх stateless-протокола.

   json

   Скопировать

   {
     "tool": "get_note",
     "arguments": {
       "note_id": "тот же идентификатор"
     }
   }

5. Проверь два независимых HTTP-запроса.

   Сначала отправь вызов создания заметки. Получи note_id. Затем отдельным запросом вызови добавление текста или чтение заметки.

   В обоих запросах используй endpoint /mcp. Не передавай Mcp-Session-Id. Для нового stateless-вызова фактура фиксирует заголовки MCP-Protocol-Version, Mcp-Method и Mcp-Name.

   http

   Скопировать

   POST /mcp
   MCP-Protocol-Version: 2026-07-28
   Mcp-Method: tools/call
   Mcp-Name: create_note

   http

   Скопировать

   POST /mcp
   MCP-Protocol-Version: 2026-07-28
   Mcp-Method: tools/call
   Mcp-Name: get_note

   Это схема проверки, а не законченный JSON-RPC payload: фактура не содержит полного формата тела и всех обязательных заголовков. Я не подставляю недостающие поля из головы.

6. Проверь промптом границы инструмента.

   Передай ИИ-агенту короткое требование. Оно помогает не смешать транспортную сессию и состояние заметки.

   Проверка stateless-схемы заметокСкопировать промпт

   Собери минимальный локальный MCP-артефакт с endpoint /mcp и тремя инструментами:
   create_note, append_to_note и get_note.
   
   Состояние заметок храни в SQLite или JSON-файле.
   create_note должен возвращать явный note_id.
   append_to_note и get_note должны принимать note_id в аргументах.
   Не используй Mcp-Session-Id для связи вызовов.
   Покажи отдельно, какие данные передаются в первом HTTP-запросе и какие во втором.
   Не добавляй другие инструменты, авторизацию и сложную бизнес-логику.
   Если точного JSON-RPC payload или команды запуска не хватает в исходных данных, укажи это явно и не выдумывай.

7. Проверь результат в хранилище.

   После вызова append_to_note вызови get_note с тем же note_id. Текст должен прийти из SQLite или JSON-файла, а не из памяти протокольной сессии.

   Если сервер перезапустился, память одного процесса не должна считаться надёжным хранилищем. Для локального примера фактура разрешает SQLite или JSON-файл, но не задаёт точную реализацию восстановления и конкурентной записи. Это место надо проверять отдельно.

Что делать, если приложению всё ещё нужно состояние?

Старая сессия смешивала несколько смыслов. Она могла означать соединение, пользователя, чат или последовательность вызовов. Из-за этого один и тот же ID не всегда совпадал с тем, что человек считал одной рабочей сессией.

В stateless-схеме смысл задаёт приложение:

• note_id указывает на заметку;
• basket_id указывает на корзину;
• job_id указывает на длительную задачу.

Сервер сам создаёт такой идентификатор и возвращает его в результате. Клиент сохраняет значение и передаёт его дальше. Инструменты получают состояние явно и не достают его из памяти MCP-соединения.

Например, create_note возвращает note_id. Затем append_to_note(note_id, text) меняет конкретную заметку. get_note(note_id) читает её. Протокол при этом остаётся stateless, а поведение приложения остаётся stateful.

Такой подход требует аккуратнее проектировать аргументы инструментов. Зато из вызова видно, с какой сущностью идёт работа. Это проще проверять в логах и при повторном запросе.

Что ломается после перехода на stateless?

Крайние случаи начинаются с совместимости. Клиент или middleware может по-прежнему отправлять initialize и ожидать Mcp-Session-Id. Новый сервер такой сценарий не обязан поддерживать.

Дальше идут функции, которым нужно обратиться к клиенту после вызова. В stateless-режиме отключается часть сценариев, связанных с unsolicited notifications и server-to-client requests. Client sampling, elicitation и roots тоже могут быть недоступны в legacy stateless-режиме.

Ломается и внутренняя диагностика. Раньше счётчик можно было привязать к sessionId. После удаления ID несколько клиентов с одинаковой ошибкой могут выглядеть как один поток событий. Для корреляции нужен другой ключ: явный идентификатор операции, failure fingerprint или внешняя телеметрия.

Авторизация тоже не исчезает вместе с сессией. Каждый запрос должен сам нести или получать из middleware credential, identity, права доступа и контекст аудита. Использовать старый ID как доказательство личности больше нельзя.

Есть и инфраструктурная ловушка. Любой запрос может попасть на другой экземпляр сервера. Поэтому память одного процесса не подходит для надёжного хранения счётчиков, задач и состояния. Данные надо вынести в SQLite, JSON-файл или другое внешнее хранилище с учётом ограничений конкретной реализации.

Поддержка новой схемы пока неоднородна: правильная по новой спецификации схема может не заработать в старой обвязке.

Вопросы и ответы