MCP változás: véget érhet a session-alapú működés korszaka
Az elmúlt két évben szinte észrevétlenül történt meg egy váltás: az AI-ügynökök már nem csak chatablakokban válaszolgatnak, hanem ténylegesen dolgoznak. Fájlokat olvasnak, API-kat hívnak meg, adatbázisokhoz nyúlnak, és mindezt egyre gyakrabban távoli szervereken teszik, nem a saját gépünkön futtatva. Ez hívta életre azt a megoldást, ami az egész mögött áll: az MCP-t, vagyis a Model Context Protocol-t. És most, 2026 júliusában ez a protokoll egy nagy átalakuláson megy keresztül.
A végleges specifikáció július 28-án érkezik, a release candidate pedig már egy ideje elérhető. Amikor először végigolvastam a changelogot, kicsit furcsa volt: eltűnik a session (a szerver és a kliens közötti kapcsolatot azonosító, folyamatosan fenntartott állapot), eltűnik az inicializációs handshake (a kapcsolat elején lezajló üzenetváltás, ami tisztázza, mire képes a másik fél), három alapfunkciót pedig kivezetnek.
Majd ahogy jobban belemélyedtem, kiderült, hogy ez nem bonyolítja a dolgokat, hanem pont az ellenkezőjét csinálja. A protokoll visszaadja a feladatokat annak az infrastruktúrának, ami amúgy is jól tud velük bánni.
Mi volt a baj a session-ökkel
Az MCP eredetileg egy asztali alkalmazás és egy helyi folyamat közötti kommunikációra épült, ahol egy induláskor lezajló handshake szinte semmibe sem került, hiszen a kapcsolat hosszú életű volt.
A gond akkor kezdődött, amikor az MCP szerverek elkezdtek távoli, horizontálisan skálázott szolgáltatásokká válni. A szerver kapott egy Mcp-Session-Id azonosítót, ami az ügyfelet egyetlen konkrét példányhoz kötötte. Ha skálázni akartál, vagy session affinity kellett, vagy egy külön, megosztott session store, vagy egy MCP-tudatos gateway, ami minden JSON body-t elemezve döntött arról, hova irányítsa a hívást. Ez pontosan az a fajta plusz munka, amit egy egyszerű, stateless (állapotmentes, vagyis olyan, amelyik semmit nem jegyez meg a kérések között) HTTP szolgáltatásnak sosem kellene elviselnie.
Mi változik valójában
Az új specifikáció egyetlen elvre épül: minden kérésnek „meg kell állnia a saját lábán”. A protokoll verziója és a kliens képességei mostantól minden hívásnál a metaadatok között utaznak, nem egyszeri handshake-kor dőlnek el. Egy új server/discover metódus pedig lehetővé teszi, hogy a szerver képességeit bármikor lekérdezzük.
A fejlesztők ezt pay-as-you-go complexity elvnek hívják: az alap marad egyszerű, és az állapotkezelés csak ott jelenik meg, ahol egy funkciónak tényleg szüksége van rá, vagyis ahol stateful (állapottartó, tehát emlékező) működésre van szükség.
Persze jogos a kérdés: mi lesz azokkal a szerverekkel, amiknek tényleg emlékezniük kell dolgokra? Erre a válasz a handle-minta, ami nem valami új találmány, hanem pontosan az, amit egy HTTP-alapú bevásárlókosár csinál már húsz éve. A tool létrehoz egy azonosítót, mondjuk egy basket_id-t, visszaadja az eredményben, a kliens pedig egy sima paraméterként küldi vissza a következő híváskor.
Ami ezt szerintem többé teszi egy egyszerű workaroundnál, az az, hogy a handle látható a modell számára, míg a régi, transport metaadatokban elrejtett session-állapotról a modell semmit sem tudott. Cserébe a handle megjelenik a promptokban és a logokban is, szóval érdemes az autentikált felhasználóhoz kötni, és minden használatnál újra ellenőrizni a jogosultságot.
Mit jelent ez a gyakorlatban
Egy távoli MCP szervert mostantól sokkal inkább lehet úgy üzemeltetni, mint egy hagyományos, stateless HTTP szolgáltatást. Három replika round-robin mögött, session affinity és protokoll-szintű session store nélkül. Egy rolling deploy már nem érvényteleníti a session-öket, bár a folyamatban lévő kéréseket még mindig megszakíthatja, ezeket a kliens egyszerűen egy új request ID-vel indítja újra.
A platformcsapatoknak is könnyebb lesz a dolga: a kötelező Mcp-Method és Mcp-Name fejlécek miatt egy gateway a body megnyitása nélkül is tud rate limitel-ni vagy jogosultságot ellenőrizni.
Nekem a cache-elés körüli változás tetszik a legjobban. A lista- és olvasási válaszoknak mostantól tartalmazniuk kell egy ttlMs és cacheScope mezőt, ami a HTTP Cache-Control logikáját követi, így a kliens egy megadott ideig megtarthatja a katalógust anélkül, hogy újra lekérné. A szerverek emellett determinisztikus sorrendben adják vissza a tool-okat, ami jobb prompt cache hit arányt eredményez, ez pedig nagyobb terhelésnél alacsonyabb latenciát vagy alacsonyabb token-költséget jelenthet.
Egy dolgot viszont fontos tisztázni: a stateless működés a protokoll szintjén útvonalválaszthatóságot ad, nem determinizmust. Két replika elfogadja ugyanazt a kérést protokoll-állapot nélkül is, de ha eltérő verziót futtatnak, simán adhatnak eltérő választ.
Bővítmények jövője
A bővítmények mostantól saját névteret kapnak, saját repóval és saját ütemezéssel jelennek meg, függetlenül a fő kiadási ciklustól. Ez a váltás egyszeri töréssel jár, de a jövőben már nem lesz rá szükség: az újabb fejlesztések capability flag-ekkel érkeznek majd, ami azt jelenti, hogy a funkció úgy bővül tovább, hogy közben nem kell semmit lecserélni alatta.
Van emellett egy világos elévülési szabályzat (deprecation policy) is: minden funkció három állapoton megy végig – aktív, elévülőben lévő, majd megszűnő -, és ehhez minimum tizenkét hónapos átmeneti idő jár. Szerintem pont ez az a fajta írásos garancia, amire szükség van, ha valakinek egy platform review board előtt kell megvédenie egy MCP integrációt.
És miért jó ez? Mert kiszámíthatóvá teszi a tervezést: egy funkció nem tűnhet el egyik napról a másikra. Ez nem csak ígéret, hanem nyilvánosan is követhető folyamat, ami megmutatja, mi szűnik meg ki és mikor. Ennek gyakorlati súlya van: aki egy cégen belül akar jóváhagyást szerezni egy MCP-integrációhoz, mostantól pontos, dokumentált választ tud adni arra, mi történik, ha a szolgáltató egyszer kivezet valamit, amire épített.
Amire érdemes odafigyelni
Nem minden változás könnyű, de ez egy jó alkalom arra, hogy rendet tegyünk a saját MCP-integrációnkban. Aki a kísérleti Tasks funkcióra épített, annak most van módja átállni a végleges, letisztultabb működésre.
A legkényesebb változás a Sampling nevű funkciót érinti. Eddig, ha egy szerver a modellt akarta használni, ezt a kliensen keresztül tehette meg, így nem kellett saját fiókot tartania egy AI-szolgáltatónál, és a számlát sem neki kellett állnia. Mostantól, ha egy szerver közvetlenül fordul egy ilyen szolgáltatáshoz, magának kell gondoskodnia a hozzáférésről, ő állja a költséget, és rajta lesz a felelősség a felhasználói adatok kezeléséért is.
Az viszont fontos, hogy az alkalmazás állapota nem tűnik el, csak máshol lakik majd. Mostantól nem a protokoll, hanem maga a szerver felelőssége lesz kézben tartani őket.
