GitHub MCP Server заранее поддержал stateless-спецификацию MCP перед релизом 28 июля

23 июля 2026 года GitHub сообщил, что официальный GitHub MCP Server уже совместим с версией MCP 2026-07-28, хотя финальная спецификация выйдет 28 июля. Новый протокол убирает обязательные сессии и процедуру initialize, упрощая масштабирование удалённых серверов и сокращая обработку каждого запроса.

GitHub MCP Server
GitHub MCP Server

GitHub MCP Server уже принимает запросы по версии MCP 2026-07-28

GitHub объявил о поддержке новой спецификации за пять дней до её запланированного финального выпуска. Речь идёт о крупной переработке Model Context Protocol — открытого стандарта, через который AI-агенты получают доступ к внешним данным и инструментам.

Официальный GitHub MCP Server связывает совместимые AI-клиенты с GitHub. Через него агент может читать файлы в репозитории, искать код, работать с issues и pull request, проверять запуски GitHub Actions, анализировать уведомления и обращаться к данным о безопасности. Пользователь формулирует задачу обычным языком, а модель выбирает подходящий инструмент сервера и отправляет структурированный запрос.

Версия MCP 2026-07-28 пока остаётся предстоящей спецификацией. Её релиз-кандидат опубликован проектом MCP, а финальный документ запланирован на 28 июля 2026 года. GitHub заранее перевёл свой сервер на новый протокол и сохранил совместимость с клиентами, использующими предыдущие версии.

Обязательные сессии исчезают из транспортного уровня MCP

Предыдущая схема Streamable HTTP начиналась с вызова initialize. Сервер создавал идентификатор сессии Mcp-Session-Id, после чего клиент прикладывал его к следующим запросам. В распределённой инфраструктуре это требовало закреплять клиента за конкретным экземпляром сервера либо хранить состояние сессий в общей базе.

MCP 2026-07-28 убирает процедуру initialize, заголовок Mcp-Session-Id и протокольную сессию. Каждый вызов содержит сведения, необходимые для самостоятельной обработки. Запрос можно отправить на любой доступный экземпляр сервера за обычным балансировщиком нагрузки.

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

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

Удаление Redis сокращает обращения к базе данных

В GitHub назвали три изменения, сделанные внутри GitHub MCP Server. Первое связано с отказом от Redis-сессий. Запись в базу при initialize исчезла, как и чтение данных сессии при каждом последующем вызове.

Раньше даже простой запрос к инструменту сопровождался обращением к общему хранилищу состояния. После перехода на stateless-модель экземпляр сервера получает нужные данные из самого запроса. GitHub описывает результат как более быструю обработку без потери пользовательских возможностей.

Практический эффект особенно заметен при большом количестве коротких обращений. Например, AI-агент во время анализа pull request может последовательно запросить список файлов, содержимое нескольких фрагментов, комментарии и результаты проверок. Удаление служебных чтений из Redis сокращает дополнительную работу на каждом шаге такой цепочки.

HTTP-заголовки заменяют предварительный разбор тела запроса

Новая спецификация требует передавать служебные сведения в гарантированных HTTP-заголовках, включая метод MCP и имя вызываемого инструмента. Шлюзы, балансировщики и системы ограничения частоты запросов могут принимать решения до разбора JSON-тела.

GitHub использует часть этих данных для журналирования и поиска секретов. В прежней реализации инфраструктуре приходилось заранее просматривать содержимое каждого запроса, прежде чем его получал официальный SDK. Теперь нужные значения читаются из заголовков.

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

Многошаговые запросы сохраняют вход пользователя без постоянного соединения

MCP-сервер иногда должен запросить у человека дополнительное действие: подтвердить удаление файлов, выбрать параметр или пройти авторизацию. Этот механизм называется elicitation. В stateless-версии каждый этап такого диалога оформляется отдельным HTTP-запросом.

GitHub MCP Server применяет URL elicitation в локальном режиме stdio, чтобы упростить вход пользователя. После обновления официальный Go SDK предоставляет совместимую обёртку, которая обслуживает прежний и новый варианты обмена.

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

Официальный Go SDK сохраняет работу старых клиентов

GitHub MCP Server построен на официальном Go SDK для MCP. В документации SDK версия 1.7.0 и новее указана как совместимая с MCP 2026-07-28 и несколькими предыдущими версиями протокола.

GitHub сообщает, что SDK первого уровня уже выпустили бета-поддержку новой спецификации и сохранили обратную совместимость. Пользователям сервера сейчас не требуется менять конфигурацию ради сохранения подключения. Старые клиенты продолжают общаться через поддерживаемую версию протокола, а обновлённые клиенты смогут использовать stateless-схему.

Администраторам собственных MCP-серверов ситуация требует отдельной проверки. В спецификации удалены handshake и протокольные сессии, изменена схема многошаговых запросов, появились обязательные HTTP-заголовки. Код, напрямую завязанный на Mcp-Session-Id, sticky routing или чтение метода из JSON-тела на шлюзе, придётся адаптировать.

Тесты соответствия дают проверяемый путь миграции

В новой ветке MCP появились официальные conformance tests — набор сценариев, проверяющих соответствие клиента или сервера спецификации. GitHub предлагает подключить к проекту тестовый набор, черновик документации MCP 2026-07-28 и одну из реализаций SDK первого уровня.

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

До 28 июля документ сохраняет статус релиз-кандидата. Основная архитектура версии 2026-07-28 зафиксирована с 21 мая, а GitHub уже использует её в официальном сервере.

GitHub готовит MCP Server к росту удалённых AI-интеграций

Обновление GitHub MCP Server сосредоточено на инфраструктуре, которую пользователь обычно не видит. Исчезают Redis-сессии и обязательный handshake, запросы становятся самостоятельными, а служебная маршрутизация переносится в HTTP-заголовки.

Для пользователей GitHub новая версия MCP упрощает и ускоряет работу удалённого сервера при увеличении нагрузки. Для команд, создающих собственные серверы, релиз MCP от 28 июля 2026 года предлагает обновлённую транспортную систему: стандартную балансировку, явную передачу состояния и проверку через официальный набор тестов.

До 28 июля спецификация сохраняет статус релиз-кандидата. GitHub уже подтвердил поддержку нового протокола в официальном GitHub MCP Server до даты его финального выпуска.

При использовании материалов сайта необходимо указывать ссылку на TGLand.ru. Если вы копируете фрагменты текста в интернете, прямая гиперссылка, доступная для индексации поисковыми системами, должна быть размещена в начале материала.

Вам также может понравиться