MCP muutus olekuta protokolliks: ettevõtete integratsioone ootab sisuline ümberehitus

01Lühidalt

• Model Context Protocoli 28. juulil 2026 avaldatud versioon eemaldas protokollitaseme seansid, kohustusliku algkäepigistuse ja Mcp-Session-Id päise.
• Iga MCP päring kannab nüüd ise versiooni-, kliendi- ja võimekusinfot, mistõttu saab tavaline koormusjaotur saata päringu ükskõik millisele serveriinstantsile.
• Uus versioon lisas mitme vooruga päringud, marsruutimiseks mõeldud HTTP-päised, vahemällu salvestatavad loendid, OAuthi tugevama kontrolli ja ametliku laienduste raamistiku.
• SDK-del põhinevad lihtsad integratsioonid võivad vajada peamiselt versiooniuuendust, kuid oma kliendi, serveri või lüüsi kirjutanud ettevõtted peavad üle vaatama seansioleku, autoriseerimise, monitooringu ja veataaste.

Model Context Protocoli ehk MCP olekuta protokolli versioon 2026-07-28 muudab põhjalikult viisi, kuidas tehisaruagendid väliste tööriistade ja andmeallikatega suhtlevad. Protokolli haldajad loobusid püsivatest protokolliseanssidest: iga päring peab nüüd sisaldama enda töötlemiseks vajalikku versiooni-, kliendi- ja võimekusinfot.

Muudatus võimaldab MCP servereid käitada tavapärase pilverakendusena, kus päringu võib vastu võtta ükskõik milline koormusjaoturi taga asuv serveriinstants. Varasem ülesehitus võis nõuda püsivat seansisidumist, jagatud seansihoidlat või lüüsi, mis oskas JSON-RPC sõnumite sisu marsruutimiseks analüüsida.

Uus spetsifikatsioon ei muuda siiski kogu MCP rakendust automaatselt olekuta süsteemiks. Kui töövoog peab ostukorvi, kinnituse, poolelioleva ülesande või muu seisundi mitme päringu vahel säilitama, tuleb seda teha rakenduse tasandil selgelt määratletud identifikaatorite ja andmehoidla abil.

Seetõttu pole 28. juuli väljalase üksnes tehniline lihtsustus. Protokollitaseme keerukust vähendades viib see osa vastutusest MCP serveri ja seda ümbritseva platvormi arendajatele. Eriti vajavad ülevaatamist autoriseerimine, kliendilt saadud metaandmete usaldamine, töövooidentifikaatorite terviklus ning HTTP-päiste ja JSON-RPC sisu omavaheline kooskõla.

02MCP olekuta protokoll eemaldab käepigistuse ja seansiidentifikaatori

Eelmise, 25. novembri 2025 spetsifikatsiooni järgi alustas klient suhtlust initialize päringuga ning server vastas muu hulgas seansiidentifikaatoriga. Järgnevad päringud kandsid Mcp-Session-Id päist, mis sidus suhtluse kindla seansiga. Versioonis 2026-07-28 on nii algne initialize ja initialized vahetus kui ka seansipäis eemaldatud.

Iga uus päring sisaldab protokolliversiooni ja kliendi võimekusi _meta väljal. Klient peaks lisama ka enda nime ja versiooni ning server peaks tagastatud tulemuse metaandmetes ennast tuvastama. Kui versioonid ei sobi, näeb spetsifikatsioon ette vea UnsupportedProtocolVersionError.

Serveri toetatud versioonide ja võimekuste eelnevaks pärimiseks lisandus server/discover. Server peab selle kaugprotseduurikutse rakendama, kuid klient ei pea seda enne iga toimingut kasutama: vajalik teave võib liikuda otse tööriistapäringuga. STDIO-transpordi puhul saab avastuspäringut kasutada ka varasema protokollipõlvkonna tuvastamiseks.

Praktiline infrastruktuurimuutus on oluline. Kui päring ei sõltu enam kindla serveri mälus olevast protokolliseansist, saab selle saata hariliku ringjaotusega ükskõik millisele eksemplarile. Serveri tõrge ei pea hävitama kogu protokolliseanssi ning liikluse kasvades saab uusi serveriinstantse lihtsamalt lisada.

Olekuta tuum ei keela rakendusliku oleku kasutamist. MCP haldajad soovitavad serveril vajaduse korral väljastada selgesõnaline viide, näiteks workflow_run_id või basket_id, mille klient saadab järgmise tööriistakutse argumendina tagasi. Erinevalt transpordikihti peidetud seansist on selline viide mudelile ja arendajale nähtav.

03Mitme vooruga päringud asendavad osa püsivast kahesuunalisest suhtlusest

Olekuta päringuvorm tekitab küsimuse, kuidas käsitleda toimingut, mis vajab töö käigus kasutaja kinnitust või puuduvat sisendit. Selleks lisab spetsifikatsioon mitme edasi-tagasi vooruga päringud ehk Multi Round-Trip Requests (MRTR).

Kui server vajab tööriistakutse lõpetamiseks täiendavat teavet, võib ta tagastada tulemuse input_required koos vastamist vajavate päringutega. Klient kogub kasutajalt või muust lubatud allikast vastused ning kordab algset väljakutset, lisades need väljale inputResponses.

Lahendus asendab varasemad serverist kliendile algatatud päringud, mida kasutati näiteks sisendi küsimiseks, mudelilt teksti genereerimise tellimiseks või failisüsteemi juurte pärimiseks. Muudatuse eesmärk on vältida olukorda, kus server peab hoidma pidevalt avatuna kahesuunalist voogu ainult selleks, et kliendilt hiljem täiendavat vastust küsida.

MRTR muudab katkestatud töö taastamise läbipaistvamaks, kuid loob ka uue usalduspiiri. Kui klient saadab serverile tagasi töövooidentifikaatori või seisundiobjekti, ei tohi server eeldada, et see on muutmata, õige kasutajaga seotud või piisav autoriseerimisotsuse tegemiseks. Akamai hinnangul võivad ennustatavad identifikaatorid ja nõrk kontroll viia teise kasutaja töövoo ülevõtmise või tenantidevahelise andmelekkeni.

04Uued päised lihtsustavad marsruutimist, kuid vajavad ranget kontrolli

Streamable HTTP päringud peavad nüüd kandma Mcp-Method ja Mcp-Name päist. Need näitavad vastavalt kutsutavat MCP meetodit ja tööriista nime, võimaldades lüüsil, veebirakenduse tulemüüril või kiirusepiirajal teha otsuseid JSON-RPC keha avamata.

Ettevõtte jaoks tähendab see, et MCP liiklusele saab rakendada tavapäraseid API-põhiseid reegleid. Näiteks võib lüüs lubada ühele agendile lugemistööriista, keelata muutmistoimingu, kehtestada kallile tööriistale eraldi päringulimiidi või saata erinevad tööriistad erinevatesse teenustesse.

Samas ei tohi lüüs ja server tõlgendada sama päringut erinevalt. Kui Mcp-Name päis nimetab ühe tööriista, kuid JSON-RPC keha teise, peab süsteem vastuolu tagasi lükkama, mitte valima ühe väärtuse sõltuvalt töötlemiskihist. Akamai toob päise ja sõnumikeha lahknevuse esile võimaliku protokollisegaduse ja turvakontrollidest möödapääsu allikana.

Tähelepanu vajab ka võimalus peegeldada tööriista argumente HTTP-päistesse. Päised läbivad koormusjaotureid, puhverservereid ja logisüsteeme ning neid säilitatakse sageli laiemalt kui päringukeha. API-võtmete, isikuandmete või muude saladuste päisesse tõstmine võib seetõttu suurendada nende nähtavust ja säilitusaega.

05Tööriistaloendid muutusid vahemällu salvestatavaks

Meetodite tools/list, prompts/list, resources/list ja resources/read vastused võivad nüüd sisaldada vahemälu eluiga tähistavat ttlMs väärtust ning cacheScope määrangut. Loendid peavad olema deterministlikus järjekorras, et sama serveriseisu korral ei muutuks vastuse sisu juhuslikult.

Vahemällu salvestamine vähendab korduvaid serveripäringuid ja aitab hoida mudelile antava tööriistakataloogi stabiilsena. See võib vähendada nii latentsust kui ka mudelipäringu sisendmahtu, eriti juhul, kui agent kasutab suurt, kuid harva muutuvat tööriistade või ressursside loendit.

Rakendaja peab siiski otsustama, millal vahemälu kehtetuks muutub. Kui kasutaja õigused, tenant, geograafiline piirkond või tellimuspakett mõjutavad nähtavaid tööriistu, ei tohi ühe kasutaja kataloogi teisele jagada. cacheScope tuleb seetõttu siduda tegeliku autoriseerimismudeliga, mitte käsitleda üksnes jõudlusparameetrina.

06OAuthi kontroll muutus rangemaks

MCP 2026-07-28 jätkab autoriseerimiskihi lähendamist tavapärastele OAuthi ja OpenID Connecti juurutustele. Autoriseerimisserver peaks tagastama RFC 9207 järgi väljaandja ehk iss parameetri ning klient peab seda enne autoriseerimiskoodi lunastamist kontrollima. Eesmärk on vähendada autoriseerimisserverite segiajamise ründe võimalust.

Veel üks suunamuutus puudutab dünaamilist kliendiregistreerimist. MCP liigub Dynamic Client Registrationi kasutamiselt kliendi metaandmete dokumentide poole, mis peaks sobima paremini olukorda, kus ettevõte haldab klientide identiteete ja lubatud ümbersuunamisaadresse keskse kontrolli all.

Uus spetsifikatsioon ei muuda aga kliendi _meta välju usaldusväärseks identiteeditõendiks. Kliendi nimi, versioon, võimekused ja muud kaasa pandud väärtused on sisendandmed, mida tuleb kontrollida sama kriitiliselt nagu tööriista argumente. Autoriseerimisotsus peab põhinema kontrollitud identiteedil ja ligipääsutõendil, mitte kliendi enda väitel.

07Tasks kolis laienduseks ja osa vanu võimalusi märgiti aegunuks

Pikaajaliste toimingute haldamiseks loodud Tasks eemaldati protokolli tuumast ning viidi ametlikku laienduste raamistikku. Sama raamistik võimaldab arendada ja versioonida valdkonnaspetsiifilisi võimalusi põhispetsifikatsioonist eraldi; ametlike laienduste hulka kuuluvad ka MCP Apps ja Enterprise Managed Authorization.

Laienduste eraldi elutsükkel annab MCP haldajatele võimaluse uusi funktsioone katsetada ilma, et iga muudatus muutuks kohe kõigi klientide ja serverite kohustuslikuks osaks. Ettevõtte integratsioon peab aga oskama tuvastada, millist laienduse versiooni teine pool toetab, ning määratlema käitumise juhuks, kui vajalik laiendus puudub.

Roots, Sampling ja Logging on märgitud aegunuks. Samuti taandub vana HTTP+SSE transpordimudel ning muutusteateid korraldatakse uue subscriptions/listen lahendusega, kus tellitud teavituste jaoks kasutatakse pikka POST-vastusvoogu. Päringuga seotud edenemis- ja logiteated liiguvad endiselt vastava päringu vastusevoos.

MCP ametlik aegumispoliitika näeb ette vähemalt 12-kuulise üleminekuakna. See ei tähenda siiski, et vana klient töötab automaatselt uue serveriga: osapooled peavad toetama sama protokollipõlvkonda või üks pool peab rakendama teadliku varumehhanismi või tõlkekihi.

08Mõju sõltub sellest, kuidas MCP integratsioon ehitati

Kõige väiksem migratsioonirisk on tõenäoliselt kohalikul STDIO-serveril, mis kasutab ametlikku SDK-d ega säilita päringute vahel varjatud olekut. Sellisel juhul võib piisata SDK uuendamisest, versiooniläbirääkimise testimisest ja seniste tööriistakutsete regressioonitestidest.

Keskmine risk puudutab kaugservereid, mis ei säilita ärilist seansiinfot, kuid kasutavad oma lüüsi, OAuthi seadistust või HTTP-transpordikihti. Need meeskonnad peavad lisama ja kontrollima uusi päiseid, edastama iga päringuga vajalikud metaandmed ning veenduma, et logid seovad ühe agenditöö eri päringud endiselt kokku.

Kõrge riskiga on lahendused, mis kasutavad Mcp-Session-Id väärtust ärilise oleku võtmena, eeldavad seansiga seotud kasutajaõigusi või hoiavad töövoogu ühe serveri mälus. Sellised süsteemid vajavad selgesõnalisi töövooviiteid, jagatud andmehoidlat, tervikluse kontrolli ja tenantide ranget eraldamist.

Oma MCP kliendi või serveri kirjutanud meeskondadel on töömaht suurem kui neil, kes kasutavad ametlikke SDK-sid. MCP juhtiv haldaja David Soria Parra ütles enne väljalaset The Registerile, et andmeedastusmehhanism ehitati sisuliselt uuesti ning oma teostuse autoritel tuleb korrektseks üleminekuks teha märkimisväärne uuendus.

09Migratsioonikontrollnimekiri ettevõttele

1. Kaardista varjatud seansiinfo

Otsi kogu integratsioonist initialize, notifications/initialized ja Mcp-Session-Id kasutust. Kontrolli eraldi, kas seansiidentifikaatoriga on seotud kasutaja, tenant, ligipääsutõend, tööriistade loend, pooleliolev töö või võrgumarsruut.

2. Vii vajalik olek selgesõnalise viite taha

Asenda protokolliseansist sõltuv äriline olek juhusliku, lühiajalise ja kasutaja identiteediga seotud töövooviitega. Server peab kontrollima viite autentsust, kehtivust, omanikku ja kasutusõigust iga päringu puhul; pelgalt kliendilt tagasi saadud väärtus pole tõend.

3. Rakenda versioonivalik ja kontrollitud tagasilangus

Määra, kas klient kutsub kõigepealt server/discover meetodit või saadab kohe eelistatud versiooniga päringu. Tagasilangus vanemale versioonile peab olema teadlik ja logitav, sest vaikne protokollivahetus võib varjata turvareeglite või funktsioonide kadumist.

4. Uuenda lüüsi- ja autoriseerimisreegleid

Lisa Mcp-Method ja Mcp-Name päiste lubatud väärtused, kontrolli nende vastavust JSON-RPC kehale ning väldi tundlike argumentide päistesse tõstmist. Autoriseerimispoliitika peaks eristama tööriistu ja toiminguid, mitte lubama kogu MCP lõpp-punkti ühe üldise reegliga.

5. Säilita jälgitavus ka ilma protokolliseansita

Protokolliseansi kadumine ei tohi lõhkuda hajusjälgimist. Iga agenditöö, tööriistakutse ja MRTR jätkupäring peab kandma jälgimis- või korrelatsiooniidentifikaatorit, mis ei anna ise ligipääsu töövoole ning mida saab kasutada OpenTelemetry jälgedes, logides ja mõõdikutes.

6. Piira pikaajaliste ülesannete ressursikasutust

Tasks-laienduse kasutamisel kehtesta kasutaja- ja tenantipõhised kvoodid, maksimaalne tööaeg, paralleelsuspiir, tühistamine ja aegumine. Odav päring ei tohi saada käivitada piiramatult kulukat taustatööd, mis jätkub ka pärast kliendi lahkumist.

7. Tee kahe protokollipõlvkonna koostoimetestid

Testida tuleb vähemalt kombinatsioone uus klient-uus server, vana klient-uus server ja uus klient-vana server. Lisaks tavapärasele eduteele tuleb kontrollida versiooniviga, serveri taaskäivitust, katkestatud MRTR voogu, aegunud viidet, vastuolulisi päiseid ja autoriseerimistõendi uuendamist.

10Mida muudatus tähendab Eesti ettevõtetele

Eesti ettevõtetele ei tekita MCP spetsifikatsiooni väljalase iseenesest uut õiguslikku kohustust. Praktiline mõju avaldub siis, kui organisatsioon kasutab tehisaruagente pilveteenuste, andmebaaside, dokumendihalduse, lähtekoodi, monitooringu või sisemiste API-dega ühendamiseks.

Olekuta tuum sobib hästi tavapärase pilve- ja mikroteenusearhitektuuriga. Seda saab hõlpsamini paigutada API-lüüsi, veebirakenduse tulemüüri, keskse identiteedihalduse ja OpenTelemetry-põhise jälgimise taha. Samal ajal peab ettevõte ise tagama, et rakenduslik olek, kasutajaõigus ja tenantide eraldamine ei sõltuks kontrollimata kliendiväljast.

Juhtide jaoks on oluline eristada SDK versiooniuuendust arhitektuurimuudatusest. Kui MCP-d kasutav toode on täielikult tarnija hallatav, võib suurem osa üleminekust jääda teenusepakkuja kanda. Oma serverite, tööriistade või identiteediliideste puhul tuleb muudatus käsitleda tavapärase API migratsioonina koos inventuuri, ohumudeli, koostoimetestide ja järkjärgulise kasutuselevõtuga.

11Kokkuvõte

MCP 2026-07-28 muudab protokolli pilvekeskkonnas lihtsamini käitatavaks: kohustuslik käepigistus ja protokolliseanss on kadunud, päringud on isekirjeldavad ning marsruutimiseks saab kasutada standardset HTTP taristut. Uus lahendus vähendab vajadust püsivate seansside, kleepuva koormusjaotuse ja jagatud transpordioleku järele.

Lihtsam protokoll ei tähenda automaatselt lihtsamat turvamudelit. Töövoo seisund, identiteet ja autoriseerimine tuleb rakenduskihis senisest nähtavamalt määratleda ning kliendi saadetud viiteid, metaandmeid ja päiseid ei tohi vaikimisi usaldada.

Järgmistel kuudel tasub jälgida ametlike SDK-de migratsioonikogemusi, vanade funktsioonide täpset eemaldamiskava ja seda, kuidas suuremad MCP kliendid protokolliversioonide vahelist ühilduvust korraldavad. Vähemalt 12-kuuline aegumisaken annab migratsiooniks aega, kuid oma teostusega ettevõtetel on mõistlik varjatud seansisõltuvused välja selgitada enne, kui vana ja uus protokollipõlvkond tootmises kokku saavad.

12Korduma kippuvad küsimused

Mis MCP 2026-07-28 versioonis kõige rohkem muutus?

MCP 2026-07-28 eemaldas protokollitaseme seansid, kohustusliku algkäepigistuse ja Mcp-Session-Id päise. Iga päring sisaldab nüüd ise protokolliversiooni ning kliendi võimekuste ja identiteedi infot.

Kas MCP server ei tohi enam olekut säilitada?

MCP server võib endiselt rakenduslikku olekut säilitada, kuid see ei ole enam peidetud protokolliseanssi. Server võib väljastada selgesõnalise töövoo- või objektiidentifikaatori, mille klient saadab järgneva tööriistakutse argumendina tagasi.

Kas olemasolevad MCP integratsioonid lähevad katki?

Olemasoleva integratsiooni ühilduvus sõltub selle teostusest ja toetatud protokolliversioonidest. Ametlikul SDK-l põhinev lihtne lahendus võib vajada peamiselt uuendamist ja testimist, kuid oma seansihalduse või transpordikihi ehitanud süsteem võib nõuda põhjalikku migratsiooni.

Mis on mitme edasi-tagasi vooruga päring?

Mitme edasi-tagasi vooruga päring võimaldab tööriistal küsida poole toimingu pealt lisainfot või kasutaja kinnitust ilma püsiva kahesuunalise seansita. Server tagastab sisendivajaduse ning klient kordab algset päringut koos kogutud vastustega.

Miks lisati Mcp-Method ja Mcp-Name päised?

Mcp-Method ja Mcp-Name võimaldavad API-lüüsil, koormusjaoturil või tulemüüril MCP liiklust marsruutida ja piirata JSON-RPC keha avamata. Server peab kontrollima, et päiste väärtused vastaksid päringukehas olevale meetodile ja tööriistanimele.

Millised on olekuta MCP peamised turvariskid?

Peamised riskid on kliendi saadetud töövooviidete võltsimine, tenantidevaheline ligipääs, kontrollimata metaandmete usaldamine ning päiste ja JSON-RPC keha vastuoluline tõlgendamine. Pikaajaliste ülesannete puhul tuleb piirata ka tööaega, paralleelsust ja ressursikasutust.

Mida peaks Eesti ettevõte enne uuendamist tegema?

Eesti ettevõte peaks kaardistama seansiidentifikaatorist sõltuva oleku, uuendama OAuthi ja lüüsi reegleid ning lisama protokolliversioonide koostoimetestid. Eraldi tuleb kontrollida, et logimine ja hajusjälgimine töötaksid ka ilma protokolliseansita.

Kui kaua vanad MCP võimalused veel töötavad?

MCP ametlik aegumispoliitika näeb aegunuks märgitud võimalustele ette vähemalt 12-kuulise üleminekuaja. Üleminekuaeg ei taga siiski automaatset ühilduvust vana kliendi ja uut protokolliversiooni kasutava serveri vahel.

13Allikad

1. Model Context Protocol, "The 2026-07-28 Specification", 28. juuli 2026. https://blog.modelcontextprotocol.io/posts/2026-07-28/
2. Model Context Protocol, "Key Changes", 28. juuli 2026. https://modelcontextprotocol.io/specification/2026-07-28/changelog
3. The Register, "Model Context Protocol prepares to break with its stateful past", 23. juuli 2026. https://www.theregister.com/devops/2026/07/23/model_context_protocol_prepares_to_break_with_its_stateful_past/5276722
4. Akamai, "The New MCP Specification: What Security Teams Must Prepare For", 25. juuni 2026. https://www.akamai.com/blog/security-research/new-mcp-specification-security-teams-must-prepare
5. Anthropic, "Bringing MCP 2026-07-28 to Claude", 28. juuli 2026. https://claude.com/blog/bringing-mcp-2026-07-28-to-claude