A Model Context Protocol jelentős infrastrukturális mérföldkőhöz érkezett: a 2026. július 28-i felülvizsgálata a protokollt egy állapot nélküli mag felé mozdítja el. Ügynökrendszereket, eszközszervereket, IDE-integrációkat vagy több modellből álló hangszerelési rétegeket építő csapatok számára ez nem kozmetikai specifikációfrissítés. Megváltoztatja a munkamenetekre, inicializálásra, méretezésre, kompatibilitásra és irányításra vonatkozó feltételezéseket.
Az MCP-kiadás jelöltje a július 28-i specifikációt úgy írta le, hogy egy állapot nélküli protokollmagot, egy kiterjesztési keretrendszert, Tasks-t, MCP-alkalmazásokat, engedélyezési szigorítást és formális elavulási szabályzatot ad hozzá. A hivatalos MCP blog arra is figyelmeztetett, hogy a kiadás törést okozó változásokat tartalmaz. Az egyik leglátványosabb MCP-szerver-megvalósítást üzemeltető GitHub a végleges kiadás előtt azt mondta, hogy az MCP-kiszolgálója már támogatta az új specifikációt, és július 28-án a protokollt „államtalanná váló”-ként írta le.
A gyakorlati jelentés egyértelmű: az MCP-t kevésbé alakítják ki egy munkamenet-igényes helyi integrációs rétegre, hanem inkább egy távoli internet-hozzáférési protokollra. Ez azért fontos, mert az ügynökrendszerek már nem korlátozódnak az asztali fejlesztői eszközökre. Egyre gyakrabban futnak felhőszolgáltatásokon, CI-rendszereken, ügyfélszolgálati munkafolyamatokon, problémakövetőkön és vállalati automatizálási platformokon belül.
Mi változott az MCP-ben
A fő változás az állapot nélküli protokollmagra való átállás. A GitHub változásnaplója szerint az új mag eltávolítja a munkameneteket és inicializálja a távoli MCP-telepítések méretezhetőségét. Ez jelentős építészeti váltás. Az állapotalapú protokollok jól működhetnek helyi eszközökhöz és ellenőrzött környezetekhez, de bonyolítják a vízszintes skálázást, a szerver nélküli végrehajtást, a feladatátvételt, az éles telepítést és a terheléselosztást.
Az állapot nélküli mag nagyobb szabadságot biztosít a megvalósítóknak az MCP-kiszolgálók normál webes infrastruktúra mögötti futtatására. A kérelmek szétoszthatók a példányok között anélkül, hogy egy adott háttérrendszeren megőriznének egy hosszú élettartamú munkamenetet. Nagy szervezetek esetében ez csökkentheti a működési bonyolultságot. Kisebb csapatok számára megkönnyítheti a hosztolt MCP-szerverek üzembe helyezését felügyelt számításokkal az egyéni hosszú távú infrastruktúra helyett.
A tágabb, 2026-07-28-as kiadás az Extensions-keretrendszert és a Tasks-t is bevezeti a kiadásra jelölt anyagok szerint. Ezek a kiegészítések azt sugallják, hogy az MCP egyre modulárisabbá válik, és egyértelműbbé válik a hosszabb ideig tartó munkával kapcsolatban. Az MCP-alkalmazások és az engedélyezési szigorítás ugyanabba az irányba mutat: a protokoll a korai ökoszisztéma-ragasztóból formálisabb réteggé fejlődik az ügynök-eszköz interakcióhoz.
Az érlelés költsége a kompatibilitási munka. Az MCP-blog törést okozó változásokkal jellemezte a kiadást, a revízió körül megjelent TypeScript és C# SDK anyagok pedig a migráció támogatására és az állapot nélküli koncepciókra összpontosítanak. Bármely csapatnak, amely MCP-kiszolgálót üzemeltet, MCP-t IDE-bővítménybe ágyaz be, vagy ügynökhívásokat irányít belső infrastruktúrán keresztül, a felülvizsgálatot mérnöki eseményként kell kezelnie, nem pedig háttérszabvány-frissítésként.
Miért fontos az állapot nélküli MCP a fejlesztők és az üzemeltetők számára?
Az ügynökeszközök méretezési problémája különbözik a szokásos API-méretezéstől. Egyetlen felhasználói kérés számos eszközhívást, modellfordulatot, újrapróbálkozást, fájlolvasást, keresési lekérdezést és jóváhagyási lépést indíthat el. Amikor az eszközprotokoll tartós munkameneteket feltételez, az éles operátoroknak meg kell őrizniük az állapotokat ezen interakciók során, vagy megkerülő megoldásokat kell kidolgozniuk a protokoll körül.
A munkamenetek magból való eltávolításával az MCP jobban illeszkedik azokhoz a környezetekhez, ahol az ügynöki munkaterhelések sorozatos, elosztott és aszinkron jellegűek. A kiszolgáló nélküli funkciók, a peremmunkások, a Kubernetes-telepítések és a többrégiós rendszerek mind előnyösek, ha a kéréseket függetlenül lehet kezelni. Ez nem szünteti meg az állapotot az ügynökalkalmazásokból; áthelyezi az állapotot az alkalmazásadatbázisokba, a feladatsorokba, az identitásrendszerekbe vagy az explicit munkafolyamat-rétegekbe, ahelyett, hogy a protokollmagba ágyazza.
A fejlesztők számára a változtatásnak végső soron a távoli eszközkiszolgálók könnyebben használhatóvá kell válnia. A platformcsapatok számára leegyszerűsítheti a megfigyelhetőséget és a kapacitástervezést. Az átláthatatlan munkamenet-affinitási viselkedés hibakeresése helyett az operátorok a kérésszintű nyomkövetésre, az eszközhívási késleltetésre, az engedélyezési döntésekre és a hibamintákra összpontosíthatnak.
Van egy irányítási szög is. Ahogy az MCP egyre gyakoribbá válik a kódolási asszisztensekben és a vállalati ügynökökben, a vállalatoknak olyan irányelvekre lesz szükségük, amelyek körül az ügynökök hívhatják az eszközöket, milyen adatokhoz férhetnek hozzá, és mely felhasználók vagy szolgáltatások hívhatják meg őket. Az engedélyezési szigorítás az új változatban tehát nem véletlen.Azt a valóságot tükrözi, hogy az eszközök hozzáférése ma már biztonsági határ, nem csak a fejlesztők kényelme.
Kik érintett
A legközvetlenebbül érintett csoportok az MCP-kiszolgálók karbantartói, az SDK-felhasználók, az ügynöki platform csapatai és a belső eszközöket AI-ügynököknek kitevő szervezetek. Ha egy kiszolgáló függ a munkamenet viselkedésétől vagy a régebbi inicializálási folyamatoktól, akkor tesztelni kell az új specifikáció szerint. Ha egy alkalmazás több MCP-verziót is támogat, akkor verzióegyeztetésre, kompatibilitási rétegekre vagy szakaszos áttelepítési tervre lehet szüksége.
Az IDE és a fejlesztői eszközök szállítói is beletartoznak. Az MCP egyre gyakrabban jelenik meg a kódoló ügynökök, egyéni ügynökök és modellkezelési szolgáltatások mellett. Az állapot nélküli protokollmag megkönnyíti ezeknek a termékeknek a távoli eszközök megbízható meghívását, de csak akkor, ha az integrációjuk lépést tart a specifikációkkal.
Az ügynökautomatizálást használó vállalkozásoknak akkor is figyelniük kell, ha soha nem olvassák el az MCP-specifikációt. A változás hatással lehet a lerakatokhoz, jegyrendszerekhez, adatbázisokhoz, belső tudásbázisokhoz vagy telepítési eszközökhöz csatlakozó ügynökök megbízhatóságára. Az áttelepítési ablakok során a valószínű hibamódok nemcsak nyilvánvaló kimaradások. Ezek lehetnek hiányzó eszközök képességei, megváltozott hitelesítési viselkedés vagy ügynökök, amelyek más utakat választanak, mert az eszközszerver már nem a várt módon viselkedik.
Az AI API-átjárók, például a Model Gate esetében praktikus a kapcsolat. Az egységes mesterséges intelligencia API egyre inkább a modell-útválasztás, az API-kulcs-kezelés, a használati elemzés és a csapat API-irányítás közelében helyezkedik el. Mivel az ügynökrendszerek MCP-eszközhívásokat adnak a szokásos modellhívások mellé, az átjáró- és megfigyelési rétegeknek figyelembe kell venniük a munkafolyamat mindkét oldalát: melyik modellt használták, mely eszközöket hívták meg, mennyibe kerültek, ki engedélyezte őket, és hol történtek hibák.
Migrációs prioritások és nyitott kérdések
Az első áttelepítési prioritás a kompatibilitási teszt. A csapatoknak leltárt kell készíteniük az MCP-kliensekről és -kiszolgálókról, azonosítaniuk kell a munkamenetektől való függőségeket vagy inicializálniuk kell a viselkedést, és tesztelniük kell a 2026-07-28 SDK-kkal vagy megfelelőségi anyagokkal, ahol rendelkezésre állnak. A termelési rendszereknek végre kell hajtaniuk a frissítést, különösen akkor, ha az ügynökök olyan mellékhatásokkal járó műveleteket hajtanak végre, mint például lekérési kérelmek létrehozása, problémák módosítása, ügyféladatok lekérdezése vagy telepítési munkafolyamatok végrehajtása.
A második prioritás a megfigyelhetőség. Az állapot nélküli infrastruktúra könnyebben méretezhető, de az elosztott ügynökrendszereknek továbbra is szükségük van korrelációs azonosítókra, nyomkövetési rögzítésre, kérésnaplókra és házirend-eseményekre. Ezek nélkül a csapatok felcserélhetik a munkamenet bonyolultságát a hibakeresési bonyolultságra. A használati elemzésnek különbséget kell tennie a modellhívások és az eszközhívások között, különösen akkor, ha az ügynöki munkafolyamatokat számlázzák, korlátozzák vagy auditálja a csapat.
A harmadik prioritás a jogosultság felülvizsgálata. Ha az új specifikáció megerősíti az engedélyezési szemantikát, a megvalósítóknak nem szabad egyszerűen átvinniük a régi hozzáférési feltételezéseket az új verzióba. Újra ellenőrizniük kell a jogkivonat hatóköreit, a felhasználói delegálást, a szolgáltatásfiókokat, az ellenőrzési naplókat és a megtagadási viselkedést. Az eszköz-hozzáférésnek alapértelmezés szerint a legkevesebb jogosultsággal kell rendelkeznie, különösen távoli MCP-telepítések esetén.
Bizonyos részleteket érdemes ellenőrizni, mielőtt a szervezetek visszafordíthatatlan tervezési döntéseket hoznának. A cikkhez rendelkezésre álló kutatás magában foglalta a kiadás jelöltjét, a specifikációs oldalt, az SDK-migrációs anyagokat és a GitHub megvalósítási megjegyzését. A 2026-07-28 specifikáció végleges normatív szövegét közvetlenül át kell tekinteni, mielőtt pontos protokollkövetelményeket idézne a belső szabványokban vagy a vevői dokumentációban.
Még ezzel a figyelmeztetéssel is egyértelmű az irány. Az MCP egyre inkább termelésorientált protokolllá válik az ügynök-infrastruktúra számára. Az állapot nélküli magnak könnyebbé kell tennie a távoli telepítések méretezését, de arra is kényszeríti az ökoszisztémát, hogy megtisztítsa a korábbi megvalósításokból származó feltételezéseket. Az ügynökökkel építkező csapatok számára ez az a fajta protokollmódosítás, amely sprintjegyet érdemel, nem csak könyvjelzőt.