Microsoft объявила о выпуске версии 2.0 официального комплекта средств разработки MCP для C#, одновременно реализовав спецификацию 2026-07-28. Выпуск изменяет способ работы MCP-серверов через HTTP, делая их по умолчанию не имеющими состояния, добавляет унифицированные HTTP-заголовки и поддерживает многошаговые запросы, позволяющие инструментам запрашивать ввод у пользователя или языковой модели без зависимости от постоянного сеанса.
Выпуск предназначен для разработчиков, создающих MCP-серверы и клиенты на .NET, при этом стабильные API версии 1.x продолжают работать. Поддерживаются платформы net8.0, net9.0 и net10.0, а также netstandard2.0 для использования с .NET Framework.
Серверы без состояния по умолчанию
В предыдущих выпусках использование Streamable HTTP требовало завершить рукопожатие инициализации и создать сеанс, а затем отправлять заголовок Mcp-Session-Id с каждым последующим запросом. Это связывало запросы с экземпляром сервера, выдавшим идентификатор, что при работе нескольких экземпляров требовало фиксированной маршрутизации или переноса сеансов.
Спецификация 2026-07-28 отменяет рукопожатия initialize и initialized, а также заголовок Mcp-Session-Id, перенося версию протокола и возможности в каждый запрос. В результате любой экземпляр сервера может обработать любой запрос без необходимости в фиксированных сеансах или общих хранилищах сеансов на уровне протокола. Благодаря этому развертывание MCP-серверов в serverless-средах, средах с несколькими экземплярами или на периферии становится ближе к запуску обычного приложения ASP.NET Core за балансировщиком нагрузки.
В версии 2.0 параметр HttpServerTransportOptions.Stateless по умолчанию получает значение true; при необходимости можно включить режим с состоянием, если нужны сообщения, не инициированные сервером, в сторону клиента, или состояние транспорта, связанное с сеансом. Сеансы остаются доступным вариантом, но больше не являются основной настройкой.
HTTP-заголовки для маршрутизации и мониторинга
Режим без состояния превращает запрос MCP в самодостаточный HTTP POST-запрос, позволяя стандартной инфраструктуре обрабатывать его как любой другой HTTP-трафик. Спецификация предусматривает такие заголовки, как Mcp-Method и Mcp-Name, а также возможность преобразовывать некоторые параметры инструмента в заголовки вида Mcp-Param-*.
Балансировщик нагрузки, прокси, шлюз или межсетевой экран веб-приложений могут использовать эти заголовки для маршрутизации и мониторинга без анализа тела запроса JSON-RPC. Тело запроса остаётся доверенным источником; если значение заголовка отличается от значения в теле, сервер отклоняет запрос с ошибкой HeaderMismatch. Конструкция также поддерживает кодирование значений, не поддерживаемых заголовками, например значений, содержащих символы ASCII, с использованием указателя Base64.
Многошаговые запросы для интерактивных инструментов
Функция Multi Round-Trip Requests, или MRTR, добавляет способ работы с инструментами, которые не могут завершить задачу за один вызов. Вместо подключения сервера к клиенту через активный сеанс во время выполнения запроса сервер возвращает результат типа InputRequiredResult, содержащий запросы ввода и непрозрачное состояние под названием requestState.
Клиент выполняет требуемое действие, например запрашивает подтверждение пользователя, вызывает языковую модель или отображает корни рабочих пространств, а затем повторно отправляет тот же вызов инструмента, добавляя inputResponses и requestState. Процесс можно повторять в течение нескольких раундов, при этом информация для продолжения передаётся внутри полезной нагрузки, поэтому сеанс для операции не требуется.
Высокоуровневый McpClient автоматически обрабатывает MRTR после регистрации соответствующих обработчиков. Выпуск также может использовать мост совместимости со старыми клиентами при наличии сеанса с состоянием. Однако старый клиент, работающий без сеанса, не может выполнить многошаговое взаимодействие, поэтому инструмент должен предоставлять альтернативный путь, например передавать требуемое значение непосредственно в параметре вызова.
Совместимость и доступные пакеты
Стабильные API версии 1.x, не признанные устаревшими, продолжают компилироваться и выполняться в версии 2.0, тогда как устаревшие изменения отображаются в виде предупреждений, а не удалений. Клиент версии 2.0 может использовать старое рукопожатие инициализации при подключении к старому серверу, а сервер версии 2.0 принимает такое рукопожатие от старого клиента.
Единственным исключением из совместимости протокола является расширение Tasks: его переработанная конструкция в версии 2.0 заменяет экспериментальную Tasks из спецификации 2025-11-25 и несовместима с ней на уровне интерфейса и протокола. Теперь Tasks доступно в отдельном пакете ModelContextProtocol.Extensions.Tasks, а экспериментальные MCP Apps входят в ModelContextProtocol.Extensions.Apps.
В основные пакеты входят ModelContextProtocol.Core для клиента и низкоуровневых компонентов, ModelContextProtocol для большинства серверов и ModelContextProtocol.AspNetCore для серверов Streamable HTTP. В публикации говорится, что следующим направлением в серии 2.x станет комплексная аутентификация и авторизация на основе более тесной совместимости с OAuth и OpenID Connect.