Безстановий MCP: масштабування серверів без сеансів чи процедур взаємодії

Сервер протоколу Model Context Protocol, який бездоганно працює на одній машині, може почати виявляти проблеми як тільки ви запустите три його копії за допомогою балансувальника навантаження, оскільки кожна інстанція пам’ятає лише ті сеанси, які створила сама. Перехід протоколу до безстанової архітектури спрямований саме на вирішення цієї проблеми. У цій статті пояснюється, що змінюється після відсутності сеансів та процедури ініціалізації, як запити передають власний контекст, а також як багатокрокові взаємодії, маршрутизація на основі заголовків, списки для кешування та фонові завдання вписуються у нову модель, щоб ви могли оцінити їхній вплив на сервери та шлюзи, які ви використовуєте.

Примітка щодо таймінгу: описаний тут дизайн без стану належить до ревізії протоколу 2026 року. Такі деталі, як точні назви методів, назви заголовків та типи результатів, все ще можуть змінюватися, тому перевірте їх за поточною специфікацією MCP перед тим, як використовувати їх у коді. Якщо вам потрібно ознайомлення з основами того, як клієнти MCP виявляють та викликають інструменти, устаткування блогу з вступом до того, як Протокол контексту моделі дозволяє агентам виявляти та викликати інструменти, розглядає це питання.

Що означає тут „стан“

Система є становою, коли їй потрібно пам’ятати щось між запитами, щоб обробити наступний. Хорошим повсякденним прикладом є замовлення доставки їжі: воно проходить стадії прийняття, підготовки, виходу у дорогу та доставки, і сервіс мусить відстежувати, на якій стадії знаходиться кожне замовлення, щоб у будь-який момент можна було відповісти на запитання „Де моя їжа?“.

Ранні версії MCP працювали аналогічно на рівні з’єднання. Коли клієнт (додаток ШІ) вперше під’єднувався до сервера, обидві сторони виконували процедуру ініціалізації з’єднання. Потім сервер видавав ідентифікатор сеансу, наприклад abc123, і клієнт додавав його до кожного наступного запиту, щоб сервер міг пов’язати кожен виклик із тим, що відбувалося раніше під час розмови, включаючи можливості, які були узгоджені обома сторонами.

Чому сеанси руйнуються під час горизонтального масштабування

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

1. Клієнт користувача надсилає свій перший запит, наприклад, з проханням надати список інструментів. Балансувальник навантаження направляє його на Сервер 1, який створює сеанс abc123.
2. Той самий клієнт надсилає другий запит, наприклад, з проханням отримати інформацію про погоду. Цього разу балансувальник навантаження обирає Сервер 2.
3. Сервер 2 ніколи не чув про abc123. У нього немає жодної інформації про стан пам’яті Сервера 1, тому запит провалюється.

У системах із станом існують два стандартні способи вирішення проблем. Функція „sticky sessions“ прив’язує кожного клієнта до однієї інстанції, що погіршує розподіл навантаження та ускладнює процес переходу на резервний сервер. Іншим варіантом є використання спільного сховища, такого як Redis, де зберігаються дані сесій, які може читати кожна інстанція. Цей підхід ефективний, але вимагає додаткової інфраструктури для її функціонування, захисту та підтримки доступності, а також мережевого пошуку при кожному запиті — усе це лише для збереження обліку протоколу.

Безстановий модель

У ревізії 2026 року обрано інший підхід: MCP перетворюється на безстановий протокол запит-відповідь, і функція сесій видаляється. Кожен запит є автономним та не залежить від того, що сервер пам’ятає з попереднього запиту. Оскільки на сервері немає окремої пам’яті для кожного клієнта, будь-яка інстанція може відповісти на будь-який запит, а масштабування полягає у додаванні інстанцій позаду звичайного балансувальника навантаження.

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

Як запит несе власний контекст

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

Об’єкт _meta

У вантажі запиту може бути необов’язковий об’єкт _meta для цих метаданих. Він може містити:

• Версію протоколу, щоб сервер знав, як інтерпретувати повідомлення.

Ідентичність клієнта, така як назва та версія додатку, наприклад MyAIApp v1.0.

Функціональні можливості клієнта, щоб сервер знав, які функції він може використовувати у своїй відповіді.

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

Багатократні взаємодії без відкритого з’єднання

Дизайни зі станом полегшують взаємодію: якщо серверу потрібна додаткова інформація, він може запитати про неї через вже відкрите з’єднання. Наприклад, користувач просить забронювати рейс до Делі, але забуває вказати дату. Сервер із підтримкою стану може просто запитати про дату та чекати на відповідь через те саме з’єднання.

Протокол без стану не може підтримувати відкриті з’єднання для цієї мети, тому MCP визначає структурований багатокроковий процес замість цього:

1. Коли сервер отримує запит, у якому відсутні необхідні параметри, він повертає спеціальний результат input required, замість того щоб завершити роботу або чекати.
2. Клієнтське програмне забезпечення просить користувача надати відсутню інформацію.
3. Клієнт поміщає відповіді у об’єкт input responses та надсилає новий, повністю автономний запит, який сервер може обробити.

Оскільки другий запит містить усе необхідне, він може потрапити на будь-яку інстанцію сервера. Серверу не потрібно пам’ятати, що він поставив запит; клієнт продовжує обробку. Якщо серверу потрібно пов’язати ці два запити (наприклад, щоб уникнути повторної виконання ресурсомістких операцій), він може повернути клієнту непрозорий токен для повторного використання, замість того щоб зберігати приховану інформацію.

Маршрутизація за допомогою заголовків замість тіла

Безстановий підхід також відкриває можливості для покращення продуктивності та ефективності роботи. Особливо варто зазначити два зміни: маршрутизація на основі заголовків та можливість кешування результатів списку.

Деталі протоколу в HTTP-заголовках

Раніше інфраструктура перед сервером MCP, така як API-шлюз, брандмауер веб-додатку чи балансувальник навантаження, мусила аналізувати тіло JSON кожного запиту лише для того, щоб з’ясувати, який метод чи інструмент викликається. Аналіз тіла запиту на рівні краю вимагає ресурсів процесора, збільшує затримки та у багатьох шлюзах є складним для налаштування.

Згідно з новими правилами, HTTP-запити повинні відображати ключову інформацію протоколу у заголовках:

• MCP-Method, наприклад tools/call;
• MCP-Name — назва конкретного інструменту, який викликається.

Гейтвей може читати ці заголовки та направляти, обмежувати частоту або блокувати трафік, не торкаючись самого вмісту повідомлення. Це дозволяє просто сформулювати поширені правила — наприклад, надсилати дорогі інструменти до спеціального пулу екземплярів, застосовувати суворіші обмеження до певного інструменту чи повністю блокувати його під час інциденту. Як і завжди з заголовками, сервер має перевіряти їх відповідність тілу повідомлення, щоб клієнт не міг обійти правила, надсилаючи оманливі заголовки.

Списки інструментів та запитів, які можна кешувати

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

Списки інструментів та запитів змінюються рідко, тому нова версія дозволяє кешувати результати цих списків. Клієнт може отримати список інструментів один раз, зберегти його в пам’яті та використовувати знову для подальших запитів, замість того щоб запитувати його заново. Ця ж можливість дозволяє спільній інфраструктурі, такій як шлюз або HTTP-кеш перед серверами, відповідати на повторні запити до списків від багатьох клієнтів одночасно. У будь-якому разі до сервера надходить значно менше запитів. Як і у будь-якому кеші, потрібен спосіб анулювати його дію, коли оновлення змінює список, тому краще планувати термін закінчення дії кешу або використання версіонування, а не кешувати дані вічно.

Довготривала робота з фоновими завданнями

Деякі інструменти відповідають протягом кількох мілісекунд, наприклад під час пошуку інформації про погоду. Інші — ні: запит до асистента щодо аналізу 10 000 документів може зайняти двадцять хвилин. У звичайному циклі запит-відповідь клієнт мусить підтримувати з’єднання відкритим протягом усього часу, що займає ресурси на обох кінцях та змушує інтерфейс користувача чекати без дії.

Щоб вирішити цю проблему, у версії 2026 включено перероблену структуру Tasks:

1. Створення. Коли клієнт ініціює використання ресурсоємного інструменту, сервер негайно відповідає ідентифікатором завдання, наприклад task_abc123, після чого початковий запит завершується.
2. Виконання на фоні. Сервер виконує аналіз у фоновому режимі, поки користувач продовжує працювати з іншими частинами програми.

Перевірка прогресу. У будь-який момент клієнт може запитати про статус та результати завдання за допомогою виклику Task Get.

Оновлення даних. Якщо під час виконання завдання потрібна додаткова інформація, клієнт надсилає її за допомогою Task Update.

Це знайомий асинхронний патерн обробки завдань з веб-API, застосований у MCP. Він забезпечує реактивність додатків незалежно від складності виконуваних завдань. При розгортанні з кількома інстанціями пам’ятайте, що статус завдання має зберігатися в місці, до якого може отримати доступ кожна інстанція, адже виклик Task Get може надійти на інший сервер, ніж той, що створив завдання. Протокол більше не вимагає спільного стану сеансу, але відповідальність за стабільне зберігання завдань все одно лежить на вас.

Що це означає для ваших серверів

Якщо ви керуєте або створюєте сервери MCP, практичний перелік контролю виглядає так:

• Видаліть приховану пам’ять на кожне з’єднання. Усе, що інструменту потрібно між викликами, має знаходитися у прямому сховищі, індексованому за ідентифікаторами, які надсилає клієнт.
• Читайте контекст з кожного запиту. Беріть версію протоколу, ідентичність та можливості клієнта з _meta, а не з сеансу.
• Проектуйте інструменти так, щоб вони запитували, а не чекали. Повертайте результат, який вимагає введення даних, коли бракують параметрів, та очікуйте відповідей у новому запиті.
• Використовуйте заголовки маршрутизації на рівні краю мережі. Налаштуйте шлюзи для маршрутизації та обмежень за параметрами MCP-Method та MCP-Name, а також перевіряйте їх у відповідності з контентом запиту на сервері.

Списки кешу та планування анулювання. Дозвольте клієнтам та шлюзам кешувати списки інструментів та запитів, з чітким способом їх оновлення після розгортання.

Переміщення повільних інструментів у завдання. Швидко повертайте ідентифікатор завдання та зберігайте стан завдання у сховищі, яке використовується всіма екземплярами.

Основні висновки

• Безстановий підхід замінює собою сеансову архітектуру MCP на незалежні виклики типу запит-відповідь, усуваючи потребу у «липких сеансах» чи спільному сховищі сеансів лише для масштабування.
• Хендшейки та ідентифікатори сеансів відсутні; кожен запит містить версію протоколу, ідентифікатор клієнта та його можливості у полі _meta.
• Відсутню інформацію обробляється за допомогою результату input required та наступного запиту з полем input responses, замість підтримки відкритого з’єднання.
• MCP-Method та MCP-Name — це заголовки, які дозволяють шлюзам направляти трафік, обмежувати його швидкість та блокувати без необхідності парсингу тіл JSON.
• Стабільні списки інструментів, запитів та ресурсів можна кешувати, що зменшує повторні навантаження на сервери.
• Інструменти з довгим часом виконання негайно повертають ідентифікатор завдання, а клієнти використовують Task Get та Task Update для подальших дій.
• Безстановість означає переміщення стану, а не його повне усунення: дані додатку та прогрес виконання завдань все одно потребують надійного місця зберігання, до якого може отримати доступ кожен екземпляр. Перед тим, як будувати щось на основі цих елементів, перевірте їхні точні назви відповідно до поточних специфікацій.

Пов’язана література

• Як протокол Model Context Protocol дозволяє штучним інтелектуальним агентам знаходити та викликати інструменти — чітке пояснення MCP: як хости, клієнти та сервери дозволяють штучному інтелектуальному додатку знаходити інструменти, викликати їх за допомогою структурованих вхідних даних та які є його обмеження.
• Проектування ефективних з точки зору токенів інтерфейсів інструментів для серверів MCP з агентами — дізнайтеся, як об’єднати десятки визначень інструментів MCP у кілька інструментів, орієнтованих на конкретну сферу та з розміткою дій, не втрачаючи при цьому жодної функціональності.