Миграция сервера MCP на спецификацию 2026-07-28: двадцать минут, шаг за шагом

Ничего не сломалось, и именно это самое тревожное. 28 июля 2026 года Model Context Protocol опубликовал свою спецификацию 2026-07-28 — крупнейшие изменения с момента появления удаленного MCP. Была устарожена заголовочная информация, от которой зависели серверы, а сама модель передачи данных изменилась, однако совместимость была сохранена. Серверы продолжали работать без записей о стеке вызовов, предупреждений или сигналов об ошибках.

Это пример тихого технического долга. Он остается скрытым до тех пор, пока кому-то не понадобится масштабирование, или пока не истечет двенадцатимесячный период устаревания и какая-либо зависимость перестанет поддерживаться. Сервер, использующий версию от 2025-11-25, отстает от современных стандартов. Сервер, работающий с устаревшей транспортной моделью HTTP+SSE, использует технологии, которые уже устарели, а также, возможно, три функции, срок поддержки которых уже истекает.

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

Почему был отказ от сессий

Инженерные соображения объясняют всё остальное. MCP был запущен в конце 2024 года как протокол, ориентированный на сессии: клиент инициирует соединение с помощью команды initialize, сервер выдает Mcp-Session-Id, который затем передается во всех последующих запросах. Это подходило для первоначального случая, когда на одной машине работал один клиент и один сервер через стандартный ввод-вывод.

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

Подумайте, что требует идентификатор сессии. Либо механизм «липкого» маршрутизирования, позволяющий одному клиенту всегда обращаться к одному и тому же экземпляру, либо общий хранилище сессий, к которому может обращаться любой экземпляр. Обычному HTTP-сервису вдруг требуется балансировка нагрузки с учетом аффинности и что-то вроде Redis, просто для обеспечения транспортной связи, прежде чем он сможет выполнять какие-либо полезные действия.

В посте о выпуске от Дэвида Сориа Парры и Дена Делимарски это сформулировано прямо: MCP переходит от двунаправленного протокола с состоянием к протоколу запроса/ответа без состояния, что было одним из самых часто запрашиваемых изменений со стороны разработчиков, желающих надежности и масштабируемости. Срочность этого изменения обусловлена масштабами использования. SDK уровня 1 совершают почти полмиллиарда загрузок в месяц, а SDK на TypeScript и Python каждый из них превысил отметку в миллиард загрузок. Протокол такого масштаба не может постоянно требовать, чтобы при каждой развертке решалась проблема аффинности сессий.

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

Пять изменений, которые необходимо понимать

1. Отсутствие процедуры подтверждения соединения и заголовка сессии

Обмен сообщениями initialize и initialized, а также заголовок Mcp-Session-Id официально устарели (SEP-2575 и SEP-2567). Каждый запрос рассматривается отдельно, причем версия протокола, идентификатор клиента и его возможности указываются в разделе _meta. Запрос согласно новым спецификациям выглядит следующим образом:

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

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
 "_meta":{"io.modelcontextprotocol/clientInfo":
              {"name":"my-app",
                "version":"1.0"}
          }}}

Клиент, желающий заранее узнать возможности сервера, может воспользоваться новым RPC server/discover; он является необязательным и больше не представляет собой обязательный этап взаимодействия.

Часто существует опасение, что приложения больше не смогут сохранять состояние. Однако это возможно. Исключение сессии из протокола не обязывает приложение быть безсостоянийным. Когда серверу требуется преемственность, инструмент должен создать явный идентификатор, который позже будет возвращен моделью в качестве аргумента. Это работает лучше, чем хранение состояния в самом механизме передачи данных, поскольку модель может видеть этот идентификатор и передавать его от одного инструмента к другому. Видимое состояние лучше, чем невидимое.

2. Два обязательных заголовка

Начиная с сейчаса, HTTP-запросы к Streamable должны содержать поля Mcp-Method и Mcp-Name (SEP-2243), причем сервер должен подтвердить их соответствие запросу. Это приносит преимущества инфраструктуре: шлюз, ограничитель скорости или WAF могут направлять трафик и отслеживать его объем с использованием этих заголовков, избегая при этом парсинга JSON. Те, кто ранее отказался от ограничения скорости по отдельным инструментам на уровне края сети из-за того, что название инструмента находилось внутри тела запроса, теперь имеют выход из этой ситуации.

3. Ответы в формате списка, подлежащие кэшированию

Результаты вызовов tools/list, prompts/list, resources/list и resources/read теперь включают параметры ttlMs и cacheScope (SEP-2549) и возвращаются в определенном порядке. Клиенты могут кэшировать каталог ваших инструментов, сохраняя стабильность кэшей запросов при повторных подключениях. Поскольку значительная часть расходов агента связана с многократной передачей определений инструментов, это также способствует снижению затрат.

4. Ужесточение механизмов авторизации

Было внесено четыре изменения, одно из которых может объяснить баг, с которым вы уже сталкивались:

• Серверы авторизации должны возвращать параметр iss, определенный в RFC 9207, и клиенты обязаны проверять его перед использованием кода (SEP-2468), тем самым устраняя уязвимость, связанную с путаницей.
• Клиенты устанавливают application_type во время динамической регистрации клиентов (SEP-837), поэтому серверы авторизации перестают отклонять перенаправления с localhost для десктопных приложений и приложений командной строки. Если процесс OAuth в приложении командной строки когда-либо завершался с ошибкой redirect_uri, скорее всего, это и является причиной.
• Учетные данные клиента привязаны к организации, которая их создала, и не могут быть использованы в других серверах авторизации (SEP-2352).
• Сама процедура динамической регистрации клиентов официально устарела в пользу документов метаданных идентификатора клиента. Она по-прежнему работает, но будет устранена в более поздней версии.

5. Список устаревших функций

Здесь термин «устаревший» имеет весомое значение. Функции Roots, Sampling and Logging (SEP-2577) устарели, но продолжают работать; у них есть как минимум двенадцать месяцев на замену, и новые реализации не должны их использовать. Традиционный протокол передачи HTTP+SSE также устарел, и у него также есть год на постепенную замену.

Функция Tasks была перенесена, а не устаревшей объявлена. Она перешла из экспериментального ядра в расширение io.modelcontextprotocol/tasks; для получения данных от нее используется метод tasks/get, а для обновления — новый метод tasks/update (SEP-2663). Теперь уведомления о изменениях передаются через единственный поток subscriptions/listen, в который клиенты могут подключиться по своему выбору.

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

Миграция, шаг за шагом

В этом руководстве используется Python SDK, замена которого является наиболее сложной из четырех вариантов, хотя структура остается прежней в TypeScript, Go и C#.

Минуты 0–2: принятие решения. Если сервер использует методы выборки, извлечения данных или другие аналогичные подходы, ему требуется полная переработка, о которой говорится ниже. Если же сервер предоставляет лишь инструменты и ресурсы, можно продолжать дальше.

Минуты 2–5: обновление SDK. Python SDK достиг версии 2.0.0 в день публикации спецификации, и теперь команда pip install mcp загружает версию 2.x.

pip install --upgrade "mcp>=2"

Одно важное изменение, о котором стоит знать: SDK был перенесен с httpx на httpx2. Если httpx используется где-либо еще в вашей иерархии зависимостей, решите эту проблему немедленно.

От 5 до 10 минут: переименуйте класс. Это касается всех Python-серверов. FastMCP теперь называется MCPServer; алиасов и механизмов временной замены нет:

# Before, on mcp 1.x
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("Demo")

# After, on mcp 2.x
from mcp.server.mcpserver import MCPServer

mcp = MCPServer("Demo")

В том же обновлении произошли ещё три переименования:

# Wire types are snake_case now
result.isError        # → result.is_error
tool.inputSchema      # → tool.input_schema

# The error class matches the new capitalisation
except McpError:      # → except MCPError:

mcp-types теперь является отдельным пакетом, но mcp.types по-прежнему остается поддерживаемым путем импорта, поэтому такие импорты продолжают работать. Внимание: это не влияет на тех, кто использует отдельный пакет fastmcp вместо официального SDK. Это отдельный проект с собственными версиями 3.x, и одной из причин переименования является необходимость разделения этих двух проектов.

Минуты 10–15: удаление компонентов, связанных с сессиями. Можно удалить словари сессий, таймеры очистки и экземпляр Redis, созданный исключительно для хранения состояния сессий. Если действительно требуется сохранение преемственности между вызовами, используйте шаблон обработчиков:

# Instead of hiding state in a session the model can't see:
@mcp.tool()
def open_dataset(path: str) -> str:
    """Open a dataset and return a handle for subsequent calls."""
    handle = register_dataset(path)     # your own store, your own TTL
    return handle                        # the model now HOLDS this

@mcp.tool()
def query_dataset(handle: str, query: str) -> list[dict]:
    """Query a previously opened dataset."""
    return lookup(handle).query(query)

Минуты 15–18: проверка новых заголовков. Сервер должен убедиться, что передаваемые значения Mcp-Method и Mcp-Name совпадают с параметрами запроса. SDK покрывает обычные сценарии, но при использовании пользовательского шлюза или реализованного вручную механизма передачи данных необходимо провести проверку «от конца до конца».

Минуты 18–20: исправление кода ошибки. Его легко упустить, что приводит к непонятному поведению клиента. Для ошибок отсутствия ресурса следует использовать стандартный код JSON-RPC invalid-params -32602, а не собственный код MCP -32002.

Готово к выпуску

Один и тот же MCPServer поддерживает обе версии протокола, поэтому клиенты 2025 года могут продолжать работать с мигрированным сервером без необходимости настраивать что-либо ни с одной стороны. Именно поэтому его можно выпустить в обычный вторник, без необходимости согласовывать специальный день для всех клиентов.

Когда это занимает больше времени

Серверы, использующие методы выборки данных, запроса информации или другие аналогичные подходы, сталкиваются с необходимостью полной переработки кода, что, по мнению Real Python, является самым сложным пунктом в списке задач миграции. Ранее сервер мог инициировать запрос и возвращаться к клиенту через открытый двунаправленный поток обмена данными. В безсостоянийном дизайне такого потока нет, поэтому для решения проблемы применяется механизм многократных запросов-ответов (SEP-2322).

Новый подход работает следующим образом: сервер отвечает с информацией resultType: „input_required“ и вопросами, на которые требуются ответы, после чего клиент повторяет первоначальный запрос, передавая свои ответы в поле inputResponses. Это меняет способ написания программных инструментов: обработчик не может остановиться на полпути и ждать ответа. Его могут вызывать несколько раз для выполнения одной логической операции, и он должен правильно продолжить работу по получении входных данных; поэтому всё, что хранится в локальных переменных во время паузы, должно быть сохранено в месте, до которого можно будет добраться при повторной попытке.

Польза действительно реальна. Руководитель отдела продуктов Supabase заявил, что реализация такой функции давно была в планах, но она казалась невозможной из-за того, что их сервер MCP работает без сохранения состояния, тогда как MRTR делает это возможным, позволяя инструментам сначала уточнять информацию у пользователя — например, стоимость нового проекта или информацию о запросе, который может удалить данные. Разработка такого инструмента становится немного сложнее, но его запуск в масштабах без сохранения состояния становится возможным.

Что даёт новый протокол

Manufact управляет тысячами серверов MCP и поддерживает фреймворк с открытым исходным кодом mcp-use. Было установлено, что версия SDK v2 на 83% меньше по размеру и на 25% быстрее благодаря новой архитектуре с разделением на клиент и сервер. В обзоре экосистемы от Agentic AI Foundation говорится, что теперь сервер ведет себя как любой другой HTTP-сервис, отвечая с той инстанции, которую выбирает балансировщик нагрузки, при этом шлюзы осуществляют маршрутизацию и ограничение скорости передачи данных с помощью заголовков. Двенадцатимесячная стратегия развития гарантирует, что протокол также будет продолжать совершенствоваться.

Для открытого стандарта процесс внедрения прошел быстро. В течение нескольких дней поставщики инфраструктуры, поддерживающие SDK, облачные платформы и производители инструментов объявили о своей поддержке, опубликовали инструкции по миграции и выпустили готовые решения для производственного использования. SDK Agents от Cloudflare с самого начала соответствовало спецификации, Amazon Bedrock AgentCore предоставляет безсостоянийный ядро, а к проекту присоединились Microsoft Foundry, Netlify, Figma, Supabase и Honeycomb. По словам Honeycomb, почти один из пяти ежемесячных интерактивных запросов теперь поступает от агентов, что объясняет важность этого явления. Агенты уже вышли за рамки этапа демонстраций.

Оставаться на версии 1.x

Это вполне обоснованный выбор. Можно фиксировать текущую версию и ждать:

# Buys you time, keeps security patches coming
pip install "mcp>=1.28,<2"

Узнайте две вещи во время работы с этим инструментом. Линейка 1.x находится в режиме технического обслуживания, где вносятся только исправления безопасности. Кроме того, расширение Tasks ещё не включено в версию Python SDK 2.0, поэтому оно исчезло из основных спецификаций, так и не попав в SDK. Для пользователей Python, которые зависят от Tasks, правильным решением будет подождать. Установите напоминание в календаре на дату, через двенадцать месяцев, когда закончится поддержка функций Roots, Sampling и Logging, ведь периоды устаревания кажутся бесконечными до самого их окончания.

Опасность тихого устаревания

Радикальные изменения проявляются явно: они мешают сборке, вызывают ошибки у пользователей и затем исправляются. Устаревание же по своей сути является тихим процессом. Сервер продолжает работать, тесты проходят, и ничего не становится красным, в то время как проблемы накапливаются: срок действия транспортного протокола, отсутствие возможности легкого горизонтального масштабирования и зависимость от компонента, находящегося в режиме технического обслуживания, пока экосистема развивается дальше. Значение в MCP-Protocol-Version представляет собой дату, и стоит проверить, насколько оно уже устарело.

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