Протоколът за контекст на модела достигна важен инфраструктурен етап: неговата ревизия от 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 става все по-разпространен в асистентите за кодиране и корпоративните агенти, компаниите ще се нуждаят от политики относно кои инструменти агентите могат да извикват, до какви данни имат достъп и кои потребители или услуги имат право да ги извикват. Следователно втвърдяването на разрешението в новата редакция не е случайно.Той отразява реалността, че достъпът до инструменти вече е граница на сигурността, а не само удобство за разработчиците.

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

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

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

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

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

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

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

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

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

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

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