MCP 2026-07-28 подробно: серверы без состояния, приложения MCP, задачи, корпоративная аутентификация и новая агентная инфраструктура

引言

Модельный контекстный протокол (Model Context Protocol) получил самое масштабное архитектурное обновление с момента своего появления.

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

Редакция 2026-07-28 сосредоточена на проблемах, возникающих при выходе MCP за пределы ноутбука разработчика и переходе в крупные производственные среды.

Основное изменение можно резюмировать так:

MCP становится апатридным (без сохранения состояния) на уровне протокола.

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

Но апатридная передача — лишь часть этого обновления.

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

Помимо самого протокола, экосистема MCP пополняется интерактивными приложениями, корпоративным хостингом с авторизацией, туннелями в частных сетях и более мощными инструментами разработчика.

Именно сейчас MCP начинает выглядеть не как удобный коннектор для агентов, а как производственная инфраструктура.

Темпы внедрения MCP стремительно растут

Исходный отчёт подчёркивает скорость роста использования MCP.

Согласно данным из релизного анонса для разработчиков Claude, на которые ссылается исходная статья:

• Ежемесячные загрузки MCP SDK превысили 400 миллионов.
• За год ежемесячное использование SDK выросло примерно в четыре раза.
• Совокупные загрузки TypeScript и Python SDK преодолели очень крупные рубежи.
• Через экосистему коннекторов Claude доступны сотни интеграций MCP.

Эти конкретные данные конца июля относятся к метрикам релизного анонса, а не к цифрам, публикуемым в основной спецификации.

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

Это означает, что ещё до редизайна протокола в июле экосистема уже была довольно масштабной.

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

К этим проблемам относятся:

• Липкие сеансы.
• Общее хранилище сеансов.
• Горизонтальное масштабирование.
• Бессерверные развёртывания.
• Маршрутизация через шлюзы.
• Сложность аутентификации.
• Длительные операции агентов.
• Интерактивные интерфейсы.
• Обратная совместимость.
• Эволюция протокола.

Почему прежняя апатридная архитектура стала проблемой масштабирования

Ранние удалённые развёртывания MCP поддерживали состояние сеанса на уровне протокола.

Клиент обычно инициализировал

устанавливал соединение и получал идентификатор сеанса. Последующие запросы должны были сохранять привязку к этому сеансу.

Упрощённый процесс 2025-11-25 выглядел так:

POST /mcp HTTP/1.1
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {},
    "clientInfo": {
      "name": "my-app",
      "version": "1.0"
    }
  }
}

После инициализации последующие вызовы могли содержать:

Mcp-Session-Id: 1868a90c-3a3f-4f5b

Такой подход работал для многих приложений, но накладывал определённые требования на инфраструктуру.

Производственные развёртывания могли требовать:

• Липкую маршрутизацию балансировщиков нагрузки.
• Общее хранилище сеансов.
• Репликацию сеансов.
• Логику истечения сеансов.
• Обработку отказов.
• Наблюдаемость, учитывающую соединения.
• Особую обработку перезапусков серверов.

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

Новая редакция устраняет это допущение.

MCP теперь апатриден на уровне протокола

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

Официальный пример:

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

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

Больше нет Mcp-Session-Id на уровне протокола.

Больше нет обязательного сеанса соединения, привязывающего запросы к одному экземпляру сервера.

Любой совместимый экземпляр сервера может обработать запрос.

Это значительное улучшение для облачных развёртываний.

Удалённые MCP-серверы теперь могут адаптироваться к традиционным архитектурам:

Клиент
  ↓
API-шлюз / балансировщик нагрузки
  ↓
Экземпляр MCP-сервера A
Экземпляр MCP-сервера B
Экземпляр MCP-сервера C

Запросу больше не нужно возвращаться к тому экземпляру, на который попал предыдущий запрос.

В новом сетевом формате удалено рукопожатие initialize

Апатридный редизайн также удаляет из сетевого формата 2026-07-28 прежний жизненный цикл initialize / initialized.

Информация, которая раньше передавалась только один раз при инициализации, теперь передаётся с каждым запросом через метаданные.

Когда клиент хочет заранее получить сведения о возможностях сервера, он может использовать новый метод server/discover.

Это не означает, что старые клиенты немедленно перестанут работать.

Текущая документация SDK содержит описание поведения совместимости с более ранними версиями протокола. Например, C# SDK может поддерживать новый апатридный

продолжая при этом согласовывать прежнее поведение на основе сеансов с клиентами, использующими протокол 2025-11-25.

Ключевое различие для миграции:

2026-07-28:
Модель запросов без сохранения состояния, без сеансового протокола.

Старые версии:
Инициализационное рукопожатие и поведение с учётом сеанса могут по-прежнему поддерживаться
через согласование версий и совместимые пути SDK.

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

## Протокол без состояния не означает приложение без состояния

Одна из самых распространённых ошибок — понимать это изменение так:

> Приложениям MCP больше не разрешается сохранять состояние.

Это не то, что подразумевает спецификация.

**Уровень протокола** не имеет состояния.

Приложения по-прежнему могут поддерживать состояние там, где оно полезно.

Предположим, инструмент для покупок создаёт корзину.

Сервер может вернуть:

```JSON
{
  "basket_id": "basket_8472"
}

Модель может передать это значение в последующих вызовах:

{
  "basket_id": "basket_8472",
  "item_id": "item_123"
}

Это делает состояние приложения видимым как обычные данные инструмента, а не скрывает его в метаданных транспорта.

Тот же подход можно использовать для сеансов браузера, отчётов, корзин покупок, идентификаторов рабочих процессов, идентификаторов развёртывания, состояния редактирования документов и длительных аналитических задач.

Почему явные дескрипторы могут быть лучше

Видимые дескрипторы имеют несколько преимуществ.

Модель может:

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

Сервер может:

• Проверять дескриптор.
• Устанавливать срок его действия.
• Привязывать его к пользователю или арендатору.
• Отклонять устаревшее состояние.
• Хранить фактическое состояние в базе данных.

Таким образом, MCP без состояния переносит управление состоянием с транспортного уровня на явное проектирование приложения.

Бессерверные и горизонтально масштабируемые развёртывания становятся значительно проще

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

Когда запросы самодостаточны, MCP-серверы могут легче работать в таких средах, как:

• AWS Lambda.
• Cloudflare Workers.
• Vercel.
• Другие бессерверные функции.
• Платформы автоматического масштабирования контейнеров.
• Обычные развёртывания Kubernetes без состояния.
• Граничные среды.

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

Разработчикам по-прежнему нужно учитывать время выполнения, поддержку потоковой передачи, холодные запуски, постоянное состояние приложения, ключи, исходящий сетевой трафик, длительные задачи, требования к файловой системе и подключения к базам данных.

Протокол больше не навязывает сеансовую архитектуру, что устраняет основное препятствие.

Циклический балансировщик нагрузки становится естественным выбором по умолчанию

Горизонтально масштабируемым серверам больше не нужно привязывать отдельного клиента к отдельному экземпляру на уровне протокола.

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

Это улучшает:

• Автоматическое масштабирование.
• Замену экземпляров.
• Восстановление после сбоев.
• Поэтапные развёртывания.
• Маршрутизацию по нескольким регионам.
• Простоту инфраструктуры.

Это также меняет подход авторов серверов к скрытому состоянию в памяти.

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

Хороший тест на миграцию:

Если каждый вызов инструмента попадает на другой процесс сервера, продолжит ли тот же рабочий процесс работу?

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

Многораундовые запросы заменяют постоянные соединения с вызовами

Проектирование без состояния по-прежнему требует способа для сервера запрашивать у клиента дополнительную информацию.

Примеры включают подтверждение пользователя, дополнительные параметры, направляющие вопросы, ответы, сгенерированные моделью, или значения, связанные с рабочим пространством.

Новый механизм — это многораундовые запросы (Multi Round-Trip Requests, MRTR).

Инструмент может вернуть неполный результат:

{
  "resultType": "input_required",
  "inputRequests": {
    "confirm": {
      "type": "elicitation",
      "message": "Удалить 3 файла?",
      "schema": {
        "type": "boolean"
      }
    }
  },
  "requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="
}

Клиент собирает необходимые ответы.

Затем он повторяет исходный вызов с inputResponses и возвращённым requestState.

Поскольку состояние переносится в потоке запроса, другой экземпляр сервера может обработать следующий раунд.

Это гораздо больше соответствует архитектуре без состояния, чем требование долгоживущего соединения между сервером и клиентом.

Маршрутизация на основе заголовков делает MCP более удобным для шлюзов

Новый формат Streamable HTTP добавляет метаданные операций непосредственно в HTTP-заголовки.

Важные заголовки включают:

Mcp-Method: tools/call
Mcp-Name: search

Это важно для производственной инфраструктуры.

API-шлюзы, веб-фаерволы, ограничители скорости или уровни наблюдаемости могут распознавать операции без разбора JSON-тела.

Возможные применения:

• Маршрутизация всех поисковых инструментов в один пул.
• Применение более строгих ограничений к разрушительным операциям.
• Запись задержек по имени инструмента.
• Учёт использования по методам.
• Блокировка недопустимых инструментов на шлюзе.
• Создание независимых политик надёжности.

Спецификация также требует согласованности между заголовками и телом JSON-RPC.

Сервер должен отклонять запросы, в которых они не совпадают.

Результаты списков и чтений поддерживают кэширование

MCP-клиенты часто запрашивают относительно стабильные метаданные, такие как списки инструментов, ресурсы, списки подсказок и чтение ресурсов.

Повторное получение одной и той же информации тратит сетевой трафик и ресурсы сервера.

Новая редакция вводит метаданные кэширования, например:

ttlMs
cacheScope

Эти значения позволяют серверу указать, как долго результат должен оставаться актуальным и может ли результат совместно использоваться между пользователями или контекстами.

Это аналогично принципам обычного HTTP-кэширования.

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

Распределённая трассировка стандартизирована

Редакция также документирует распространение контекста трассировки W3C.

Такие ключи, как:

• traceparent
• tracestate
• baggage

могут распространяться через метаданные MCP.

Это позволяет отслеживать работу в рамках одной распределённой трассы по цепочке:

Хост-приложение
→ MCP-клиент
→ MCP-шлюз
→ MCP-сервер
→ Нисходящий API
→ База данных

Это важно для корпоративных развёртываний, поскольку медленные вызовы инструментов легче отлаживать, когда команды видят, где на самом деле возникает задержка.

Расширения становятся первоклассной функцией протокола

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

Текущая структура даёт расширениям:

• Обратные DNS-идентификаторы.
• Согласование возможностей.
• Независимое версионирование.
• Выделенные репозитории кода.
• Делегированных сопроводителей.
• Официальный путь расширений в рамках процесса SEP.

Это важно, потому что ядро протокола не должно поглощать каждую новую идею.

Функция может сначала созреть как расширение, а проверенные возможности затем могут приблизиться к ядру.

MCP Apps: интерактивный интерфейс в диалоге

Одно из самых заметных расширений MCP — MCP Apps.

Инструменты MCP традиционно возвращают текст, структурированный JSON или ресурсы.

Некоторые задачи требуют интерфейса.

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

MCP Apps позволяет серверу объявлять UI-ресурс, который хост отображает в изолированном iframe.

![Изображение показывает интерактивный процесс MCP Apps. Пользователь отправляет агенту команду "покажи аналитику", агент отображает интерактивное приложение в чате. Приложение взаимодействует с MCP-сервером через вызовы инструментов, сервер возвращает входные данные/результаты инструментов, результаты передаются в приложение.

Пользователь взаимодействует с приложением, приложение запрашивает вызов инструмента, сервер возвращает свежие данные, приложение обновляется до новых данных. Эта схема тесно связана с контекстом и наглядно показывает полный процесс взаимодействия MCP Apps — от пользовательской команды до обновления приложения.](https://we0-cms.oss-cn-beijing.aliyuncs.com/cms-assets/image/2026/07/c7e4e5a5-3b69-4999-be13-41aa3f213186-be0c3bc3-5210-4e7e-971e-c9b0e2d35daf.png)

Упрощённый поток выглядит следующим образом:

1. Инструмент объявляет ресурс пользовательского интерфейса.
2. Модель вызывает этот инструмент.
3. Хост загружает интерфейс в песочнице.
4. Данные инструмента передаются в интерфейс.
5. Пользователь взаимодействует с приложением.
6. Приложение может запрашивать дополнительные вызовы инструментов через хост.
7. Хост сохраняет контроль разрешений и аудита над этими операциями.

MCP Apps поддерживается несколькими совместимыми хостами, включая Claude и другие продукты для разработки с поддержкой MCP.

Базовая установка MCP Apps

Официальный пакет расширения можно установить следующей командой:

npm install -S @modelcontextprotocol/ext-apps

Официальный репозиторий с примерами кода можно запустить локально:

git clone https://github.com/modelcontextprotocol/ext-apps.git
cd ext-apps
npm install
npm start

Эти команды взяты из официальной документации MCP Apps и могут меняться по мере развития расширения.

Tasks: длительные операции, не блокирующие соединение

Инструменты агентов всё чаще запускают работу, которую невозможно выполнить в рамках одного обычного HTTP-запроса.

Примеры включают CI/CD-конвейеры, крупные задачи обработки данных, облачные развёртывания, длительные исследовательские задачи, рендеринг видео и процессы с участием человека для утверждения.

Расширение MCP Tasks позволяет серверу возвращать постоянный дескриптор задачи вместо блокировки ожидания завершения операции.

Официально определённые методы расширения включают:

tasks/get
tasks/update
tasks/cancel

Задача может переходить между следующими состояниями:

working
input_required
completed
cancelled
failed

Клиент может опрашивать tasks/get.

Если серверу требуется ввод пользователя, задача может перейти в состояние input_required.

Клиент может отправить данные через tasks/update.

Такая конструкция корректно работает даже при разрыве соединения и не требует постоянного поддерживаемого соединения.

Важное замечание о совместимости

Возможность задач существовала как экспериментальная функция в базовой спецификации от 2025-11-25.

Новое расширение Tasks — это не просто переименованная копия старого API.

Официальная документация SDK предупреждает, что более новое расширение Tasks не совместимо с ранними экспериментальными реализациями на уровне сетевого протокола.

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

Корпоративная управляемая авторизация

Корпоративные развёртывания сталкиваются с проблемами авторизации, отличными от интеграций для потребительского уровня.

В компании может быть тысячи сотрудников и десятки одобренных MCP-серверов.

И она не хочет, чтобы каждый сотрудник независимо авторизовывал каждый коннектор.

Расширение корпоративной управляемой авторизации позволяет организациям централизованно управлять контролем доступа через поставщика удостоверений.

Поддерживаемые корпоративные режимы IdP могут включать такие продукты, как Microsoft Entra ID, Okta и корпоративные системы единого входа (SSO).

Организации могут решать, какие сотрудники имеют доступ к каким MCP-серверам и когда доступ должен быть отозван.

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

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

И клиент, и корпоративная инфраструктура удостоверений должны поддерживать это расширение.

Механизмы авторизации получают более широкое усиление защиты

Базовая авторизация также получила ряд улучшений безопасности.

Проверка издателя RFC 9207

Ответ авторизации может содержать параметр издателя iss.

Клиент проверяет издателя перед обменом кода авторизации.

Это помогает защититься от атак подмены сервера авторизации.

Учётные данные клиента привязаны к его издателю

Зарегистрированные учётные данные клиента не должны повторно использоваться между несвязанными серверами авторизации.

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

Улучшенная регистрация для десктопных приложений и CLI

Данная редакция уточняет поведение поля application_type при динамической регистрации клиентов.

Это помогает избежать ситуаций, когда сервер авторизации воспринимает нативное CLI- или десктопное приложение как веб-клиента и отклоняет локальные URI перенаправления.

CIMD — новые рекомендации по регистрации клиентов

Проект авторизации MCP продвигается в направлении документов метаданных ID клиента (Client ID Metadata Documents, сокращённо CIMD) для новых реализаций, сохраняя при необходимости совместимость с DCR.

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

Полная поддержка JSON Schema 2020-12 для инструментов

Схемы инструментов также стали более выразительными.

inputSchema и outputSchema поддерживают все возможности JSON Schema 2020-12.

Входные схемы могут использовать:

oneOf
anyOf
allOf
$ref
$defs
условные операторы

Выходные схемы больше не ограничены единственной узкой формой объекта.

structuredContent может представлять любое значение JSON, поддерживаемое схемой.

Это позволяет инструментам MCP точнее описывать API с объединёнными типами, условными полями, вложенными переиспользуемыми определениями, множественными формами вывода, массивами или скалярными результатами.

Roots, Sampling и Logging объявлены устаревшими

Три более старых ключевых возможности официально объявлены устаревшими:

Объявление устаревшим не означает немедленное удаление.

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

Текущие SDK могут продолжать поддерживать эти возможности для обеспечения совместимости.

Официальная политика устаревания меняет риски обновления MCP

Редизайн без сохранения состояния включает критические изменения.

Разработчики заявили, что не хотят, чтобы такой уровень нарушений стал нормой.

Новый жизненный цикл функций определяет следующие этапы:

Активен (Active)
Устарел (Deprecated)
Удалён (Removed)

Устаревшие функции получают минимальный срок поддержки перед удалением.

Расширения также могут развиваться независимо от ядра.

Это обеспечивает более предсказуемое планирование миграции для команд.

MCP-туннели решают другую корпоративную задачу

Редакция протокола упрощает масштабирование публичных удалённых MCP-серверов.

Предприятия часто сталкиваются с противоположной проблемой: они вообще не хотят делать серверы публичными.

Функция MCP-туннели от Anthropic решает этот сценарий для управляемых агентов Claude и поддерживаемых рабочих процессов платформы Claude.

Лёгкий шлюз работает внутри корпоративной сети и устанавливает исходящее соединение.

Anthropic описывает эту модель так:

• Нет публичных MCP-эндпоинтов.
• Нет правил входящего брандмауэра.
• Не требуется публичный IP-адрес.
• Сквозное шифрование трафика.

Внутренние базы данных, ERP-системы, частные API, базы знаний и системы тикетов могут оставаться внутри периметра корпоративной сети.

MCP-туннели остаются функцией продукта Claude, а не требованием основного протокола MCP.

В настоящее время Anthropic описывает их как исследовательский предпросмотр.

Приложения MCP и туннели не следует путать

Обе функции улучшают MCP в производственной среде, но решают разные задачи.

политика доступа |
| MCP-туннели | Доступ к частным MCP-серверам без публичного раскрытия |
| Ядро MCP без состояния | Масштабируемый транспорт протокола |
| MRTR | Ввод от клиента во время вызова без длительной сессии протокола |

Серверы могут использовать одно, несколько или все эти функции.

Что нужно изменить разработчикам существующих MCP-серверов?

Если сервер уже работает со старыми MCP-клиентами, разработчикам не нужно немедленно переписывать всё.

Им следует выполнить структурированную миграцию.

Шаг 1: инвентаризация скрытых зависимостей от сессий

Найдите код, который зависит от:

• Mcp-Session-Id
• Внутрипроцессных словарей по сессиям
• Липкой маршрутизации
• Локального состояния клиента, связанного с соединением
• Хранилища возможностей, доступного только при инициализации
• Привязки к конкретному экземпляру сервера

Определите, является ли каждая зависимость состоянием протокола, состоянием приложения, состоянием аутентификации или временным состоянием выполнения.

Перенесите состояние приложения в явные дескрипторы или соответствующее постоянное хранилище.

Шаг 2: тестирование обработки запросов без состояния

Используйте версии SDK, поддерживающие ревизию 2026-07-28.

Затем протестируйте с несколькими экземплярами сервера.

Полезная тестовая конфигурация:

Клиент
  ↓
Балансировщик нагрузки с опросом
  ↓
Сервер A / Сервер B / Сервер C

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

Шаг 3: добавление явных дескрипторов состояния

Для рабочих процессов, требующих состояния, возвращайте стабильный идентификатор:

{
  "job_id": "job_7f18c9"
}

Требуйте, чтобы последующие вызовы включали этот идентификатор:

{
  "job_id": "job_7f18c9",
  "action": "continue"
}

Проверяйте каждый дескриптор на стороне сервера.

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

Шаг 4: обновление правил шлюза

При использовании Streamable HTTP используйте следующие заголовки:

Mcp-Method
Mcp-Name

Добавьте маршрутизацию, ограничение скорости, метрики, политики WAF и журналы доступа.

Шаг 5: добавление поддержки кэширования

Для соответствующих ответов на список и чтение соблюдайте или генерируйте:

ttlMs
cacheScope

Не передавайте конфиденциальное кэшированное содержимое, относящееся к данным конкретного пользователя, между пользователями.

Шаг 6: миграция старых задач

Если приложение использует экспериментальный Tasks API версии 2025-11-25, обновите его до расширенного жизненного цикла.

Протестируйте:

tasks/get
tasks/update
tasks/cancel

а также состояние input_required.

Шаг 7: проверка устаревших возможностей

Найдите Roots, Sampling и MCP Logging.

Спланируйте миграцию на явные параметры инструментов или URI ресурсов, прямые вызовы моделей провайдера и stderr или OpenTelemetry.

Шаг 8: повторное тестирование авторизации

Проверьте проверку эмитента, URI перенаправления, регистрацию клиентов, токены обновления, обработку областей действия и совместимость с провайдерами удостоверений.

Корпоративные развёртывания должны оценить применимость EMA.

Шаг 9: тестирование старых клиентов

Обратная совместимость — это проблема экосистемы, а не только сервера.

Ведите тестовую матрицу:

Не предполагайте молча, что каждый

клиент обновляется одновременно.

Шаг 10: добавление наблюдаемости перед производственной эксплуатацией

Как минимум необходимо измерять:

• Количество запросов.
• Имена инструментов.
• Задержку.
• Долю ошибок.
• Продолжительность задач.
• Частоту запросов ввода.
• Долю попаданий в кэш.
• Количество сбоев аутентификации.
• Задержку нижестоящих API.
• Идентификаторы трассировки.

Системы без состояния легче масштабировать, но распределённые системы по-прежнему требуют хорошей наблюдаемости.

Пример: сравнение до и после миграции

До миграции

Сервер хранит объекты отчётов в памяти:

sessions[session_id]["report"] = report

Следующий вызов инструмента ожидает попадания в тот же процесс.

После миграции

Сервер хранит постоянное состояние:

report_id = save_report(report)
return {"report_id": report_id}

Следующий инструмент получает:

{
  "report_id": "report_123"
}

Любой экземпляр сервера может загрузить этот отчёт.

Ключевое изменение происходит на уровне архитектуры:

Скрытое состояние транспортной сессии
→ Явное состояние приложения

Означает ли MCP без состояния более низкие затраты?

Возможно, но это не происходит автоматически.

Развёртывание без состояния может снизить сложность инфраструктуры:

• Не требуется общее хранилище сессий MCP.
• Меньше потребностей в липкой маршрутизации.
• Проще автоматическое масштабирование.
• Проще бессерверное развёртывание.
• Упрощённый переход на другой ресурс при сбое.

Кэширование также может уменьшить количество повторных вызовов метаданных.

Однако состояние приложения по-прежнему имеет стоимость.

Если рабочие процессы требуют постоянного состояния, разработчикам могут по-прежнему понадобиться Redis, SQL-базы данных, объектное хранилище, очереди задач или механизмы рабочих процессов.

Новый дизайн позволяет разработчикам выбирать архитектуру хранения, а не быть вынужденными использовать одну, предписанную протокольной сессией.

Становится ли MCP «HTTP в мире ИИ»?

В исходной статье использовалась эта аналогия.

Эта аналогия полезна, но её не следует понимать буквально.

HTTP — это фундаментальный стандарт веб-передачи данных, используемый практически во всех интернет-системах.

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

Что передаёт эта аналогия — так это направление развития:

• Единый стандартный интерфейс.
• Множество независимых серверов.
• Множество совместимых клиентов.
• Общие соглашения.
• Инфраструктура, способная универсально маршрутизировать и наблюдать за запросами.

Редизайн 2026-07-28 усиливает эту аналогию, поскольку трафик MCP теперь более естественно вписывается в традиционную инфраструктуру HTTP без сохранения состояния.

Вопрос о том, достигнет ли MCP уровня распространённости, сопоставимого с HTTP, остаётся открытым.

Экосистема шире, чем Claude

MCP зародился в Anthropic, но теперь управляется как более широкий проект с открытым исходным кодом.

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

Например, приложения MCP разрабатываются совместно с участниками сообщества MCP, а также с участниками из Anthropic, OpenAI и MCP-UI.

Это важно, потому что ценность протокола возрастает, когда и клиенты, и серверы могут реализовывать его без зависимости от одного поставщика.

Текущая ситуация с SDK

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

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

Июнь 2026 года

В анонсе кандидата на выпуск особо подчёркивалась поддержка бета-версий четырёх SDK первого уровня:

• TypeScript.
• Python.
• Go.
• C#.

К концу июля текущая документация SDK уже включает поведение 2026-07-28.

Поскольку внедрение SDK происходит независимо, всегда обращайтесь к примечаниям к выпуску для вашей конкретной версии языка.

Более безопасная стратегия миграции

Для производственных систем избегайте миграции «в один день».

Более безопасный процесс:

1. Обновите среду разработки.
2. Запустите тесты на согласованность.
3. Протестируйте клиент 2026-07-28.
4. Протестируйте клиенты предыдущих версий.
5. Включите развёртывание без состояния в предрелизной среде.
6. Добавьте несколько экземпляров сервера.
7. Обеспечьте распределение запросов между экземплярами.
8. Проверьте аутентификацию.
9. Проверьте длительные задачи.
10. Проверьте дескрипторы состояния приложения.
11. Отслеживайте задержки и ошибки.
12. Запускайте поэтапно.

Это особенно важно, поскольку новая редакция намеренно изменяет базовое поведение жизненного цикла.

Чего не следует предполагать

Не предполагайте, что каждый сервер автоматически становится бессерверным

Протокол более естественно поддерживает бессерверные развёртывания.

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

Не предполагайте, что всё состояние исчезнет

Только состояние сессии на уровне протокола удаляется из новой сетевой модели.

Состояние приложения остаётся задачей самого приложения.

Не предполагайте, что приложения MCP будут работать в каждом клиенте

Расширения согласовываются, и поддержка хоста варьируется.

Не предполагайте, что задачи обратно совместимы

Текущее расширение Tasks отличается от более ранних экспериментальных реализаций.

Не предполагайте, что устаревание означает неработоспособность

Roots, Sampling и Logging остаются доступными в период устаревания.

Не предполагайте, что все клиенты уже поддерживают 2026-07-28

Прогресс внедрения в SDK и продуктах различается.

Не предполагайте, что «открытый протокол» означает «не требуется безопасность»

MCP может выполнять мощные инструменты.

Авторизация, согласие пользователя, песочницы, проектирование инструментов, управление секретами и аудит остаются критически важными.

Часто задаваемые вопросы

Что такое MCP 2026-07-28?

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

Полностью ли MCP теперь не имеет состояния?

Уровень протокола 2026-07-28 спроектирован так, чтобы быть без сохранения состояния. Приложения всё ещё могут сохранять состояние через явные дескрипторы, базы данных, системы рабочих процессов или другие постоянные хранилища.

Что случилось с Mcp-Session-Id?

Сетевой формат 2026-07-28 удаляет механизм Mcp-Session-Id на уровне протокола. Текущие SDK всё ещё могут поддерживать поведение на основе сессии для обратной совместимости при согласовании предыдущих редакций протокола.

Могу ли я развернуть сервер MCP на AWS Lambda или Cloudflare Workers?

Протокол без состояния упрощает бессерверные и краевые развёртывания, поскольку запросы больше не требуют привязки к сессии на уровне протокола. Ваш сервер всё ещё должен соответствовать ограничениям выполнения, сети, хранения и длительности времени выполнения.

Что такое приложения MCP?

Приложение MCP — это официальное расширение,

которое позволяет инструментам возвращать интерактивные интерфейсы, такие как панели мониторинга, формы, графики и другие HTML-интерфейсы, в совместимых хостах MCP. Интерфейс работает в песочнице iframe и взаимодействует через хост MCP.

Что такое задачи MCP?

Функция Tasks позволяет серверам возвращать постоянные асинхронные дескрипторы задач для длительных работ. Клиенты могут опрашивать статус через tasks/get, предоставлять необходимые входные данные через tasks/update или отменять операции через tasks/cancel.

Что такое корпоративная управляемая авторизация?

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

Должен ли я немедленно мигрировать со старой версии MCP?

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

Связанные инструменты

• Model Context Protocol: официальная документация по спецификации, архитектуре, SDK, расширениям и руководствам для разработчиков MCP.
• MCP TypeScript SDK: официальная реализация TypeScript для клиентов и серверов MCP.
• MCP Python SDK: официальный Python SDK и примеры для разработки MCP.
• MCP Go SDK: официальная реализация Go, в настоящее время поддерживает путь протокола без состояния.
• MCP C# SDK: официальный .NET SDK с подробной документацией по режиму без состояния, задачам и совместимости.
• MCP Apps: официальная документация по расширению и SDK для интерактивных интерфейсов в хостах MCP.
• MCP Tasks: официальная документация по длительным асинхронным операциям MCP.
• [MCP Registry](https://registry.modelcontextprotocol.

io/): официальная инфраструктура реестра для обнаружения опубликованных MCP-серверов.

Связанные ссылки

• Обзор кандидата в релиз MCP от 2026-07-28: пояснения официальных сопровождающих по бессерверной реструктуризации, расширениям, изменениям аутентификации, кэшированию и удалённому содержимому.
• Релизы репозитория спецификации MCP: официальная история релизов протокольных редакций на GitHub.
• Дорожная карта MCP на 2026 год: официальная дорожная карта, охватывающая масштабируемость транспорта, коммуникацию агентов, управление и корпоративную готовность.
• Официальная документация MCP Apps: спецификации, SDK, примеры и руководства для разработчиков интерактивных MCP-приложений.
• Расширение MCP Tasks:

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

• Корпоративная управляемая авторизация: официальная документация по доступу MCP на основе централизованного поставщика удостоверений.
• Anthropic MCP-туннели: документация Anthropic о подключении MCP к частным сетям в управляемых агентах Claude.

Резюме

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

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

Миграция — это не просто «удалить идентификатор сессии». Командам необходимо выявить скрытые зависимости от состояния, перенести состояние приложения в явные обработчики или постоянное хранилище, протестировать MRTR и задачи, обновить авторизацию, сохранить совместимость со старыми клиентами и добавить надлежащую наблюдаемость.

Самое важное изменение — на уровне архитектуры: MCP переходит от соединённой модели интеграции агентов к бессерверному, масштабируемому протоколу, который более естественно вписывается в современную облачную инфраструктуру.