Если вы в Cursor или Claude Code подключали «MCP-сервер» (GitHub, браузер, docs, своя база) — вы уже пользуетесь MCP. Это общий язык: агент говорит «вызови tool», сервер отвечает результатом.
28 июля 2026 вышла новая версия этого языка — в названии дата: MCP 2026-07-28. Не «версия 3.0», а именно дата релиза. Так у MCP принято нумеровать спеки (как раньше 2024-11-05 и т.д.).
Коротко, зачем читать дальше: старый MCP держал длинную сессию «клиент ↔ сервер». Новый — ближе к обычному HTTP: спросил — ответил, без обязательной «памяти соединения». Так серверам проще масштабироваться и падать без драмы.
Сначала видео: как меняется схема
Ниже — короткая анимация: слева старый способ (сессия на всё), справа новый (каждый запрос независим).
Словарь на 30 секунд (без «воды»)
| Термин | Что это по-человечески |
|---|---|
| MCP | Стандарт «как агент ходит в tools» (Model Context Protocol) |
| MCP-сервер | Программа, которая отдаёт tools: поиск, API, файлы… |
| Клиент | Приложение с агентом: Cursor, Claude Desktop, ваш runtime |
| Stateful / сессия | Сервер помнит вас между запросами по «номеру разговора» |
| Stateless | Каждый запрос сам по себе — как обычный запрос к сайту |
| Handshake | Стартовый обмен «привет, вот кто я / вот что умею» |
| MRTR | Если tool mid-call не хватает данных — просит их и ждёт повторный вызов |
| Load balancer | Распределитель: запросы на разные копии сервера |
| Gateway | «Шлюз» перед серверами: роутинг, лимиты, доступ |
Как было: «одна длинная труба»
Раньше клиент и сервер сначала здоровались (initialize → initialized), получали номер сессии (заголовок вроде Mcp-Session-Id) и дальше жили «в одном разговоре». Удобно для прототипа. Плохо, когда серверов много:
- Запрос №2 должен попасть на тот же сервер, что и №1 — иначе «сессия не найдена»
- Нужна sticky-сессия у балансировщика или общее хранилище сессий
- Упал инстанс — оборвался контекст
- Serverless и auto-scale превращаются в головную боль
Отсюда и главный запрос сообщества: сделайте протокол проще и надёжнее для продакшена.
Как стало: «каждый звонок — отдельный»
В MCP 2026-07-28 убрали обязательный handshake и номер сессии. Каждый запрос несёт с собой:
- версию протокола (я говорю на MCP от 28.07.2026)
- кто клиент (имя/версия приложения)
- что клиент умеет — прямо в теле запроса (поле _meta)
- какой method и какой tool — ещё и в HTTP-заголовках, чтобы шлюз не лез в JSON
Хотите заранее узнать «что сервер умеет» — есть отдельный вызов server/discover («расскажи о себе»). Но он не обязателен: можно сразу звать tool.
Важно: «протокол без сессии» ≠ «приложение без памяти». Если tool'у нужно «продолжить с того же места», сервер возвращает id (handle), а модель в следующем вызове передаёт его аргументом. Память видна, а не спрятана в «магии соединения».
Если tool mid-call спрашивает пользователя (MRTR)
Иногда tool'у прямо во время работы нужно: «точно удалить?», «какой аккаунт?». Раньше сервер сам стучал клиенту по открытому двустороннему каналу — это требовало держать «трубу».
Сейчас — MRTR (Multi Round-Trip Request), по-русски: несколько кругов одного вызова.
- 1. Клиент: «tools/call — сделай X»
- 2. Сервер: «не могу до конца — нужно ещё вот это» (resultType: input_required)
- 3. Клиент спрашивает человека/агента и повторяет тот же call уже с ответами
Похоже на форму на сайте: отправил → «заполните поле» → отправил снова. Без вечного WebSocket «сервер постоянно орёт в клиента».
Заголовки Mcp-Method и Mcp-Name — зачем
Раньше, чтобы понять «это tools/call search», шлюзу часто приходилось разбирать JSON. Теперь method и имя tool обязаны быть в заголовках HTTP. Балансировщик, rate limit, WAF, биллинг — смотрят headers и не парсят body.
Для вас, если пишете MCP-сервер «для себя в Cursor» — почти не заметно. Если поднимаете общий MCP на несколько машин — заметно сильно.
Список tools можно кэшировать
Ответы «список tools / prompts / resources» теперь с подсказками ttlMs (сколько миллисекунд можно держать в кэше) и cacheScope. Плюс стабильный порядок списка.
Зачем обычному человеку: клиент не обязан каждый раз спрашивать «какие tools есть?». Для моделей, которые кэшируют system/prompt, стабильный каталог tools = меньше лишних пересчётов контекста.
Безопасность входа (OAuth) — короче
Авторизация — то, на чём чаще всего горят интеграции. В новой спеке:
- Клиент обязан проверять кто выдал код (issuer / iss) — чтобы не отдать код «чужому» auth-серверу
- Для CLI/desktop починили типичные ошибки redirect на localhost
- Старый способ «Dynamic Client Registration» (клиент сам регистрируется «на лету») помечают устаревшим — новый путь: Client ID Metadata Documents (документ о клиенте по URL)
- Пока старый способ ещё работает, но новые проекты лучше сразу на новый
Что устарело (но не «завтра отключат»)
Официально deprecated (не берите в новый код): Roots, Sampling, Logging, старый транспорт HTTP+SSE. Обещают минимум 12 месяцев поддержки. Планируйте спокойно, не паникуйте.
Tasks (долгие фоновые задачи) вынесли в расширение — не «ядро протокола навсегда», а отдельный модуль, который подключают, если нужен.
Было → стало (одной таблицей)
| Было | Стало |
|---|---|
| Обязательное «рукопожатие» + номер сессии | Запрос сам по себе; «расскажи о себе» — по желанию |
| Нужно клеить запросы к одному серверу | Можно слать на любую копию (round-robin) |
| Сервер mid-call сам пушит вопросы по stream | MRTR: «нужен input» → клиент повторяет call |
| Шлюз читает JSON, чтобы понять tool | Method и имя tool в HTTP-заголовках |
| Список tools каждый раз заново | Можно кэшировать (ttl + стабильный порядок) |
Кому это важно прямо сейчас
- Да, если вы пишете MCP-сервер в облаке, за nginx/балансером, на нескольких инстансах
- Да, если делаете gateway/платформу tools для команды
- Скорее нет срочки, если у вас один локальный MCP в Cursor/Claude на своей машине — обновите SDK, когда будете рядом, но «всё умерло» overnight не должно
- Да посмотреть, если пишете skills/tools и думаете, как хранить state: не в «магии сессии», а в явных id
Что сделать, если вы автор MCP-сервера
- Обновить SDK (TypeScript / Python / Go / C# уже под 2026-07-28; Rust — beta)
- Не полагаться на session id: state → id в ответе tool, модель передаёт его дальше
- На HTTP — отдавать/принимать заголовки method и name
- Elicitation mid-tool — через MRTR, не «вечный» server-push
- Новый код: не цепляться к Roots / Sampling / Logging
- Auth: проверить issuer; план ухода с DCR на CIMD
Вердикт
MCP 2026-07-28 — это не «ещё фичи ради пресс-релиза». Это сдвиг от чат-сессии к нормальному API tools, которое можно класть за балансировщик и не бояться. Для локального вайбкодинга — тихий апгрейд. Для production MCP — причина наконец-то упростить инфраструктуру.
Запомните одно: номер сессии убрали не «назло», а чтобы tools жили как обычные HTTP-сервисы. Память — в аргументах и id, не в «магии трубы».
Источник: анонс maintainers MCP от 28 июля 2026 (David Soria Parra, Den Delimarsky), спека 2026-07-28. Официальные SDK — TypeScript, Python, Go, C#.
Если поднимаете tools/MCP под продукт или агентный контур в команде — 15 минут разбора. Короткие новости в @codautomat.