Што означаюць безстановы ядро MCP і керованая автарызація для команд з інтэграціі.
Управління Linux Foundation, транспорт HTTP без стану і автарызація, керованая постачальнікамі ідэнтычнасці, робяць MCP практычным для інтэграціі падпрыемств. Ось што змянілася.
Протокол кантэксту мадэлі стандартызуе способ, якім агенты штучного інтэлекту підключаюцца до сістэм навколо себе, подыбно до того, як API колісь стандартызувалі взаемодыю між додаткамі. На працягу двох років гэты протокол став прэдметом увагі фахівців з інтэграціі і IT-операцій — ён показуе обнадыйлівій розвіток і більшэ нагадуе інструменты для розробніків, ніж шчось, што могло б схваліты рада з архітэктуры. Гэтая відстань скоротылася: за вісім місяців протокол MCP подолав тры важліві рубежы, што нагадуе початкові етапі розвітку управління API блізько 2010 року, і повторуе гэты шлях для агентаў штучного інтэлекту.
Тры зміні за вісім місяців
Нейтральна адміністрацыя. У грудзені 2025 года Anthropic перадала MCP у структуру Agentic AI Foundation. эта ўстанова являе сабою спецыяльны фонд у складзе Linux Foundation, створаны Anthropic, Block і OpenAI, а падтрымліваець яго — Google, Microsoft, AWS, Cloudflare і Bloomberg. Дзякуючы гэтаму MCP больш не падкоралася планам адзінаго віробніка, а перайшла пад нейтральны кераванне, якое існуе для Kubernetes і Node.js.
Централізавана автарызацыя. 18 чэрвеня 2026 года розробка Enterprise-Managed Authorization (EMA) стала стабільной. Яна заменяе экраны з падтверджэнням на кожны сервер на сістэму, якая керуецца данымі про ідэнтычнасьць, пры чым Anthropic, Microsoft і Okta былі сярод першых, хто ўзяў яе на вжытак.
Безстановы карэнь. Выпуск 28 ліпня 2026 года стаў найбольшым пераглядам спецыфікацыі з моменту стварэння протакола, і ён заменіў становы, прыкрэплёны да сесіі дызайн на безстановы, пабудаваны на звычным HTTP.
Гэта не толькі косметычныя змены. Кожна з іх усувае адзін конкрэтны факт, чым MCP не выкарыстоўваліся у серйозных прыкладнах, і яны маюць вялікое значэнне для тых, хто займаецца паў’язываннем сістэм як професіяю і не стварае дэманстрацый AI.
Короткая дэфініцыя
MCP — гэта адкрыты стандарт, які візначае, як прыкладная програма AI, напрыклад агент на базе LLM, знаходзіць і запускае зовнішнія інструменты, чытае зовнішнія рэсурсы і адмаўляецца кантэкстам з сістэмамі паza межамі самага мадэлю. Одна ўніфікованая інтарфейсная плошча заменяе неабходнасць стварэння індывідуальных рашэнняў для кожнага крыніцы дадзеных.
Простая парадыгма: MCP выпалюе тую жоўсткую ролю ў з’яўленні звязку межа AI і сістэмай, якую раней выпалюеў REST і OpenAPI межа аплікацыямі. Інтэграваныя сістэмы застаюцца такімі, якія ўжо ёсць. Стандартызуецца толькі кантракт межа кліентам AI і тым, што працюе пад керуваннем сервера MCP – гэта можа быць інструмент для обработкі заявок, CMDB, платформа для монітарынгу або внутраняя база дадзеных.
Змена 1: больш няма сесый
У першыя два гады MCP праз HTTP працаваў падобна да багато рэальнага часу протакалаў. Кліент падключаліся, завершаў процедуру ініцыялізацыі і атрымоўваў ID сесый, які кожны наступны запіт быў змушаны включаць. Сесыя прыкрэпляла кліента да таго самога экземпляра сервера, які ёю стварыў. Кожны, хто вжываў службу WebSocket за балансіром навантажэння, знае якія ў гэтым ёсць проблемы. Для расшырэння было неабходна вікорыстоўваць механізмы прыкрэплення запытаў да конкрэтнага сервера, спяльны хранілішча сесый або шлюз, які аналізаваў трафік, каб знайсці той екземпляр сервера, які трэба ўтрымваў з’яўленне звязку.
Спефікацыя з датой 2026-07-28 усунула ўсё гэта. Не існуець процедуры ініцыялізаціі і падтверджэння ініцыялізаціі, а таксама немае заголовка Mcp-Session-Id. У замен кожны запіт несе сваю версію протаколу, ідэнтыфікатор кліента і яго можлівасці. У рэзультаце будзь-якая інстанцыя сервера можа адпаведзець на будзь-які запіт, таму «лепкія» сесіі і спальні сховышы сесій больш не ўскладнююць працу протакола. Кластэры без сервера, з калькамі інстанцый і маршрутызацыя на краю працуюць так сама, як і з звычнымі HTTP API, таму што структурна MCP стала самэй такой сістэмай.
Без сесій протакола аплікацыі не становяцца безстановымі. Калі сервер даскледзеў памятаць што-небудзь між вызывамі, напрыклад, працэс экспорту чыясьць длігую задачу на выправленне, ён следуе старым практыкам REST: ён стварае явны кантролер, а кліент перадае яго знову як звычны аргумент наступнай раз. Інжынеры, якія знаюцься на пагінацыі і канцах для статусу задач, яго адгукнуць, і гэта ўважлівы выбар, які падходзіць для балансэраў навантажэння, а не проста патч.
У гэтай версіі была паўжыннейшаць абарону навакол новага фармата. Кліенты должны пераканацца ў абэцэнцы выдавача праз адпаведныя адпаведзі, што запобегае крадзеўству сесій па мэтлу перэнаправлення ў сетках з кальколькам сервераў. Яны таксама должны зазначыць, для каго саме сервера прызначаны токен, чым закрываецца слабыя месцы ў сістэме дэлегавання, якія каманды абароны адзначалі як сэрьёзную апасцерогу ў сцэнарыях з кальколькам аб’ектаў. Кроме таго, MCP цяпер упершыню мае формальную політыку знявання падтрымкі, таму змены палягаюць на рэальным цыкле жыцця продукту, а не ў спрэчных, адзінаковых дзеяннях.
Змена 2: адзынкі, карыстаецца якімі керуе выдавач аб’ектаў
Другая змяна стосуецца не столь кранічна транспараты, як радшэ ўседзённых працоў пад час размешчэння агентав у всій кампаніі. Па падходзе першага паколення автарызаціі кожны працавальнік мусеў самастаятэльна выкарыстоваць крок схвалення OAuth для кожнага сервера MCP, які выкарыстоўваў яго кліент AI. Калі ў кампаніі сто чалавек і шэсць-семь внутраніх інструментаў, працэс адключэння новых працавальнікаў перастае быць масштабаваным. Команды з абеспекі таксама трапляюцца без центральнага адгледу, хто падключаны да чаго, і не існуе простаг спосабу адміністрування даступу, калі хтось пераходзіць на іншую паслявыборчую позіцыю або кідае компанію.
EMA перакладае рашэння пра автарызацію клячу кампаніі — прадавальніку ідэнтычнасця. Адміністратар адначасова, у IdP, выбірае, якія серверы MCP можа выкарыстоўваць група працавальнікаў. Пазней даступ сам апыляецца першы раз, калі чалавек заходзіць у сістэму праз падтрымваны кліент, без запітоў на схвалення і без дадатковай наладкі.
Okta была першай асяроддзя прадаўцоў аідэнтычнасці, якая падтрымала гэта рашэння, выкорыстоўваючы як аднойчыну свой продукт Cross App Access. Пашырэнне створана на аснове спецыфікацыі Identity Assertion JWT Authorization Grant, якая ўзьмлена з адкрытай спецыфікацыі IETF і не ўласная толькі для Anthropic. Anthropic інтэгравала яе ў Claude, Claude Code і Cowork праз спяльны шар MCP, тады як Microsoft падтрымку будавала безпасова ў Visual Studio Code. Серверы, якія вэсна падтрымліваюць гэта рашэння, включаюць Asana, Atlassian, Canva, Figma, Granola, Linear і Supabase, і гэты спіс продовжвае растаць.
Прадаўцу аідэнтычнасці завершаецца сваю ролю пасля таго, як ён выдае разрэшэнне. Ён не ўключаецца ніяк у самы вызов інструмента, і гэты факт мае значэнне пад час аналізу безпекі: прадаўцы аідэнтычнасці не працюе як проксі для кожнага потоку дадзэнняў між штучным інтэлектам і сістэмай, а толькі вяршыць рашэнне, хто будзе мець аўтэнтыфікацыйныя даны. Паколькі доступ централізаваны, так сама ўсуненне праваў доступу. Абмежэнне адзначкі чалавека, які пакідае арганізацію, адразу ж зупіняе ўсія серверы, якія з’яўляюцца ў зв’язку з EMA, таму нікому не трэба вручную адменаваць семь разных інтэграцый.
Механізм аднароднага входу для пакета SaaS компаніі працюе аднойчы, таму ён здаецца знайомым, і гэта робіцца намерна. Командам з безпекі не трэба ствараць новую модэль керавання для агентаў — яны проста распрастраńваюць тую, якая ужо існуе.
Што гэта значыць для команд, якія вікорыстоўваюць спецыяльныя рашэнні
Большынства команд, займаюцыхся інтэграцыяй і платформамі, не чакалі, пакуль MCP вырастэ. Калі іх прасілі дазволіць внутрашням AI-памагчыку чытаць даны з Jira, падаць запісі ў Slack або выконваць запыты да інструмента манітарынгу, яны пісалі свой сяброўскі код: спецыяльны кэйс для кожнага API, самастраўлены працэс аўтэнтыфікаціі і ручнае кераванне сесіямі, таму што стандартных рашэнняў не існавало. Такія рашэнняя працавалі. Але кожны новы інструмент стаў окрэмым, аўтэнтыфікацыя прадумвалася занова для кожной сістэмы, і такі падход перастаў работаць, калі другая команда пажадала той самыя можлівасці.
Няўзростаючая зрэласць стварыла проблемы трохіма спосабамі:
- Менш ручна пісанага коду для кожнай інтэграцыі. Стабільны, безстановы транспорт на базе звычайнага HTTP дазволяе командам перастаць пісаць свой код для керавання з’ѐеднаннямі і працаваць з серверам MCP як з будзь-якім REST API, які знаходзіцца за API-гейтвэем.
Сама работа з інтэграцыяй не знікае. Пераклад дадзейна між схемай тыкетаў і схемай манітаравання, а таксама трансформацыя на рэвэле поляў, усуненне дуплікацый і бізнес-логіка, якая дзейсніцца між сістэмамі, як і раней, выкалічвае справжнія інжынерныя зусілля, незалежна ад таго, які протакол выкарыстоўваецца для перадачы запыту. Зменшаюцца толькі супутнія элементы: транспорт, карэткаванне сесый і працэс аўтэнтыфікацыі. Гэта значна зменшае колькасць незначных зусібоў, але не ўсю працу.
Старая історыя з новай абліковкай
Якшто застаўіць пазаду аспекты AI, то гэта ўжо знайома сітуацыя. Прыблізна два дзесяткі гадоў падпрыемства будуць ствараць і купляць платформы для інтэграцыі, каб рашыць проблемы з’яўленняя API-з’яўленняя: стандартызаваная аўтэнтыфікацыя, централізаванае карэткаванне і трансформацыя дадзейна, вялічыню транзакцый, якая расце без неабходнасці пісаць спецыяльны код для кожнай новай пары сістэм, а таксама месца, дзе каманды з безпекі можу бачыць і кантролаваць, што з’яўленняеся ў сітцы.
MCP, здаецца, праходзіць па той самы прынцып дысцыпліны для з’яўлення звязкаў межа AI-агентамі, толькі шырэй. Безстановы ядро на звычным HTTP дазволяе серверу MCP выглядаць і масштабавацца як будзь-якая служба backend. Автарызацыя, якая керуецца IdP, прыводзіць да таго, што наданне і аўдыт даступу да AI-інструментаў стае звычной часткай кантролю даступу ў падпрыемствах. А нейтральнае кераванне пад эгідай Linux Foundation робіць адпраўку гэтага протаколу схожай на выбір Kubernetes, а не на выбір плану дзеяння якой-небудзь адной кампаніі.
Для команд з інтэграцыі урок заключаецца не ў тым, што агентамі патрэбны абсалютна новыя інструкцыі. Методы, якія ужо выкарыстоўваюцца для надзеяного, безпечнага і масштабаванага з’яўлення звязкаў межа сістэмамі, цяпер можна застосавляць і да агентаў. Слой протаколу стае часткай інфраструктуры, яку люды ужо розумеюць, а тое, што выдзеляе команды, пераходзіць на вышэйшы роўень — у картаванне дадзеных, адпраўку правілаў керавання і калектываў змян у всіх сістэмах, што завжды было найцяжэйшай часткай.