Протоколът за контекст на модела достигна важен инфраструктурен етап: неговата ревизия от 2026-07-28 премества протокола към ядро ​​без състояние. За екипи, които изграждат системи за агенти, сървъри за инструменти, IDE интеграции или слоеве за оркестрация с множество модели, това не е актуализация на козметични спецификации. Той променя предположенията относно сесиите, инициализацията, мащабирането, съвместимостта и управлението.

Кандидатът за версия MCP описа спецификацията от 28 юли като добавяне на протоколно ядро ​​без състояние, рамка за разширения, задачи, MCP приложения, втвърдяване на авторизацията и официална политика за оттегляне. Официалният MCP блог също предупреждава, че версията съдържа нарушаващи промени. GitHub, който оперира с едно от най-видимите MCP сървърни имплементации, каза преди окончателното издание, че неговият MCP сървър вече поддържа новата спецификация и описа протокола като „преминаващ без състояние“ на 28 юли.

Практическото значение е просто: MCP се оформя по-малко като локален интеграционен слой, натоварен със сесии, а по-скоро като протокол в интернет мащаб за отдалечен достъп до инструменти. Това има значение, защото агентните системи вече не са ограничени до инструменти за разработчици на настолни компютри. Те все повече работят в облачни услуги, CI системи, работни потоци за поддръжка на клиенти, инструменти за проследяване на проблеми и платформи за корпоративна автоматизация.

Какво се промени в MCP

Основната промяна е преминаването към ядро ​​на протокол без състояние. Регистърът на промените на GitHub казва, че новото ядро ​​премахва сесии и инициализиране, с цел да направи отдалечените MCP внедрявания по-лесни за мащабиране. Това е значителна архитектурна промяна. Протоколите с поддържане на състоянието могат да работят добре за локални инструменти и контролирани среди, но усложняват хоризонталното мащабиране, изпълнението без сървър, преодоляването при срив, крайното внедряване и балансирането на натоварването.

Ядрото без състояние дава на изпълнителите повече свобода да изпълняват MCP сървъри зад обикновена уеб инфраструктура. Заявките могат да се разпределят между екземпляри, без да се запазва дълготрайна сесия на конкретен бекенд. За големи организации това може да намали оперативната сложност. За по-малки екипи може да направи хостваните MCP сървъри по-лесни за внедряване с помощта на управлявани изчисления вместо персонализирана дълготрайна инфраструктура.

По-широкото издание от 2026-07-28 също въвежда рамка за разширения и задачи, според материалите за кандидатстване за изданието. Тези допълнения предполагат, че MCP става все по-модулен и по-ясен за по-продължителна работа. MCP Втвърдяването на приложенията и оторизацията е в същата посока: протоколът се развива от ранно лепило на екосистемата в по-официален слой за взаимодействие между агенти и инструменти.

Цената на това съзряване е работата по съвместимостта. Блогът MCP характеризира изданието като такова с революционни промени, а материалите за TypeScript и C# SDK, публикувани около ревизията, се фокусират върху поддръжката за миграция и концепциите без състояние. Всеки екип, работещ със сървър MCP, вграждайки MCP в разширение на IDE или извиквания на агент за маршрутизиране през вътрешна инфраструктура, трябва да третира ревизията като инженерно събитие, а не като фонова актуализация на стандартите.

Защо MCP без състояние има значение за разработчиците и операторите

Агентните инструменти имат проблем с мащабирането, който изглежда различно от обикновеното API мащабиране. Една заявка от един потребител може да задейства много извиквания на инструменти, обръщане на модел, повторни опити, четене на файлове, заявки за търсене и стъпки за одобрение. Когато протоколът на инструмента предполага трайни сесии, производствените оператори трябва да запазят състоянието в тези взаимодействия или да създадат заобиколни решения около протокола.

Чрез премахване на сесиите от ядрото MCP се вписва по-добре в среди, където работните натоварвания на агентите са бурни, разпределени и асинхронни. Безсървърни функции, периферни работници, внедрявания на Kubernetes и многорегионални системи - всички те се възползват, когато заявките могат да се обработват независимо.Това не елиминира състоянието от приложенията на агенти; премества състоянието в бази данни на приложения, опашки със задачи, системи за идентичност или изрични слоеве на работния поток, вместо да го вгражда в ядрото на протокола.

За разработчиците промяната в крайна сметка трябва да направи сървърите на отдалечени инструменти по-лесни за използване. За екипите на платформата може да опрости наблюдението и планирането на капацитета. Вместо да отстраняват грешки в непрозрачното поведение на афинитета на сесията, операторите могат да се съсредоточат върху проследяване на ниво заявка, забавяне на извикване на инструмент, решения за оторизация и модели на грешки.

Има и ъгъл на управление. Тъй като MCP става все по-често срещан в асистентите за кодиране и корпоративните агенти, компаниите ще се нуждаят от политики относно кои инструменти агентите могат да извикват, до какви данни имат достъп и кои потребители или услуги имат право да ги извикват. Следователно втвърдяването на Authorization в новата версия не е случайно. Той отразява реалността, че достъпът до инструменти вече е граница на сигурността, а не само удобство за разработчиците.

Кой е засегнат

Най-пряко засегнатите групи са MCP поддържащи сървъри, SDK потребители, екипи на платформи на агенти и организации, излагащи вътрешни инструменти на AI агенти. Ако даден сървър зависи от поведението на сесията или по-старите потоци на инициализация, той ще се нуждае от тестване спрямо новата спецификация. Ако дадено приложение поддържа множество MCP версии, може да се нуждае от договаряне на версията, слоеве за съвместимост или план за поетапна миграция.

Доставчиците на IDE и инструменти за разработчици също са в обхвата. MCP се появява все по-често заедно с агентите за кодиране, персонализираните агенти и функциите за управление на модела. Ядрото на протокола без състояние улеснява тези продукти да извикват надеждно отдалечени инструменти, но само ако техните интеграции са в крак със спецификацията.

Бизнесите, използващи автоматизация на агенти, трябва да обърнат внимание, дори ако никога не са чели MCP спецификацията. Промяната може да повлияе на надеждността на агентите, които се свързват с хранилища, системи за билети, бази данни, вътрешни бази знания или инструменти за внедряване. По време на прозорците за миграция вероятните режими на повреда не са само очевидни прекъсвания. Те могат да включват липсващи възможности на инструмента, променено поведение при удостоверяване или агенти, които поемат по различни пътища, защото сървърът на инструмента вече не се държи според очакванията.

За AI API шлюз като Model Gate, връзката е практична. Унифициран AI API все повече се намира близо до маршрутизирането на модела, API управлението на ключове, анализите на използването и управлението на екип API. Тъй като системите на агенти добавят MCP извиквания на инструменти освен обикновените извиквания на модели, слоевете на шлюз и наблюдаемост ще трябва да отчитат и двете страни на работния поток: кой модел е използван, кои инструменти са били извиквани, какво струват, кой ги е упълномощил и къде са възникнали грешки.

Приоритети на миграция и отворени въпроси

Първият приоритет на миграция е тестването за съвместимост. Екипите трябва да инвентаризират MCP клиенти и сървъри, да идентифицират зависимости от сесии или да инициализират поведение и да тестват спрямо 2026-07-28 SDK или материалите за съответствие, когато има такива. Производствените системи трябва да организират надграждането, особено ако агентите извършват действия със странични ефекти, като създаване на заявки за изтегляне, модифициране на проблеми, заявки за клиентски данни или изпълнение на работни потоци за внедряване.

Вторият приоритет е възможността за наблюдение. Инфраструктурата без състояние може да бъде по-лесна за мащабиране, но системите с разпределени агенти все още се нуждаят от идентификатори на корелация, улавяне на проследяване, регистрационни файлове на заявки и събития на политики. Без тях екипите могат да разменят сложността на сесията със сложността на отстраняването на грешки. Анализът на използването трябва да прави разлика между извикванията на модели и извикванията на инструменти, особено когато работните потоци на агентите се таксуват, лимитират по тарифи или се одитират от екип.

Третият приоритет е прегледът на оторизацията. Ако новата спецификация втвърди семантиката на оторизацията, изпълнителите не трябва просто да пренасят стари допускания за достъп в новата версия. Те трябва да проверят отново обхватите на токени, делегирането на потребители, акаунтите за услуги, журналите за проверка и поведението на отказ.Достъпът до инструмента трябва да е с най-малки привилегии по подразбиране, особено за отдалечени MCP внедрявания.

Някои подробности си струва да бъдат проверени, преди организациите да вземат необратими дизайнерски решения. Проучването, налично за тази статия, включваше кандидата за версия, страницата със спецификации, SDK материали за миграция и GitHub бележка за внедряване. Окончателната нормативна формулировка на спецификацията 2026-07-28 трябва да бъде прегледана директно, преди да се цитират точните изисквания на протокола във вътрешните стандарти или клиентската документация.

Дори с това предупреждение, посоката е ясна. MCP става все по-ориентиран към производството протокол за агентска инфраструктура. Ядрото без състояние трябва да направи отдалечените внедрявания по-лесни за мащабиране, но също така принуждава екосистемата да изчисти предположенията от по-ранни реализации. За изграждане на екипи с агенти, това е вид промяна на протокола, която заслужава билет за спринт, а не само отметка.