Безстановий MCP у специфікації від 2026-07-28: Які зміни для інфраструктури агентів.
Нова версія MCP скасовує сесії, додає заголовки маршрутизації, функцію input_required для подвійних запитів та посилені механізми OAuth. Як це впливає на шлюзи, масштабування та безпеку.
Джерела: MCP Goes Stateless: Why the New Spec Changes Agent Infrastructure
Протокол Model Context швидко розвивався. Спочатку обговорення були спрямовані на поєднання застосунків ШІ з інструментами та даними. З того часу він пройшов етапи автентифікації OAuth, використання віддалених серверів, масштабних змін протоколу, створення реєстрів, документів метаданих Client ID та систем автентифікації для корпорацій. Специфікація 2026-07-28 змінює щось ще більш фундаментальне: сам протокол стає безстановим.
Ініціалізаційний процес взаємодії зник, як і сеанси на рівні протоколу. Клієнту більше не потрібно залишатися прив’язаним до конкретної інстанції сервера, яка прийняла його з’єднання. Кожен запит містить достатньо інформації, щоб функціонувати самостійно, і будь-яка сумісна інстанція може на нього відповісти.
Це може здатися лише невеликою корекцією для транспортування даних, але архітектурний вплив є значно глибшим. Віддалені сервери можуть функціонувати як будь-який хмарний HTTP-сервіс, розташований за звичайними балансувальниками навантаження, API-шлюзами, системами захисту від атак, платформами без серверів та масштабованими флотами контейнерів, без спеціального обладнання для керування сеансами, притаманного MCP.
Ця версія також пропонує ще багато чого: стандартні заголовки маршрутизації, результати пошуку, які можна кешувати, багатократні запити, суворіші правила авторизації, конвенції OpenTelemetry та формальну модель розширень. MCP виглядає менш особливим як інфраструктура, що може бути одним із найочевидніших ознак зрілості. У наступному розглядаються зміни, чому відсутність стану є важливою у продакшн-середовищі та які наслідки це має для безпеки, шлюзів та загального робочого процесу агентів.
Чому сеанси завдають шкоди
MCP почався з простої проблеми: створити для штучних інтелектуальних додатків стандартний спосіб роботи з інструментами, ресурсами та зовнішніми системами. Для локальних клієнтів та серверів це працювало природно. Однак віддалений MCP змінив ситуацію. Коли сервери почали працювати в контейнерах, кластерах Kubernetes, платформах без серверів та хмарній інфраструктурі, сеанси на рівні протоколу спричиняли звичні проблеми розподілених систем.
Клієнт ініціював процедуру ініціалізації, сервер міг надати Mcp-Session-Id, і кожен наступний запит мусив зберігати цю взаємозв’язок. У масштабах це могло означати:
- функцію «залипання» балансувальника навантаження
- спільні сховища сеансів
- механізм аварійного переходу, який розуміє сеанси
- довготривалі з’єднання
- додаткове керування життєвим циклом
Жоден з цих аспектів не є некерованим, адже дистрибуовані системи вже десятиліттями справляються з ними. Варто запитати, чи взагалі MCP мусив створювати ці проблеми, і з датою 2026-07-28 відповідь все більше є «ні».
Нова специфікація повністю відміняє процедури initialize та notifications/initialized, сеанси на рівні протоколу та Mcp-Session-Id. Запити містять усе необхідне для їх обробки. Концептуально архітектура змінюється наступним чином:
Будь-яка сумісна інстанція може обробити наступний запит. Це значно краще підходить для Kubernetes, контейнерів, безсерверних функцій, автомасштабування, інфраструктури на периферії та звичайного раунд-робін балансування навантаження.
Це вже відбувається на практиці. Cloudflare перевела свої сервери MCP на цю модель та створює новий безстановий сервер для кожного запиту. Google назвала закінчення використання «липких сеансів» та спільної інфраструктури сеансів значним плюсом для масштабування. AWS AgentCore Gateway тепер підтримує новий протокол поряд із попередніми версіями MCP. Отже, це є частиною сучасної моделі розгортання, а не теоретичною архітектурою.
Стан не зникає
Тут важливо розрізняти деталі. Видалення сеансів MCP не заважає додаткам зберігати стан. Це означає, що стан додатку не повинен ховатися всередині механізмів передачі даних. Візьмемо агента, який створює робоче простір:
create_workspace()
|
v
workspace_id = ws_123
У наступному запиті можна явно вказати результат:
update_workspace( workspace_id = "ws_123" )
Перше запитання може потрапити на сервер A, а друге — на сервер C. Додаток все ще має стан, але тепер у нього є явний ідентифікатор, і він не залежить від невидимого зв’язку між клієнтом та процесом на сервері.
Стан протоколу та стан додатку — це різні речі. Явний стан додатку легше зберігати, аудитувати, авторизувати, призупиняти та аналізувати, а системи з агентами отримують ще одну перевагу: агент може безпосередньо працювати з ідентифікатором та передавати його між інструментами та кроками робочого процесу.
Заголовки маршрутизації
Відсутність стану вирішує одну проблему інфраструктури, а інша зміна може бути такою ж важливою для корпоративних розгортань. MCP тепер стандартизує HTTP-заголовки, які описують поточну операцію. Наприклад:
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: delete_workspace
Раніше посередник, можливо, мусив розпакувати вміст JSON-RPC, щоб дізнатися, чого хоче агент. Тепер ця інформація видима на рівні HTTP, що відкриває цікаві можливості.
У командах з безпеки є причини для занепокоєння. Агенти отримують доступ до потужніших інструментів, і шлюз стає природним місцем для впровадження правил між наміром та зовнішнім ефектом. Усе це не усуває потреби у механізмах керування агентами чи на рівні додатків. Це, можна сказати, чіткіше розділяє протокол, шлюз, механізми керування та системи, що знаходяться за ними.
Запит на вхідні дані без сеансу
Перехід до безстанового режиму створює очевидну проблему. Що робити, якщо серверу потрібна додаткова інформація, перш ніж він зможе завершити операцію? Уявіть собі руйнівний запит:
delete_environment(“production”)
Сервер може спочатку потребувати підтвердження. Підтримка двосторонньої сесії відкритою лише для цієї операції знищить більшу частину переваг безстановості.
Відповідь специфікації — це багатократні запити з поверненням (MRTR). Сесія більше не підтримує активність взаємодії. Натомість сервер повертає результат input_required, у якому вказується те, що йому потрібно. Операція відбувається приблизно так:
Людське схвалення, додаткова автентифікація, відсутні параметри, перевірки політик та подібні інтерактивні процеси можуть бути включені до моделі запитів без стану. Це особливо актуально для дій агентів із високим ризиком. Можливість виклику інструменту не надає агенту необмежених повноважень, а чутливі операції можуть передбачати точку прийняття рішення перед їх виконанням.
Кешування та спостережуваність
Деякі менш помітні зміни можуть мати значення у масштабному використанні. До них належать операції зі списку:
tools/list
prompts/list
resources/list
resources/read
Тепер можна отримувати деталі кешу, такі як ttlMs та cacheScope, а списки інструментів мають повертатися у визначеному порядку. Це здається звичайною оптимізацією HTTP, проте від цього користуються також системи ШІ: стабільні визначення інструментів можуть покращити кешування запитів на рівні LLM, тоді як інструменти, які надходять у змінному порядку або потребують повторного пошуку, перетворюють незначну особливість протоколу на додаткову затримку та витрати на токени.
У специфікації також описано, як передавати контекст OpenTelemetry із знайомими полями:
traceparent
tracestate
baggage
Це ще один випадок, коли MCP рухається у напрямку інфраструктури, яку вже знають команди DevOps та платформ. Метою не повинен бути окремий стек для моніторингу, створений лише для протоколів ШІ. Натомість слід зробити діяльність агентів видимою в системах, якими вже керують організації.
Ідентичність стає ще важливішою
Безстанові запити не знижують значення ідентичності. Вони роблять її важливою для правильної обробки кожного окремого запиту. Нова специфікація продовжує рух MCP у напрямку усталених практик OAuth та OpenID Connect. Це включає перевірку емітента з метою протидії атакам на плутанину з серверами авторизації, а також більш суворе прив’язування облікових даних.
Ці специфікації також офіційно закріплюють тенденцію, яка розвивалася раніше: динамічна реєстрація клієнтів відміняється на користь документів метаданих Client ID. CIMD поступово стає кращим варіантом, тоді як DCR залишається через сумісність, і тепер у тексті це чітко зазначено. Це ще один сигнал зрілості, адже MCP уникає приватної системи ідентифікації та продовжує наближатися до стандартів, які вже використовуються в Інтернеті. Це особливо важливо для розгортання корпоративних агентів, оскільки MCP розвивається від кількох інтеграцій, схвалених користувачем, до великої кількості агентів, клієнтів, шлюзів та інструментів.
Реєстрація — це лише частина процесу авторизації. У масштабах корпорації складнішим питанням є визначення того, які агенти можуть отримати доступ до яких функцій: сотні агентів, що викликають сотні сервісів, створюють проблеми з управлінням у форматі N×M. Два механізми — Enterprise-Managed Authorization (EMA) та Identity Assertion Authorization Grants (ID-JAG) — спрямовують цей процес на централізовану корпоративну політику. Постачальник ідентичностей корпорації допомагає вирішити, чи отримає агент доступ, тому окремі сервери MCP не повинні запитувати у користувачів згоду поодинці.
Stateless MCP не замінює цю модель. Він посилює розділення елементів: стан транспорту, ідентичність клієнта, політика авторизації та стан додатку є окремими архітектурними аспектами.
Що залишається поза основою
Важливою частиною цього оновлення є те, що MCP видаляє або переміщує. Функції Roots, Sampling та Logging залишають основну модель, а старий механізм передачі даних HTTP+SSE замінюється на Streamable HTTP. Одночасно з’являється формальна система розширень, що дозволяє таким функціям, як Tasks, розвиватися у вигляді розширень без збільшення обсягу основного протоколу. Це створює більш чіткі межі:
MCP не повинен ставати повним середовищем виконання агента. Середовище виконання все ще контролюється загальним інструментарієм, а MCP забезпечує стандартний спосіб взаємодії цього середовища з зовнішніми функціями. Зрілий протокол визначається не лише тим, що він додає, а й тим, що він вирішує залишити поза собою.
Відсутність стану не означає довіри
Сервер MCP без стану легше масштабується, хоча відсутність стану не означає довіри: кожен запит все одно перетинає межу безпеки. Введення шкідливих команд чи заражений контекст все ще можуть впливати на роботу агентів. Інструменти все ще можуть мати надмірні привілеї, облікові дані можуть бути неправильно налаштовані, а компрометація ланцюга постачання все ще може призвести до появи зловмисних серверів чи інструментів.
Змінюється те, що архітектура стає простішою. Замість того, щоб розглядати сеанси передачі даних як частину моделі безпеки, заходи захисту можуть бути спрямовані на перевірку того, хто саме здійснює запит, яку політику дотримується шлюз та які права надає кожен інструмент. Необхідно додати чітке авторизування та ідентифікатори ресурсів, потім перевіряти вхідні дані, вимагати підтвердження людиною критичних дій, записувати телеметрию для аудиту та також контролювати роботу агента.
Один важливий момент: метадані клієнта не є автоматично його ідентичністю. Те, що клієнт стверджує про себе у метаданах запиту, не може вважатися еквівалентним криптографічно підтвердженій ідентичності через OAuth чи інший надійний механізм. Простіша маршрутизація та перевірка трафіку MCP дозволяють командам з безпеки посилити контроль за протоколом, не плутаючи метадані з ознакою довіри.
Більш широка картина
Основна зміна, яка відбудеться 2026-07-28, є простою: MCP є безстановим. Справжня значимість полягає у тому, що це дозволяє. Запити MCP поводяться більше як звичайні HTTP-завдання. Сервери масштабуються горизонтально без залежності від сеансів. Гейтвеї розуміють операції MCP за допомогою стандартних заголовків. Процес відкриття ресурсів може бути кешованим. Інтерактивні робочі процеси продовжуються за допомогою багаторазових запитів. Авторизація поступово наближається до перевірених практик OAuth, для моніторингу може використовуватися OpenTelemetry, а розширення залишають простір для розвитку, не перетворюючи основу на повний середовище виконання агента.
Окремо кожен з цих елементів виглядає як покращення протоколу, а разом вони говорять про більше. MCP почався з вирішення проблеми з’єднаності. Віддалений MCP змусив екосистему звернутися до питань ідентифікації та авторизації. CIMD та корпоративна авторизація тепер спрямовані на управління, тоді як безстановий MCP стосується оперативності та масштабування. Протокол стає менш екзотичним та підходить для інфраструктури, будування, захист, моніторинг та експлуатація якої люди вже знають. Для чогось, що розвивається так швидко, перетворення на нудну інфраструктуру може бути саме тією метою.
Пов’язана література
- Практичні нотатки: „MCP: Протокол, який перетворює ШІ з чат-бота на агента ШІ“ — детальний огляд Практичних нотаток: „MCP: Протокол, який перетворює ШІ з чат-бота на агента ШІ“: контракти, перевірки та шаблони коду для команд, які розробляють системи MCP. — Operable walkthrough of Practical notes: “MCP: Protocol That Turns AI From a Chatbot Into an AI Agent”: contracts, checks, and drop-in code slots for teams shipping mcp systems.
- Створення локального дослідницького агента в LM Studio за допомогою чотирьох серверів MCP — Об’єднання серверів файлової системи, GitHub, SearXNG та Camofox MCP в одному чаті LM Studio, оптимізація схеми інструментів, додавання запиту щодо плану дослідження та перевірка функціоналу за допомогою демонстрації.