MCP сталее: што прадакшн-камандам трэба запланаваць пад новую спецыфікацыю
Як рэдакцыя Model Context Protocol ад 2026-07-28 мяняе маштабаванне, Tasks, аўтарызацыю і кэшаванне і як бяспечна, па этапах, перавесці існы сервер.
Крыніцы: **MCP Grows Up: Six Changes Production Teams Need to Plan For**
Рэвізія, якая ў большай меры за простае апдэйтаванне
За інформацыяй у аанунсе выпуску праекту, Model Context Protocol практычна апдэйтаваўся найбольш за час свайго стварэння з 28 ліпня 2026 года. У новай версіі нехтаеся сэсіі протаколу, формалізуюцься розшырэння, дадаецца можлівасць асінхронной працы, паўжэсткаваецца правілле автарызаціі, а таксама даўаецца чыткая політыка поступовага зняцья старых функцый. Кандыдатскія версіі былі заморожаны з 21 мая, што дало адпаведальным за SDK, распрацоўшчыкам кліентаў і аператарам сервераў прыблізна дзесяць тыдзён на тэставанне новай структуры.
У сукупнасці готовы дакумент уключае безстановы ядро, можлівасць адправкі калькі запытоў, маршрутызацыю па заголовкам, функцыі аднаходжэння і кэшавання рэзультатаў, фрэймворк для розшырэнняў, заданні, MCP Apps, строгейшыя правілле автарызаціі, а таксама надзеяны працэс поступовага зняцья старых функцый.
„Безстановы MCP“ — гарны загалоў, але спіс змян ёсць дыявольскі дзейны. За ім хаваецца некалькі значных змян. Рэзультаты абтрымуюць поле resultType. Стрэм HTTP GET быў адмовлен. subscriptions/listen заменяе старыя способы падпісаў. Стрэмы SSE тыячуяць возз'яджанне праз Last-Event-ID. Рэзультаты спісаў і рэсурсаў зобав'язаны мець падказкі пра кэш. Схемы інструментаў могу выкарыстоўваць весь JSON Schema 2020-12. Нарэшце, калі рэсурс не знайдзецца, тады вяртаецца стандартны код JSON-RPC -32602, тады калі раней вяртаўся -32002.
Спрыяваць гэтаму як „падняць залежнасці і перыявдзяць“ было бы памылкай. Цэлая архітэктура пераходзіць на новы стан.
1. Безстановы пратакол не робіць аплікацыю безстановай
У пакуях парадней версіі кантэкст ствараўся за дапамою процэсу initialize/initialized. Для аддалёных HTTP-сервераў сервер таксама могаў выдаваць Mcp-Session-Id, які кліент відтвараў у наступных запітах. Гэта прыяўляла кліента да адной сесіі сервера, і пад час рэальных развёрткаў часта выкарыстоўвалася таксамаўка з прыкрэпленнем кліента да сесіі на балансэры навантажэння, спяльны хранальнік сесій або ўжо ўжо гэтыя два элементы.
У 2026-07-28 процэс абмены данымі і протакольная сесія знікаюць. Кожны запіт несе ў сабе версію протакола, можлівасці кліента і неабавязковы ідэнтыфікатор кліента ў роўні _meta. Серверы должны рэалізаваць функцыю server/discover, хоця кліенты не павінны вызываць яе ў кожнай операцыі. Кліент можа заместа таго адправіць свяю праграмаваную версію і праказаць спробу, калі будзе падана памылка UnsupportedProtocolVersionError.
Праз Streamable HTTP тэкушчы канцэкст несе метаданы такія:
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Тая ж самая версія, метод і назва таксама прыказаны ў тэле JSON-RPC. Тэле застаецца автантыфікаваным, і серверы должны адхіліцаваць будзь-яе несасвападанне между заголовкамі і тэлом. Гэта не дазволяе шлюзу затвердзіць або направіць адну операцыю, калі сервер выкананае іншую.
„Без стану“ не значыць „нічога не зберагчыць“
Спефікацыя не пазбавляе прыкладнага програмы стану; яна проста не дазволяе яго хаваць. Калі серверу патрэбна працёздатнасць з аднаго вызову на іншы, яму следуе стварыць ідэнтыфікатор домэны, напрыклад workspace_id, browser_id, basket_id, analysis_run_id або deployment_id. Кліент або модэль пасля таго прадае яго як звычны аргумент інструмента ў наступных вызовах:
create_workspace()
→ { "workspace_id": "ws_7f3..." }
add_file(workspace_id="ws_7f3...", ...)
→ ...
run_analysis(workspace_id="ws_7f3...")
→ ...
Гэта чыстэйшы варыянт, чым скрыты статус транспортавання, алі ён паставляе дапрацоўкі новыя задачы. Яго трэба выкарыстоўваць для пераканання ў правах на власнасць, ізоляцыі корыстувачаў, кантролю тэрмінаў дзеяння, правіл зберагчэння дадзеных, автарызаціі і захавання ад спробы ўгадваўкі аб павторнага выканання операцый. Пастаянныя рабочыя пралэты можаць яшчэ патрабаваць базы дадзеных аб распадзеленага кэшу, а дзеянні, якія выкананыя дзяўно, за сваёй прыродай патрабуюць надзеянага зберагчэння. Інфраструктура можа быць безстатусной, тады калі сам продукт застаецца з статусам.
2. Дзе безстатуснасць дэйсна ўзнагароджваецца
Простая горызонтальная масштабаванне
Калі запчытаець мае свой сабе кантэкст, сервер можа знаходзіцца за стандартным раунд-робінным балансавальнікам навантажэння. У Kubernetes зазвычай дастаткова стандартная Deployment і Service, без анотацый прыналежнасці сесіям і без StatefulSet, які бы спецыяльна кераваў сесіямі MCP. Яшчэ большыя прынады дае автаскалінг: новы пад не павінен перзаснаваць протакольныя сесіі перад тым, як пачне прымаць трафік, а пад, які заменяецца пад час роляйнговай дыстансіі, не заставляе кліентоў застраць у недзейнаючай сесіі.
Ёсць адна прычына для аберагання. Якім бы ні быў сервер, які керуе аплікацыяй чыста задачамі, гэтыя об’екты застаюцца ў зовнішнім стойкім хранільніку, калі ў іх ёсць патрэба перазстаць пасля загіну процэса чыста пада.
Маршрутызацыя і правілы ў шлюзе
Пакалькі Mcp-Method і Mcp-Name ўжо ў фармаце звычных заголовкаў, таму шлюз можа кераваць трафікам, ведаць кантыент і выкананыя правілы, не павінаваючыся парсаваць тэла пакета JSON. У сервісе з калькуляцыяй па корыстувачах гэта дазволяе ствараць адзінаковыя квоты для tools/list, дорогіх інструментаў пошуку, інструментаў развяртання і будзь-каго іншага, што можа завадзіць:
tools/list → high request allowance
tools/call + search → standard allowance
tools/call + deploy_prod → lower rate limit and stronger policy
resources/read → data-volume quota
Шлюз таксама не павінен чытаць clientInfo як доказ таго, хто выклікае. Гэта ячэйка ўказваецца сама і існуе для адзірвання, налагоджэння і логавання. Тое, каму належыць корыстнік, павінна быць выявлена з паверыжанага токена або іншага надзеянага джэрага.
Кэшаванне
Адпаведныя на запыты resources/read, resources/templates/list, resources/list, prompts/list, tools/list і server/discover адпаведныя рэспансы маюць две новыя ячэйкі – ttlMs і cacheScope. Першая ўказвае тэрмін свежасці даных, а не інтэрвал апыткаў. Другая паказвае, чы рэзультат ёсць публічным чы прыватным. Усе, што зміняецца залежна ад корыстніка, тэнанта, дыялекта чы праваў, не павінна адносіцца да спільных публічных даных, а паведамленні пра змяны можу зробіць нэфармацыйным рэзультат, які інакш бы заставаўся свежым.
Кэшаванне скасоўвае павтаральныя запыты к каталогу інструментаў і стабілізуе вхідныя даны для модэляў. Неправы выбар дыяпазону таксама стварае новы клас багоў, якія стосуюцца правільнасці і прыватнасці.
Візуабільнасць
У спецыфікацыях W3C опісваецца распространенне кантэксту трэйсу праз ключы _meta traceparent, tracestate і baggage. Хост, кліент MCP, гейтвей, сервер і службы, якія працуюць пасля, тады маюць аднойчы спосаб для супарабоцавання вызоў інструментаў на всім шляху выканання. Кантэкст трэйсу спрыяе супарабоцаванню, але ён не ўтварае механізма автарызаціі чы гарантыі цэліснасці, і чулыя даны, токены, неапранутыя запыты і персональная інфармацыя не магуць знаходзіцца ў роздзеле baggage.
3. Расшырэнні стаюць канцэпцыяю першага класу
Кожныя расшырэнні цяпер маюць ідэнтыфікатор, правілы перагавораў, назначаных адпаведальных за ўтрыманне, сае рэпазітарыю і сае цыкл выдання. Кліенты адзначаюць расшырэнні, якімі яны керуюць, у характэрыстыках, якія надаюцься з кожным запітам, тады як серверы анунцююць свае расшырэнні праз server/discover. Расшырэнні набуваюць чыннасці толькі тады, калі обе стороны яго падтрымляюць; калі у партнера яго няма, рэалізацыя павінна вернуцца да базовага поведэння або адпаведзець з належным адзінкам.
Гэта вялікі крок у развіцці пратаколу, адколі функцыі больш не чакаюць на выданне цэлага ядра. Гэта таксама стварае матрыцу сумеснасці. Сервер не можа прыпускаць, што кожны хост падтрымлівае Tasks, MCP Apps, Enterprise-Managed Authorization чыя-небудзь будучыя расшырэнні, таму код для працы ў працэсе вырабоцтва павінен матыць чыстаяя альтэрнатыўнае рашэнні:
- Інструмент, які падрэбнае задачы, таксама прысвячае сінхронны маршрут кліентам, які не адказваюць задачамі, або вяртае чыстую памятку пра недаступную можлівасць.
- Інструмент, падтрымваны MCP App, вяртае корыстны структураваны або тэкстовы кантэнт, калі хост не можа адразыць свой інтэрфейс.
- Автарызацыя для падпрыемства застаўляецца толькі там, дзе дазволяе правіла арганізацыі.
- Поле, спецыфічныя для расшырэння, ніколі не падаюць да кліента, які не дагаворыўся пра іх.
Расшырэння слабяць звязок з основным стандартам і падвышаюць рызык фрагментацыі экасістэмы.
4. Задачы робяць інструменты з дзейнамым выконаннем стойкімі
Заданні перахоцца з экспэрыментальнага ядра ў офіцыйны пашырэнне io.modelcontextprotocol/tasks. Калі кліент паведамляе, што падтрымлівае заданні, сервер можа адпаведаць звычайной операцыяй, у якой замест апошньяго рэзультата выкорыстоўваецца ідэнтыфікатор заданні. Пасля чаго кліент выкарыстоўвае tasks/get для чытання тэкушчага стану, tasks/update для адправкі запрошаных дадзеных і tasks/cancel для запіту на анулювання.
Заданні пераходзіць праз станы working, input_required, completed, failed і cancelled. Сервер павінен захаваць заданні прычымо да таго, калі вярнуе яго ідэнтыфікатор. Анулюванне ёсць саўместным працэсам, таму падтверджэнне запіту не гарантуе, што адпаведныя дзеянні зупіняцца негайна.
Прыроднымі кандыдатамі ў такія раштрынгі ёсць наборы тэстаў, пайплайны будовы, генераванне коду, размешчэнне ў воблаку, імпорт дадзэнняў, апрацоўка дакументаў, крокі, якія чакаюць на людзкую апрацоўку, пакетныя заданні і простыя абгорткі над якімі-небудзь зовнішнімі API заданняў. Насамперад, гэта не сама асінхронная екзекуцыя, а можлівасць вярнуцца да працы: кліент можа перыякшаць, пачаць занова і продаваць паллінгі, выкарыстоўваючы той самы ID задання.
Што павінен дадаць сервер для працы
Для заданняў патрэбна гораздка большая чыстка, чым проста фонавая ніт:
- надзеяны рэпазітарый заданняў
- перакананне ў правах кожны раз, калі вызываюцца
tasks/get,tasks/updateабоtasks/cancel - ізоляцыя власніка і корыстніка
- перакананне станоў заданняў
- зберагчэнне рэзультатаў і адзінакоў
- яўнае прыменэнне TTL і чыстка
- ліміты на частоту паллінгаў
- перадача інформацыі пра анулюванне
Спрыяйце ID задачы як ідэнтыфікатору рэсурса, а не секрэту. Храненне ID ніколі не павінна быць достатнім для автарызаціі чаго-небудзь.
5. Багатыя запыты з кількома раунд-трыпамі заменяюць запыты, ініціяваны серверам
Сервер без стану не можа раслычвацца на стойкі двухвекторны звязак, каб у будзь-вым часе задаць кліенту запыт. У такім случае выкорыстоўваюцца багатыя запыты з кількома раунд-трыпамі (MRTR). Калі серверу патрэбна падтверджэнч, адпаведныя даны, прыклады аб іншыя даны, якія дае кліент, ён вяртае InputRequiredResult. Кліент збірае этыя даны і прабуе выконаць первісную операцыю з inputResponses і, калі ёсць, з requestState.
Возьмімо дэструктыўны інструмент:
delete_resources(resource_ids=[...])
У зяместа таго, каб адкрыцца запытка адварснага перадачы дадзенага стрыму, сервер адпавядае:
input_required:
"Confirm deletion of 53 resources"
Кліент атрымле падтверджэнне і павтарае первыя вызов. Павтарэнне ўсёрахована сама по сабе, таму гэта працуе ў разных экземплярах, але гэта таксама значыць, што серверы павінны быць спраектаваны для павтарэння.
Правіла для прыменення MRTR у працоўнай асяроддзя
- Не выконвуйце незворачныя дзеянні, пакуль не будзе атрымана ўсія неабходныя даны.
- Зробіце павтарэнні ідэмпатнымі.
- Праўяжыце
requestStateда конкрэтнай операцыі і да таго, хто яе запускае. - Анулюйце стары статус запіту.
- Адхіліце адпаведзі, якія аднасоўваюцца да ключоў, якіх сервер ніколі не прасіў або якія ён вялікі ўжо атрымаў.
- Установіце меры для колькісці дазволеных павтарэнняў, каб не ствараліся ціклы.
- Знову разрэшайце адбыцься операцыю пад час кожнага павтарэння.
- Ніколі не прыпускайце, што павтарэнне адбудзецца на там самым экземплярэ.
Калі працэс выканання задач ёсць чутлівым, нехай requestState будзе або незрозумелым аддытывальным ідэнтыфікатаром, калі рэальныя даныя зберагаюцца на серверэ, або значэннем, якое несе код аўтэнтыфікацыі паведамлення, ў рэзультаце чаго будзе можна выявіць парадукты.
6. Аплікацыі MCP зміняюць продукт, а не толькі протакол
Аплікацыі MCP дазваляюць серверу прыяўзаць інструмент да інтэрактыўнага HTML-інтэрфейсу. Сумесныя хосты адрасаваюць яго ўнутрь iframe з захістам. Аплікацыя ведае пераказы з хостам праз JSON-RPC за дапамогою postMessage, а хост кантролюе, якія можнацціны і інструменты можа выкарыстоўваць аплікацыя. Гэта дазваляе ствараць формы, панелі керування, дыялогавыя прызначэнні для парадзакання, праграмы для перагляду медыя, канфігураторы развяртання, экраны для сортавання і іншыя элементы, якія трудна выразіць толькі за дапамогою тэксту.
Для стартапа гэта можа змяніць эканоміку MVP: інтэрактыўны працэс ведзення дыялогу без падмогі окалічнай аплікацыі і шара інтэграцыі. Аднак інжынерыя фронтэнду не знікае. Команды яшчэ адпавядаюць за дызайн інтэрфейса, кераванне станамі, налаштаванне CSP, код, які работае ў сэндбоксе, перакананне вхідных дадзеных, выкананне пераговораў з хостамі, безпечную обработку вызоў інструментаў, тэставанне сумаспадобнасці на розных кліентах і альтэрнатыўны варыянт для хостаў без падтрымкі Аплікацый. Паколькі Аплікацыі ўжо ёсць необав’язковым расшырэнням, падтрымка хостаў варыюецца, таму сервер павінен вярнаваць значымы структураваны контэнт нават тады, калі відобразжэння немагчыма.
7. Автарызацыя стае строгей і складней
За правіламі автарызацыі HTTP, захаваны сервер MCP выступае як сервер рэсурса OAuth, а кліент MCP — як кліент OAuth. Шырокаверсія запоўнюецца выбранымі элементамі стандарта OAuth 2.1 і суседніх стандартаў. Серверы должны публікаваць метаданы захаваных рэсурсаў, каб кліенты моглі іх знайсці, і прыймаюцца метаданы як сервераў автарызацыі OAuth, так і OpenID Connect. PKCE ёсць обавязковым, так сама як і індыкаторы рэсурсаў у запітах на автарызацыю і токены, а перакананні ў выдавцы стаюць стрэлкавымі. Найважлівейшыя правілы:
- Кліенты адправляюць параметр
resource, у якім указваецца павінны сервер MCP. - Сервер перакананаецца, што токен, які ён атрымляе, быў выданы для яго сэрвісаў-працоўнікаў.
- Серверы автарызацыі должны мець паказаннік
iss, а кліенты перакананаецца ў выдавцы, калі гэты паказаннік ўсё-такі ўказаны, пры перэкладзе коду автарызацыі.
Authorization, а не ў строе запыту.S256.Індыкатары рэсурсаў обмежваюць круг аб’ектаў, якія можа абрабатваць токен. Іх не трэба аднаць з прыязначэнням токенаў за дапамогою крыптаграфіі.
Корпаратыўная ідэнтычнасць — гэта аднае пытанне
Автарызацыя MCP пакрывае стандартны працэс OAuth, калі правыя перадаюцца ад корыстніка. Цэнтралізаваная політыка доступу для корпаратыў выкалікаецца з неабяжнага расшырэння Enterprise-Managed Authorization, якое дазволяе прадаўцу аідэнтыкацыі арганізацыі кантролюваць доступ да сервераў MCP, уключаючы працэсы прыўязкі, ад’язвы, умовны доступ і ўжыткі правілаў. Кліент, сістэма автарызацыі сервера і сераўскае аідэнтыфікацыйнае сэрвіса ўсе павінны яе падтрымліваць. Для анаізу безпекі архітэктура дзеліцца так:
Core authorization
OAuth flow
issuer validation
resource/audience validation
scopes and step-up
Protected Resource Metadata
Optional enterprise extension
corporate IdP policy
SSO
centralized approval and revocation
identity-assertion exchange
У спефікацыі чыткая апісаньне архітэктуры, але гэта не робіць працэўванне з OAuth простым. Збір метаданых кліента стварае проблемы, зв’язаныя з SSRF і політыкай доверы. Токены і крэдытныя даны для апавержэння патрэбуюць безпечнага зберагача. У разе вікорыстання калькулятаў з калькуючымі выдавачамі патрэбны аддзельная рэгістрацыя і стан токенаў. Метаданы, URI для перыяслення, дыяпазоны і канонічныя ідэнтыфікаторы рэсурсаў должны застацца адпаведнымі.
8. Адпраўная політыка зняць з вжытку
Функцыі зараз маюць тры статусы: Актыўныя, Знятыя з вжытку і Удаленыя. Канэчная функцыя зазвычай застаецца у статусе «Знята з вжытку» прынаймні дванаццац месцаў, прычым для ўдалення яе патрэбны задокументаваны шлях міграцыі плюс запіс у цэнтральным рэестры. Удаленне можа адбыцца пазней, чым планавалося. Для актуальных бяспековых рызыкаў існуе прышвырнуты шлях, але нават у такім случае зазвычай патрэбны прынаймні 90 дзён.
HTTP+SSE, як старэйшы спосаб перадачы дадзейнаў, мае свае правілы пераходу і можа быць адключаны ранейш, чым іншыя няўжыткавыя функцыі. Усі, хто яшчэ выкарыстоўвае яго, должны спланаваць пераход на Streamable HTTP. Таксама важна памятаць, што правіла па дванаццац месцаў стосуюцца толькі функцый пратаколу; API SDK маюць аднародныя правілы падтрымкі і графікі, якія можуць разлічвацца.
Як гэта выглядае ў рэальных прыкладах выкарыстоўвання
Внутрашніе інструменты падпрыемства
Уявіце сабе компанію, якая публікуе внутрашнія знанні, дадзеныя з Jira, Confluence, каталогі службаў і інструкцыі праз MCP. За старым падходам да удаленай разгрупаванні могла бы выкарыстоўвацца прыязнь сесій, калі адны работнік завжды падключаліся да той самой інстанцыі. З 2026-07-28 ранг MCP можа стаць наборам безстановых контэйнераў за звычайным Kubernetes Service і балансірам навантажэння:
MCP host
↓
API gateway / authorization
↓
Stateless MCP Deployment
├─ Knowledge connector
├─ Jira connector
├─ Confluence connector
└─ Service catalog connector
↓
OpenTelemetry backend
Кождадзённая автарызацыя можа выконвацца па прынцыпах базовага OAuth, а пашырэнне Enterprise-Managed Authorization прымае удзел тады, калі патрабуецца цэнтралізаваная політыка IdP. Галоўным абмежэннем ёсць тое, скількі кліентаў насправды падтрымляюць гэта пашырэнне.
Multi-tenant SaaS
Якшо продавець інструментаў для распрацоўшчыкаў продае MCP як платную API для сотняў або тыяў корыстувачаў, безстановасць дазволяе простае маршрутызаванне між зонамі, а шлюз можа відлічвацы выкарыстоўвання па Mcp-Method і Mcp-Name, пры чым інформацыя пра корыстувача бераецца з паверыжаных данаеў автарызаціі, а не з імен аб заголовкаў, якія надае кліент. Хорашая рэалізацыя мяжувала б обработкі і задачы па корыстувачах, пазначала бы каталогі, прызначаныя для конкрэтных корыстувачаў, як cacheScope: „private“, пораўнювала б кожны заголовак з тэлам, обмежвала бы выкарыстоўвання дорогіх інструментаў ў ўстановленых межах, блакавала бы пошук задач між корыстувачамі і не залішала б рашэнняў пра автарызацію ў мемарыі локальнага процэса. Маршрутызаванне, залежнае ад сесіі, ўжо ня існуе; ізоляцыя корыстувачаў застаецца вашай адпаведальнасцю.
Памочнікі з кодавання на базе AI
Сервер для кодавання можа выклікваць run_tests, build_project, generate_patch або deploy_preview як задачы. Ён адразу вяртае ID задачы, ставяе працу у чэргу і дазваляе агенту продаваць чытанне коду або анаіз іншай проблемы. Кліент пераказвае запіты за інтэрвалам, практыкуемым серверам, і калі для якога-небудзь крока патрэбна згода, задача пераходзіць у статус input_required, а кліент адпавядае пакетам tasks/update. Працэйны рэзультат — стойкасць пад час перачысці рэдактара або перыванняя з’ёднання. Цена — справжня сістэма задач: стойкая чэрга, арэнда працоўнікаў, збераганыя рэзультаты, можлівасць анулявання, ізольаваныя працоўныя прасторы і політыка зберагання дадзеных.
Медычныя і фінансавыя службы
Паказатэлі рычоў і перакананні ў аудыэнцыі зменшаюць верыгоднасць таго, што токен, выданы для аднаго сервера MCP, будзе выкарыстоўвацца ў іншым, а атэстацыя выдавача зніжае рызык атак на асаблівасці за дапамою OAuth. W3C Trace Context дазволяе сочыць за запытам па шляху MCP і за службамі, якія знаходзяцца за ям. Разам яны даюць камандам з абеспекі і са адпаведнасцю болей чысты набор мер кантролю, хоць і не ўжо готавую адпаведнасць. Вам яшчэ патрэбны автарызацыя ўнутрь прыемлівача, незменныя запісы аўдыту, правілы зберагчэння і выдалення дадзэнняў, класыфікацыя дадзэнняў, карыстоўванне згоды, калектываванне канфідэнцыйных ключоў, логі ад адміністратыўнага доступу, працэс рашэння інцыдэтаў і мінімальны об’ём дадзэнняў для трэйсінгу. Трэйсінг спрыяе дыягназе; ён не павінен быць ўжо ўсім запісам аўдыту.
Стартап, створаны для AI
Разглянем невялы каманду, якая стварае помачнік для інфраструктуры. За дапамогай MCP Apps яна можа выдаваць форму плану развяртання, панель кантролю за оцэнкай выкаленняў, дыялог для затверджэння, манітар для стэпеня развяртання і механізм для анулювання. Хост забезпечвае кантэкст для дыялогу, сервер — інструменты і рэсурсы UI, а прыкладнэць выкарыстоўвае гэтыя інструменты праз мост, які кантролюе хост. Спачатку окалічная панель кантролю можа стаць непатрэбной, але дызайн API, автарызацыя, тэставанне UI, доступнасць, правіла CSP і альтэрнатыўныя варыянты сумеснасці застаюцца неабходнымі.
Дзе новыя спецыфікацыі дадаюць сложнасці
Стан быў перамешчаны, але не знік. Стан з’яўлення стае явным домэнным станам, што ўлучшае архітэктуру і вымагае рэштыльнага дызайну механізмаў кантролю, зберагчыцтва, тэрміну давальнечы, власнасці і ідэмпотэнцыі.
Апгрэйд SDK і адопцыя пратакту — гэта два разныя праекты. Калі ўжо была выпускана кандыдатская версія, адпаведальныя за SDK практыкавалі, каб команды не адночасна апгрэйдавалі яго на новую версію і не перэйшлі на новы пратакт, і гэтыя рэкамендацыі застаюцца актуальнымі. Возьмемо, прыклад, TypeScript v2 SDK: ён раздзеляе адзін пакет на околічныя пакеты для сервера і кліента, выдаецца толькі у фармаце ESM, працюе на Node.js 20+, Bun і Deno, перакананае праз бібліятэкі, сумэнныя з Standard Schema, і мае кодамод для стандартных змян з версіі v1. Python v2 таксама ўключае значныя змяны, з-поміж іншага — перайменаванне FastMCP на MCPServer. TypeScript v1 будзе прымалі правкі і абнаўленні безпекі прынеймна шасць месцаў пасля выходу v2, а Python v1 будзе прымалі крытычныя правкі і патчы безпекі. Адпаведны асторожны парадак работ:
- Апгрэдаваць SDK, захоўваючы пры гэтым пярэднюю працэсуру протакола там, дзе гэта адказвае.
- Ліквідаваць змяны у API на рэвэлю прыкладнага праграмнага забезпечэння.
- Даўаць падтрымку протакола для двух разных перыодаў.
- Працаваць з рэальнымі кліентамі і трафікам, каб пераканацца ў правільнасці.
- Поступова актывацыя сучаснай мадэлі работы без стану.
- Зняць падтрымку старых версій толькі пасля аналізу ўжыцця кліентамі.
Расшырэнні парадзейнаюць можлівасці. Інструмент не можа прыпускаць, што задачы або MCP-прыкладненні ёсць скрозь, таму команды, якія разрабатываюць продукты, патрабуюць матрыц падатныя і альтэрнатыўныя способы відображэння інфармацыі.
Павторныя спробы стаюць прычынай некорэктнасці. Павторныя спробы цяпер выступаюць унаследкі MRTR, пераговораў пра версію протакола, перыядаў у роце HTTP-адказоў, падышчаў у автарызацыі, польсінгу задач і паўтарнага падключэння. Таму кожная операцыя з парадзейнымі наследкамі вымагае чыста прапрацаванага плану ідэмпотэнцыі.
OAuth лепшае сумежнае працюе, але застаецца складным у вікорыстоўванні. У спецыфікацыі OAuth 2.1 і Документы метадаў ID кліента паказваныя як праекты, таму тыя, хто іх рэалізуе, должны следаваць як змянам MCP, так і основным стандартам.
Кэшаванне выклікае пытанні пра прыватнасць. Пазначэнне адпаведзення, якое залежыць ад автарызаціі, як публічнага, магло б адкрыць каталог аднаго карыстальніка чыя-небудзь іншага. Адпаведныя консерватывныя настройкі: выкорыстоўваць прыватны дыяпазон, як толькі рэзультат дзейсна будзе ідэнтычны для кожнаго запрошанніка.
Загальная ацэнка
MCP 2026-07-28 прыбліжае протакол да спосабу функцыонавання сучаснага вебу: запросы, якія ўзятыя самыя по сабе, чысткія версіі, звычайнае маршрутызаванне HTTP, справжняя семантыка кэша, распраўленая трэйсінг, стандартная автарызацыя і неабавязковыя можлівасці, якія развіваюцца окрэма. Праўыя выгоды — гэта не абсэнцыя стану, а абсэнцыя схованага стану протаколу.
Пашырэнне, маршрутызацыя між зонамі, вярнэнне пасля абярошчын, настаўленне правілаў шлюза і стазіроўка сістэмы становяцца значна простыяй. У якосты рэзультата выявляецца стан сесіі работы, які раней быў выкорыстоўваны для маскавання: кантролеры застосоў, ідэмпотэнцыя, дыржаўныя заданні, альтэрнатыўныя варыянты расшырэння, метаданы автарызацыі, прыватнасц кэшаў і способы павтарных спробаў.
Калі вы керуеце існуючым серверам для працы, перайшыце на новую версію паэтапна і падтрымайце обе версіі. Расследжвайце апгрэйд SDK і протакол з’ўязку як адзінаковыя крокі, абы усунуць прыпускі ўчынкі з’ўязку, зберагачыце дадзеныя, якія трэба дыяўаць дзялейна, працаваце з автарызацыяй і прабамамі паўтарэння, і толькі пасля таго, калі будзе зафіксавана рэальная адпраўка запытоў з боку кліента, можна адмовіцца ад старых способаў работы. Для абсалютна новага сервера все простае: пачніце з апрацоўшчыка запытоў без стану і з явным станам, выкарыстоўваючы Streamable HTTP і сучасную автарызацыю, дадаце OpenTelemetry, зробіце кэшаванне надзеяным і з самага пачатку запланаваце можлівасці расшырэння.
Протакол цяпер лёгкій у выкарыстоўванні, але толькі для команд, якія гатовы чытальна апісаць стан свайго прыкладнага програмнага забезпечэння, межы безпекі і спосабы рэагавання на абыякаванні.
Супаўязаныя матэрыялы
- Практычныя прыміткі: MCP 2026: Протакол вырасў – гэта ўсё, што трэба ведаць пра AI у працэсе віробніцтва — Паследоўны апіс прымітак: MCP 2026: Протакол вырасў – гэта ўсё, што трэба ведаць пра AI у працэсе віробніцтва: контракты, перакананні і шаблоны коду для команд, якія вікорыстоўваюць гэты патэрн.
- Дзесяць сервераў MCP, якія варта запусціць першыя, за прыорытэтам для распрацоўшчыкаў — Спіс сервераў MCP, якія ў першую чаргу варта встановіць для асістэнтав у кодаванні на базе AI, ад Context7 і GitHub да Postgres і іншых срэдстваў, з настройкамі встановлення і паведамленнямі пра абавесці ў чысце прав.