MCP більше не схожий на інтерфейс плагіна виробника — він починає схожий на загальну трубу. Труба буде міцнішою, але також менш підданою впливу.Автор статті, джерело: 0x9999in1, ME News

Коротко
- 28 липня 2026 року MCP випустив п’яту версію специфікації
2026-07-28, яку офіційно визначено як найбільш масштабну ревізію з моменту створення протоколу. Єдиним ключовим дією є видалення сесій з протокольного рівня. initialize/initializedЗакінчився handshake,Mcp-Session-IdЗаголовок запиту відсутній. Кожен запит містить версію протоколу, ідентифікацію клієнта та оголошення можливостей у_meta. Будь-який запит може бути оброблений будь-яким екземпляром — достатньо звичайного балансування навантаження за циклічним принципом.- Це не оптимізація продуктивності, а помилка архітектури. Стійкі сесії та спільне сховище сесій колись були найбільш витратною частиною рахунків на серверах MCP.
- Статус не зник. Його перенесено з транспортного рівня до параметрів інструменту, де він називається «явним обробником». Модель бачить його і може ним керувати.
- Інтерфейс взаємодії (MCP Apps) та довготривалі завдання (Tasks) офіційно включені до версійної розширюваної структури, основний протокол більше не розширюється для нових можливостей. Аутентифікація наближається до реальних стандартів OAuth 2.0 та OIDC, а розширення корпоративного управління авторизацією також перейшло у стабільну версію того ж дня.
- Це коштує реальних грошей: це зміна, що порушує сумісність. Roots, Sampling, Logging та стара передача HTTP+SSE виведені з експлуатації, офіційно надано мінімум 12 місяців перехідного періоду.
- Одне речення для оцінки: MCP більше не схожий на інтерфейс плагіна виробника — він починає схожий на загальну трубу. Труба буде міцнішою, але також менш вибагливою.
Перш за все, саме ті два рядки, які були видалені, є суттю цього оновлення
Спочатку — протилежний інтуїції факт.
Найважливішою частиною цієї оновлення, яку називають «найбільшим перезавантаженням у історії», є не те, що додали, а те, що видалили.
initialize та initialized ця пара привітань існувала з дня появи MCP у листопаді 2024 року.Mcp-Session-Id Цей заголовок запиту є основою всіх схем розгортання після впровадження віддаленого MCP. 28 липня обидві речі були видалені разом.
Як виглядає новий запит? Дуже простий.
POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Назви методів і інструментів переміщено до HTTP-заголовків. Шлюзи, обмежувачі та WAF більше не повинні розбирати JSON-тіло, щоб здогадатися, що саме запитується — достатньо подивитися на заголовки. Версія протоколу, інформація про клієнта та оголошення можливостей усі передаються разом із запитом у _meta. Щоб заздалегідь дізнатися, які можливості має сервер, додано новий server/discover, але він є необов’язковим.
Це що означає? Це означає, що сервер MCP нарешті перетворився на звичайну HTTP-навантаження.
За словами Шона Робертса, віце-президента Netlify з питань штучного інтелекту, безстанова основа робить MCP рівноправним HTTP-навантаженням, не вимагаючи обходу управління сесіями. Cloudflare висловлюється ще різкіше, кажучи, що ця версія дозволяє інфраструктурі агентів працювати так само, як і інші частини вебу: безстаново, кешовано, маршрутизовано та глобально масштабовано.
Звучить як стандартний промо-текст від виробника. Але на цей раз все інакше, бо вони говорять про конкретну річ: сесія зникла, тому Lambda працює, Workers працюють, крайові вузли працюють.
Друге: в’язкість сесій — це реальна стіна, з якою стикається масштабування агентів
Навіщо так сильно застосовувати ці заходи?
Стара модель мала неподолану фізичну обмеження: сесія була прив’язана до екземпляра, який обробляв рукостискання.
Тож усі були змушені робити одне й те саме: або ввімкнути сесії зі збереженням стану, щоб балансувальник навантаження пам’ятав, на який сервер направляти кожного клієнта; або встановити спільне сховище, наприклад Redis, щоб зберігати стан сесії для всіх інстансів.
Обидва шляхи працюють. Але обидва передбачають сплату прихованого податку.
Сесійна прив’язка робить масштабування незручним. Коли екземпляр потрібно вимкнути, всі його сесії розриваються. Нові екземпляри, запущені під час стрибка трафіку, не можуть отримати старі сесії, і навантаження завжди нерівномірне. Шлях із спільним сховищем дорожчий — ви вводите становий проміжний компонент для потреби, яка за суттю полягає лише у “запам’ятовуванні імені клієнта”, і повинні забезпечити його високу доступність.
Коли масштаб невеликий, це не проблема. Коли масштаб зростає — це вже проблема.
Щоб зрозуміти, як змінився масштаб, подивіться на цифри: у грудні 2025 року, на першу річницю виникнення MCP, місячна кількість завантажень SDK становила 97 мільйонів. До цього випуску у липні 2026 року Anthropic повідомила, що місячна кількість завантажень перевищила 400 мільйонів, а на офіційному блозі зазначено «майже п’ятсот мільйонів» — зростання в чотири рази за рік. Загальна кількість завантажень SDK для TypeScript і Python кожна перевищила поріг у мільярд.
У каталозі власного підключення Claude від Anthropic зараз наведено понад 950 серверів MCP. Дані компанії з обсервабельності Honeycomb краще підтверджують, що агенти вже працюють у реальних умовах: майже 20% усіх інтерактивних запитів щомісяця ініціюються агентами.
Півроку — чотириразовий зростання. Під такою кривою будь-яка «прихована податкова» структура буде збільшена до явного рахунку.
Тож офіційна формулювання — «одна з найбільш затребуваних функцій розробниками». Не ми хочемо змінити — це люди, хто працює в продакшні, вже не можуть більше витримувати.
Три: стан не зник, його перенесли перед модель
Тут є одна дуже важлива неправильна інтерпретація.
Протокол без стану не означає, що ваша програма без стану.
Наведений у специфікації альтернативний підхід називається явним обробником. Якщо ваш інструмент повинен зберігати стан між викликами, нехай він повертає ідентифікатор, наприклад basket_id, який модель потім використовуватиме як параметр у наступному виклику.
Та фраза з офіційного блогу, на мою думку, є найцікавішою у всьому документі: вони виявили, що це працює краще, ніж приховувати стан на рівні транспортного шару, оскільки модель бачить цей дескриптор і може поєднувати його між інструментами.
Зупиніться і подумайте про значення цього твердження.
Попередня логіка дизайну була такою: стан — це справа інфраструктури, модель не повинна цим займатися. Тепер логіка зворотня: стан є частиною ланцюжка міркувань моделі, і приховування його призводить до неточних висновків моделі.
Приховування стану робить модель глупішою. Цей висновок не виведено з естетики архітектури, а отримано з півтора року виробничих аварій.
Та сама ідея була застосована до шляху, коли сервер ініціює запит. Раніше, коли інструмент виконував дію, він запитував користувача: «Підтвердьте видалення цих 3 файлів?», і для цього використовував постійно відкритий SSE-потік, щоб надіслати запит назад на клієнта. Після переходу на безстановий режим цей потік зник, і на його місце прийшли багатоетапні запити (Multi Round-Trip Requests, MRTR).
Механізм не складний. Сервер повертає тип результату "потрібно ввести", разом із запитаним питанням та рядком requestState. Клієнт збирає відповіді, а потім повторно відправляє виклик із inputResponses та незмінним requestState. Оскільки вся необхідна інформація для продовження міститься в requestState, ця спроба повторного виклику може бути оброблена на іншому сервері й продовжити роботу.
Керівник продукту Supabase Ініан Парамешваран сказав чесно: підтримка elicitation довго була в їхньому плані, але через те, що Supabase MCP працює без стану, це було неможливо. Після MRTR це стало можливим: інструмент може спочатку перевірити витрати перед створенням проекту та запитати перед видаленням даних.
Тут я хочу згадати про момент, який не підкреслюється в документації, але з яким обов’язково зіткнетесь на практиці:requestState зберігається та повертається клієнтом, тому він природно знаходиться поза межами довіри. Якщо сервер вважатиме його надійним вводом і безпосередньо десеріалізуватиме, то відкриє собі дірку. Підпис, шифрування та встановлення терміну дії — ці три речі, на мою думку, швидко стануть стандартною практикою в спільноті. Це моя оцінка, а не вимога стандарту.
Чотири: Розширена рамка: протокол починає вчитися "не набирати вагу"
Друга справжня ставка — це те, що розширення рамок перетворилося з звичаю на інститут.
Зворотне DNS-іменування, узгодження можливостей через extensions, окремі сховища ext-* з авторизованими супроводжувачами, версії незалежні від основної специфікації. Звучить нудно, але це вирішує хворобу, з якою стикаються всі успішні протоколи: основний код стає надто об’ємним.
Два розширення тепер офіційно підтверджено.
MCP Apps дозволяють серверу надсилати інтерфейс взаємодії безпосередньо в діалог. Не просто текст, не структурований JSON, а повний HTML-інтерфейс, що працює в ізольованому iframe. Можна використовувати діаграми, форми, вибірники. Ключова ідея — інструменти мають заздалегідь оголошувати шаблони UI, щоб клієнт міг попередньо завантажити їх і провести безпековий аудит ще до відображення будь-яких елементів. Дії на інтерфейсі все ще виконуються через звичайний канал JSON-RPC для викликів інструментів.
Завдання: обробка іншої половини проблеми: тривалі завдання. Вони були підняті з експериментальної функції до офіційного розширення, а їхній цикл життя був перероблений у безстановий:tools/call повертає дескриптор завдання, клієнт використовує tasks/get для опитування, разом із новими tasks/update та tasks/cancel.
Варто зазначити, що tasks/list видалено. Причина проста: без сесії операція «отримати список усіх завдань» більше не є безпечною, оскільки неможливо визначити, до кого стосується «усі».
Це розширення надано AWS. Свамі Сівасубраманіан, віце-президент з агентного ШІ в Amazon, сказав, що нові стандарти та безстансове ядро вже ввійшли до Bedrock AgentCore. З боку Microsoft, Тіна Шухман, віце-президент інженерного відділу Foundry, зазначила, що MCP дозволив їм розширити інтеграції з десятків до тисяч, а Foundry toolbox об’єднав інструменти через єдиний MCP-ендпоінт для централизованого управління політикою, ідентичністю та спостережуваністю.
Протокол, який AWS, Microsoft, Google Cloud і Cloudflare використовують як основу для побудови своїх сервісів. Це вже не просто специфікація плагіна однієї компанії.
П’ять: справжня проблема — це не підключення, а ідентичність
У офіційному блозі є чесне зізнання: за останній рік, спілкуючись із реалізаторами, вони найбільше часу витрачали на авторизацію.
Ця версія додала шість SEP у авторизації — усі вони не дуже сексуальні, але необхідні. Сервер авторизації має повертати параметр iss згідно з RFC 9207, клієнт повинен перевіряти його перед обміном коду, це закриває атаку з плутаниною сервера авторизації. Під час динамічної реєстрації клієнт має вказувати application_type, і для настільних та CLI-додатків localhost callback більше не буде відхилятися без підстав. Посвідчення прив’язані до issuer, який їх видав, і не можуть використовуватися між різними серверами авторизації.
Більш значущим є те, що динамічна реєстрація клієнта (DCR) офіційно виведена з експлуатації, і напрямок зміщується на документ з метаданими ідентифікатора клієнта (CIMD). DCR ще працює, збережено зворотну сумісність, але в майбутніх версіях його видалить.
Того ж дня enterprise-grade托管授权扩展 (EMA) перейшла у стабільну версію. Ця подія може мати ще більше значення для корпоративних ІТ, ніж безстані.
У старій моделі кожному співробітнику потрібно було окремо надавати доступ до кожного сервера. При прийнятті на роботу потрібно було вручну підключатися до кожного сервісу. Відділ безпеки не міг впроваджувати єдину політику — права доступу встановлювалися користувачами вручну, без централізованого контролю та можливості аудиту. Ще гірше те, що робочі та особисті облікові записи змішувалися, а механізм, що змушує використовувати корпоративну ідентичність, відсутній.
EMA перетворює власного провайдера ідентичності підприємства на орган прийняття рішень. На нижчому рівні використовується ID-JAG-заява, видана IdP під час однократного входу, яку клієнт використовує для отримання токена доступу від сервера авторизації MCP. Користувач не проходить через жодну сторінку згоди на будь-якому окремому сервері.
Okta — перший підтримуваний IdP, який використовує його Cross App Access. З боку клієнта підключено всі Claude та VS Code. З боку сервера вже підтримуються Asana, Atlassian, Canva, Figma, Granola, Linear, Supabase, Slack знаходиться в розробці. Оцінка керівника інженерного відділу Linear Тома Мура дуже симпатична: увійдіть один раз — і всі MCP-з’єднання автоматично налаштовуються, це магічно.
Магічна частина — не в досвіді, а в управлінні. Доступ до рішень знову повернувся до панелі керування IdP, а ланцюг аудиту охоплює всі конектори.
Але я повинен сказати це повністю: безстановість та EMA вирішують питання ідентичності та масштабу, але не всі аспекти безпеки агентів. Ці дві цифри з звіту Cisco «Стан безпеки ШІ до 2026 року» все ще там: 83% організацій планують впровадити можливості агентів, а лише 29% вважають себе готовими. Проблеми, такі як ін'єкція підказок, отруєння описів інструментів, використання агентів як мостів для поперечного руху, не зникнуть просто тому, що протокол видалив сеанс.
Good news is thatMcp-Method and Mcp-Name after the header, the cost of gateway strategy execution has decreased. The specification also requires the server to reject requests with inconsistent headers and body, which blocks a class of routing and security mismatches. This is a substantive improvement in defensive posture. But that’s it.
Шість: Вартість: Це зміна з руйнуванням, рахунок вже виставлено
Мені не подобається говорити лише про прибуток, не згадуючи про рахунки.
Ця версія є breaking change. Функції Roots, Sampling та Logging одночасно виведені з експлуатації. Старий протокол HTTP+SSE також офіційно виведено з експлуатації. У специфікації також введено формалізований політику життєвого циклу функцій: Active → Deprecated → Removed, кожен етап триває щонайменше 12 місяців.
Також були внесені дрібні, але важливі зміни: схеми вводу-виводу інструментів тепер підтримують повний словник JSON Schema 2020-12, oneOf,anyOf та умови тепер працюють; код помилки «Ресурс не знайдено» змінено з власного -32002 на стандартний JSON-RPC -32602. Якщо ви жорстко закодували -32002 у своєму коді, цей рядок потрібно виправити.
Найбільш витратним місцем для міграції, як вказали самі офіційні особи: розробники, що залежать від ідентифікаторів сесій.
Тому розклад варто повторити. Кандидат у версії був заблокований 21 травня, а офіційний реліз відбувся 28 липня — між цими датами було виділено цілі десять тижнів для перевірки розробниками SDK та реалізаторами клієнтів. Чотири SDK рівня Tier 1 (TypeScript, Python, Go, C#) підтримали нову версію в день релізу, а Rust SDK був у beta.
Десятижоденне відкрите вікно верифікації + 12-місячний період переходу з виведення з експлуатації + стандартизація SEP повинні мати відповідні сценарії в тестовому наборі на сумісність, перш ніж будуть затверджені. Разом ці три пункти становлять найбільш професійну частину цього оновлення в моїх очах.
Це не приховування зламів, ні перекладання відповідальності за злами на спільноту.
Вимога до узгодженості особливо важлива. Щоб додавати нові функції до стандарту, спочатку визначте перевіряємі сценарії. Це спосіб зв’язати «наміри дизайну» з «фактичною реалізацією» — багато протоколів навчилися цьому після великих втрат.
Цікаво, що міграція принесла позитивний дохід. Головний технічний офіцер Manufact, який стоїть за відкритим фреймворком mcp-use, Енріко Тоніато, навів конкретні цифри: за допомогою нового SDK v2 розділення клієнта та сервера зменшило розмір пакету приблизно на 83% і прискорило роботу на 25%.
Одночасне зменшення архітектури і розміру пакета. Таке трапляється не часто.
Сім. Моя думка
Як ви ставитеся до цієї оновленої версії?
Моя перша думка: це була помилка, і дуже гарна помилка.
Початковий двосторонній становий дизайн MCP був розроблений навколо локальних сценаріїв. Ваш редактор підключений до сервера, що працює на локальній машині, встановлює з’єднання один раз і підтримує його — це абсолютно логічно. Проблема виникла після того, як MCP було запущено віддалено, і ця модель була перенесена в хмарне середовище, після чого всі почали накладати на неї патчі. Сесії з прив’язкою — це патч, зберігання сесій у Redis — це патч, тримання довготривалого з’єднання для elicitation — це також патч.
Коли патчів стає занадто багато, настав час змінити фундамент. За словами співавтора протоколу Давіда Сорії Парра, ця версія включає всі уроки минулих 18 місяців. Нік Купер, основний розробник, висловився точніше: MCP вже півтора роки і активно засвоює досвід десятиліть розробки веб-протоколів, перетворюючись на більш дозрілий протокол.
Друге твердження: справжнім переломним моментом цієї оновленої версії є управління, а не технологія.
Часову шкалу варто перевірити ще раз. 25 листопада 2024 року Anthropic відкрила MCP. 9 грудня 2025 року MCP було передано новоствореній Agentic AI Foundation під егідою Фонду Linux — це цільовий фонд, запущений Anthropic, Block та OpenAI, з підтримкою Google, Microsoft, AWS, Cloudflare та Bloomberg. Через вісім місяців було випущено першу велику версію.
Протокол, створений однією компанією, після передачі здійснив свою найскладнішу операцію, а не потрапив у тупик комітету. Саме це є підтвердженням ефективності відкритого управління.
Зі списку екосистемних платформ видно, що пріоритети змінилися. Figma говорить про з’єднання дизайну та коду, Intuit — про надання надійного фінансового інтелекту мільярду споживачів і бізнес-клієнтів, Zoom — про безпечне впровадження інтелекту зустрічей у платформи ШІ. Це не мова іграшок для розробників, а мова продуктів.
Третє твердження, і, на мою думку, найважливіше: зрілість протоколу має свою ціну — ціна називається «без характеру».
Безстані, маршрутизовані, кешовані, відстежувані. W3C Trace Context тепер передається через фіксовані ключі в _meta, що забезпечує сумісність із OpenTelemetry для розподіленого відстеження «з коробки». Ці терміни ви вже зустрічали в історії розвитку HTTP, REST і gRPC.
MCP стає трубопроводом, про який ви не будете говорити. Як ніхто не обговорює, наскільки захопливим був TCP сьогодні.
Це добре? Я вважаю, що так. Перемога на рівні даних завжди належить не найбільш вражаючому дизайну, а найменш схильному до поломок. У момент видалення сесії MCP пожертвував частиною елегантності, щоб отримати здатність масштабуватися горизонтально за підтримки балансування навантаження за циклічним принципом.
Масштабування агентів — це не про те, наскільки розумні моделі. Це про те, про що ніхто не хоче говорити: де зберігати розмови, як наслідувати ідентичність, чи залишаються завдання після відключення, скільки разів потрібно натиснути кнопку згоди, коли десять тисяч співробітників під’єднуються до тисячі серверів.
Ця версія значно змістила вперед ці питання.
Щодо ентузіазму, труба не відповідає за надання ентузіазму. Вона лише забезпечує, щоб не було витоків, коли ти не дивишся на неї.
Джерело цитування
- Блог Model Context Protocol, «Специфікація від 2026-07-28», 2026 рік, 28 липня. https://blog.modelcontextprotocol.io/posts/2026-07-28/
- Блог протоколу модельного контексту, «Підприємницьке керування авторизацією: Zero-touch OAuth для MCP», 2026 рік. https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/
- Claude від Anthropic, «Приведення MCP 2026-07-28 до Claude», 2026 рік, 28 липня. https://claude.com/blog/bringing-mcp-2026-07-28-to-claude
- Блог MCP Servers, «MCP Specification від 2026-07-28: Безстановищнє, розширюване майбутнє», 2026 рік. https://blog.mcpservers.org/posts/mcp-spec-2026-07-28
- Linux Foundation, «Linux Foundation оголошує про створення Agentic AI Foundation», 9 грудня 2025 року. https://linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation
- Anthropic, «Донорство Model Context Protocol та створення Agentic AI Foundation», грудень 2025 року. https://anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
- Cisco, «State of AI Security 2026», 2026 рік. https://blogs.cisco.com/ai/cisco-state-of-ai-security-2026-report
- IT之家, Найбільше оновлення за всю історію: випущено специфікацію MCP 2026-07-28, перехід на "безстанову" основу, 29 липня 2026 року. https://www.ithome.com/0/983/102.htm
