Нова специфікація MCP від 2026-07-28 відмовляється від усіх вимог до стану сесії, дозволяючи кожному запиту нести всі необхідні дані. Перехід до протоколу без збереження стану (stateless) означає, що розробники можуть запускати окремий екземпляр для кожного виклику, працювати на serverless-функціях або edge-вузлах і відмовитися від застарілої логіки «sticky-routing» та спільних сховищ, які раніше створювали проблеми під час розгортання.

Від handshake до самодостатніх викликів

До цього часу протокол Model Context Protocol (MCP) вимагав виконання handshake для видачі ID сесії. Сервери мали зберігати цей ID протягом усього часу з'єднання, що на практиці означало необхідність підтримувати процеси активними, реплікувати стан у кластері Redis або налаштовувати балансувальники навантаження для «sticky»-маршрутизації. Результатом був складний, ресурсомісткий стек, який ускладнював масштабування та робив горизонтальне зростання дорогим.

Нова специфікація робить кожен запит самодостатнім. Кожен payload містить версію протоколу та ідентифікатор викликаючої сторони, тому сервер може розглядати запит як одноразову транзакцію. Жодних сховищ сесій, жодних довготривалих процесів, жодних спеціальних правил маршрутизації.

Чому stateless важливий для розгортання

  • Готовність до serverless та edge-обчислень – запит містить усе необхідне, тому функція може запуститися, відповісти та завершити роботу без попереднього підготовки стану. Провайдери, які тарифікують за кожен виклик, стають придатними для робочих навантажень MCP.
  • Спрощене балансування навантаження – стандартні балансувальники L4/L7 можуть рівномірно розподіляти трафік; немає потреби прив'язувати клієнта до конкретного бекенду.
  • Зменшення операційних витрат – команди можуть відмовитися від кластерів Redis або власного коду для реплікації сесій, що знижує як витрати, так і ризик виникнення помилок.

Для організацій, які вже використовують MCP за балансувальником навантаження, ця зміна усуває потребу в «sticky»-правилах, які часто призводять до нерівномірного розподілу трафіку. Економія є особливо відчутною для високонавантажених сервісів, що обробляють мільйони викликів на день.

Покращення продуктивності та безпеки

Специфікація додає конкретні вдосконалення, які посилюють протокол поза межами його stateless-природи:

  • Кешування на основі TTL – списки інструментів (tools) та підказок (prompts) тепер містять поле time-to-live, що дозволяє клієнтам кешувати результати локально та уникати зайвих циклів запит-відповідь.
  • Маршрутизація на основі заголовків – нові HTTP-заголовки надають інформацію про маршрутизацію на ранніх етапах, тому шлюзи можуть перенаправляти трафік без парсингу всього JSON-тіла, скорочуючи затримку на мілісекунди.
  • Посилення OAuth/OIDC – токени ідентифікації проходять суворішу перевірку OAuth та OpenID Connect, що зменшує ризик атак повторного відтворення (replay attacks) та крадіжки токенів.
  • Формальна структура розширень – завдання (Tasks) та додатки (Apps) тепер належать до визначеної моделі розширень, що полегшить випуск нових функцій для підтримувачів SDK.

Вплив на розробників

Екосистема SDK вже відображає ці зміни: бібліотеки для TypeScript, Python, Go та C# уже видають запити у новому форматі. Сукупна кількість завантажень цих SDK наближається до пів мільярда на місяць, що в чотири рази більше, ніж на початку року, — це свідчить про широке впровадження MCP.

Розробникам необхідно адаптувати будь-який код, який передбачав постійну сесію. Зазвичай це означає перенесення даних, специфічних для сесії, у payload запиту або у зовнішнє сховище, до якого звертаються під час кожного виклику. Період міграції становить дванадцять місяців, що дає командам час на рефакторинг, тестування та впровадження нового патерну.

Контраргумент: складність міграції

Stateless-підхід не є безкоштовним бонусом. Додатки, які раніше покладалися на стан на стороні сервера для таких речей, як прогресивна історія діалогу, тепер мають керувати цим станом на стороні клієнта або через окремий рівень збереження даних.

На що звернути увагу

  • Метрики впровадження – стежте за темпами оновлення версій SDK; уповільнення може свідчити про труднощі під час міграції.
  • Підтримка edge-платформ – у міру того, як більше провайдерів оголошуватимуть про підтримку середовищ, сумісних з MCP, реальна економічна вигода від serverless-рішень стане зрозумілішою.
  • Звіти про інциденти безпеки – посилений потік OAuth/OIDC має зменшити кількість атак на ідентифікацію, але будь-яке порушення стане перевіркою нових засобів захисту.

Висновок: Роблячи MCP без збереження стану, специфікація узгоджує протокол із сучасними cloud-native патернами, зрізаючи операційне навантаження на управління сесіями та відкриваючи двері для дешевших та більш еластичних моделей розгортання. Компромісом є короткий період рефакторингу коду та збільшення обсягу даних у запитах, але довгострокова вигода — це протокол, який масштабується так само легко, як і інфраструктура, на якій він працює.