MCP 2026-07-28: az új specifikáció, amely átírja az integrációidat

A Model Context Protocol (MCP) az a nyílt szabvány, amelyen keresztül a Claude, a ChatGPT vagy egy n8n-ben összerakott AI-ügynök hozzáfér a céged rendszereihez: lekérdezi az Odoo nyitott ajánlatait, új kapcsolattartót rögzít a CRM-ben vagy megkeresi egy vevő legutóbbi számláját. Az MCP 2026-07-28 jelű specifikációja a protokoll eddigi legnagyobb átalakítása, az InfoWorld beszámolója szerint a Microsoft egyenesen az indulás óta legnagyobb revíziónak nevezte. A korábbi, folyamatos kapcsolatra épülő működés helyett minden kérés önmagában is érthető üzenet lett, a hitelesítés szigorodott, több régi funkció pedig visszaszámlálásba kezdett. A Cloudflare „az MCP következő generációjaként” hivatkozik rá, a Microsoft már a kiadás napján frissítette a C# fejlesztői csomagját, a Vercel három nappal később követte.

Ha nem fejlesztő vagy, joggal kérdezheted, mi közöd egy protokoll verziószámához. Annyi, hogy ha a cégedben már fut vagy tervben van olyan AI-integráció, amely MCP-n keresztül éri el a vállalatirányítási rendszert, a webshopot vagy az ügyfélnyilvántartást, akkor a következő egy évben valakinek hozzá kell nyúlnia, jobb tehát, ha ez tervezetten történik, nem egy hétfő reggeli hibaüzenet után. A 2026. szeptember 22-i állapot szerint sorra vesszük, mi változott pontosan, miért lesz egyszerűbb és biztonságosabb az üzemeltetés, mi szűnik meg és mikor, végül azt is, hogyan érdemes ma nekifogni egy saját MCP-szervernek Odoo-hoz vagy CRM-hez.

Röviden

• Az MCP 2026-07-28 a Model Context Protocol 2026. július 28-án kiadott specifikációja, amely a protokollt állapotmentes kérés-válasz modellre állította át: nincs többé kötelező bemutatkozó kézfogás (initialize) és munkamenet-azonosító, minden kérés magával viszi a protokollverziót, a kliens adatait és a képességeit.
• Az új, kötelező Mcp-Method és Mcp-Name HTTP-fejlécek miatt egy átjáró, terheléselosztó vagy tűzfal a kérés törzsének feldolgozása nélkül is látja, melyik eszközt hívja az AI, így az MCP-szerver egy egyszerű terheléselosztó mögött, akár szervermentes környezetben is futtatható.
• A hitelesítés szigorodott: a kliensnek ellenőriznie kell az RFC 9207 szerinti kiadóazonosítót, a hitelesítő adatok pedig az őket kiadó engedélyező szerverhez kötődnek. A dinamikus kliensregisztráció (DCR) helyett mostantól a Client ID Metadata Documents (CIMD) az ajánlott megoldás.
• A Roots, a Sampling, a Logging és a DCR elavult, a hivatalos nyilvántartás szerint legkorábban a 2027. július 28-án vagy azután kiadott első specifikációból kerülhetnek ki, a régi HTTP+SSE átvitelre viszont rövidebb átmeneti szabály vonatkozik, ezért annak kiváltása az első teendő.
• Aki csak kész, gyártói MCP-szervert használ, annak többnyire elég a kliensprogramok frissítése, egy saját fejlesztésű, Odoo-hoz vagy CRM-hez írt szerver átállítása viszont saját becslésünk szerint 16 és 40 fejlesztői óra közötti munka.
• Új MCP-szervert 2026 őszén már egyértelműen az új specifikációra érdemes építeni: kevés, jól elnevezett eszközzel, felhasználónkénti jogosultsággal, munkamenet helyett explicit azonosítókkal, Odoo esetén a 19-es verzió JSON-2 API-jára.

Mi az MCP és miért ekkora ügy a 2026-07-28-as kiadás?

Az MCP (Model Context Protocol) az Anthropic által 2024 novemberében bemutatott nyílt protokoll, amely szabványos módot ad arra, hogy egy AI-alkalmazás külső eszközöket és adatforrásokat érjen el. Az MCP-specifikáció 2026-07-28-as kiadása nem apró javítás, hanem a protokoll alapjainak újragondolása, ezért minden saját fejlesztésű MCP-integrációt érint, a kész gyártói megoldásokat viszont jóval kevésbé.

Az MCP-t gyakran az AI világának USB-C csatlakozójához hasonlítják: ahogy egy USB-C-s töltő bármelyik USB-C-s telefonhoz jó, úgy egy MCP-szerver is bármelyik MCP-képes AI-alkalmazással működik. A szerver kínálja az eszközöket (tools), vagyis a meghívható műveleteket, mellettük az olvasható erőforrásokat (resources) és az előre megírt utasítássablonokat (prompts). A kliens maga az AI-alkalmazás, például a Claude asztali programja, a ChatGPT vagy egy n8n-munkafolyamat, amely a nyelvi modell kérésére meghívja ezeket. Egy képzeletbeli 20 fős székesfehérvári nagykereskedésben így a modell nem az Odoo képernyőit böngészi, hanem közvetlenül azt kéri a szervertől, hogy adja ide a Kovács Kft. nyitott ajánlatait.

A protokoll mára iparági alapnak számít. A specifikáció két vezető karbantartója, David Soria Parra és Den Delimarsky a kiadást bejelentő, 2026. július 28-i blogbejegyzésben azt írta, hogy az első körös (Tier 1) fejlesztői csomagokat havonta közel félmilliárd alkalommal töltik le, miközben a TypeScript- és a Python-csomag külön-külön is átlépte az egymilliárdos összesített letöltésszámot.

Hogy miért kellett hozzányúlni egy ennyire sikeres protokollhoz, azt az üzemeltetők értik a legjobban. A 2025. november 25-i előző kiadásig egy MCP-kapcsolat egy telefonhívásra hasonlított: az elején a felek bemutatkoztak egymásnak (ez volt az initialize kézfogás), a szerver kiosztott egy munkamenet-azonosítót, utána végig ugyanannak a szerverpéldánynak kellett emlékeznie mindenre, ami a hívás során elhangzott. A Cloudflare 2026. augusztus 6-i elemzése szerint ez ragadós munkamenetekhez (sticky sessions) kötött útválasztást, nyitva tartott adatfolyamokat és üzenet-visszajátszást követelt, vagyis pont azokat a dolgokat, amelyek egy felhős környezetben drágák és törékenyek.

Legalább ilyen fontos a kiadással bevezetett formális életciklus-szabályzat, amely szerint egy elavultnak jelölt funkció legalább 12 hónapig a specifikáció része marad, mielőtt kivezethetik. A karbantartók megfogalmazása szerint ennek célja, hogy a fejlesztők tervezhessenek, ne csak utólag reagáljanak, ami egy KKV-nak is jó hír, hiszen az átállást így be lehet ütemezni a többi fejlesztés közé.

Mi változott az MCP 2026-07-28 specifikációban?

Az MCP 2026-07-28 legfontosabb változása, hogy a protokoll állapotmentessé vált: nincs kézfogás és munkamenet, minden kérés hordozza a szükséges adatokat. Emellett kötelezők lettek az Mcp-Method és Mcp-Name HTTP-fejlécek, a hosszú feladatok kiterjesztésbe kerültek, a pótlólagos adatokat pedig a szerver újraküldéses mintával kéri be.

Az alábbi részletek a modelcontextprotocol.io oldalon olvasható hivatalos változásnaplóból (changelog) származnak.

Állapotmentes kérések: minden üzenet önmagában megáll

Az új specifikációból kikerült az initialize és notifications/initialized üzenetpár, vagyis a kötelező bemutatkozás, valamint a Streamable HTTP átvitel Mcp-Session-Id munkamenet-fejléce. Helyette minden kérés a saját _meta mezőjében viszi a protokollverziót és a kliens képességeit. Ajánlott, hogy a kliens minden kérésnél a nevét és a verzióját is megadja. Ha a szerver nem ismeri a kért protokollverziót, UnsupportedProtocolVersionError hibával válaszol és felsorolja, mit támogat helyette.

A telefonhívás helyett tehát levelezés folyik, ahol minden borítékon rajta van a feladó, a nyelv és a hivatkozási szám, így bármelyik ügyintéző fel tudja dolgozni, akkor is, ha az előző levelet egy kollégája kapta. A szervernek ettől még lehet állapota, csak nem a protokoll szintjén: ha egy művelet több lépésen át tart, a szerver kiad egy azonosítót (a specifikáció szóhasználatával handle), amelyet a kliens a következő eszközhívásban sima paraméterként küld vissza. Egy Odoo-integrációban ez lehet például egy ajánlatpiszkozat azonosítója, amelyhez az ügynök a következő lépésben tételeket ad.

Aki előre tudni szeretné, mit tud a szerver, az új, minden szerver számára kötelező server/discover hívással lekérdezheti a támogatott verziókat, a képességeket és a szerver azonosítóját. A gépen, parancssoros átvitellel (stdio) futó helyi szervereknél ugyanez a hívás szolgál a visszafelé kompatibilitás próbájára, az állapotmentesség tehát a helyi MCP-szervereket is érinti, nem kizárólag a felhőben üzemelőket.

Mcp-Method és Mcp-Name fejlécek: a tárgy a boríték külsejére kerül

A Streamable HTTP, vagyis az MCP hálózati átviteli módja mostantól minden POST-kérésnél megköveteli az Mcp-Method fejlécet, amely a meghívott műveletet tartalmazza. Az eszközhívásnál, az erőforrás-olvasásnál és a sablonlekérésnél ehhez jön még az Mcp-Name fejléc is, benne az eszköz nevével vagy az erőforrás címével. Ezek az adatok eddig is ott voltak a kérésben, csak a JSON-törzs belsejében. A specifikáció szerint a cél az, hogy a terheléselosztók, az átjárók és a megfigyelőeszközök a törzs feldolgozása nélkül irányíthassák és vizsgálhassák a forgalmat. Egy eszközhívás az új specifikáció szerint így néz ki (a példa a hivatalos dokumentáció mintáját követi, egy képzeletbeli Odoo-eszközzel):

POST /mcp HTTP/1.1
Host: mcp.example.com
Content-Type: application/json
Accept: application/json, text/event-stream
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: nyitott_ajanlatok
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "nyitott_ajanlatok",
    "arguments": { "partner": "Kovács Kft." },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": { "name": "PeldaKliens", "version": "1.0.0" },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

Nem fejlesztőként elég annyit látnod, hogy a kérés fejlécében, még a tartalom előtt, olvasható formában ott áll: ez egy eszközhívás a nyitott_ajanlatok nevű eszközre. Egy átjáró így bontás nélkül eldöntheti, hogy az adott felhasználó hívhatja-e ezt az eszközt, hány ilyen hívást engedjen percenként vagy melyik szerverre továbbítsa. Hogy senki ne játszhasson ki egy ilyen szűrőt hamis fejléccel, a szervernek kötelező összevetnie a fejlécet a törzzsel, eltérés esetén pedig 400-as HTTP-kóddal és HeaderMismatch (-32020) hibával kell elutasítania a kérést. Ugyanez vonatkozik az MCP-Protocol-Version fejlécre, amelynek egyeznie kell a törzsben küldött verzióval.

Van egy apró, de a magyar cégeknek bosszantó részlet: a fejlécbe csak ASCII-karakter kerülhet, ezért egy ékezetes eszköz- vagy erőforrásnevet a kliens Base64-kódolással, egy külön jelölővel körülvéve küld el. Ez működik, de a naplókban olvashatatlan, ezért az eszközneveket jobb eleve ékezet nélkül, kisbetűvel és aláhúzással képezni, ahogy a fenti példában is. A szerver ezenfelül az eszköz bemeneti sémájában x-mcp-header jelöléssel kérheti, hogy egy paraméter (például a régió vagy az ügyfél azonosítója) Mcp-Param- előtagú fejlécként is utazzon, így egy több ügyfelet kiszolgáló szerver a fejléc alapján irányíthatja a kérést a megfelelő adatbázishoz.

Feladatok (Tasks) kiterjesztésként: hosszú munkák sorszámmal

A hosszú ideig futó műveletek, például egy több ezer soros termékimport vagy egy éves számlaösszesítő elkészítése, eddig kísérleti funkcióként a protokoll magjában kaptak helyet. Az új specifikáció a feladatokat (Tasks) io.modelcontextprotocol/tasks néven hivatalos kiterjesztésbe emelte és közben át is tervezte őket. A blokkoló tasks/result helyett a kliens a tasks/get hívással kérdezi le időnként az állapotot, az új tasks/update hívással menet közben adatot küldhet a szervernek, a tasks/list pedig megszűnt. A szerver ráadásul külön kérés nélkül is visszaadhat feladatazonosítót, ha úgy látja, hogy a munka tovább tart a szokásosnál.

Üzleti nyelvre fordítva ez olyan, mint a sorszám a kormányablakban: az ügynök nem áll a pult előtt, amíg elkészül a dokumentum, hanem kap egy számot és időnként ránéz, hol tart az ügye. Mivel kiterjesztésről van szó, nem minden szerver és kliens fogja támogatni, a támogatást a képességek új extensions mezőjében kell jelezni. Ha a céged folyamataiban vannak percekig vagy órákig tartó műveletek, a beszállítódtól kérdezd meg kifejezetten, hogy a kliens kezeli-e ezt a kiterjesztést.

Visszakérdezés újraküldéssel: a Multi Round-Trip Requests minta

Eddig a szerver menet közben saját kéréseket küldhetett a kliensnek: megkérdezhette a felhasználót (elicitation), kérhetett a kliens nyelvi modelljétől szöveggenerálást (sampling) vagy lekérdezhette az elérhető mappákat (roots). Az új Multi Round-Trip Requests (MRTR) minta ezt megfordítja. A szerver ilyenkor nem kérdez vissza, hanem egy input_required típusú köztes eredménnyel jelzi, milyen adat hiányzik még, a kliens pedig összegyűjti a választ és az eredeti kérést újraküldi, immár a hiányzó adatokkal együtt. Minden eredmény kötelező resultType mezőt kapott, amelynek értéke complete vagy input_required lehet.

A minta a gyakorlatban a jóváhagyásoknál jön jól. Tegyük fel, hogy egy AI-asszisztens egy 1,2 millió forintos ajánlatot készül rögzíteni az Odoo-ban: a szerver megerősítő kérdéssel ellátott köztes választ ad, a felhasználó a kliens felületén rábólint, végül a kliens a válasszal együtt újra elküldi a kérést. Mivel a szervernek nem kell nyitva tartott kapcsolaton várakoznia, a jóváhagyás akár percekig is tarthat anélkül, hogy bármi elveszne közben.

Gyorsítótárazható listák és kiszámítható sorrend

Az eszközök, a sablonok és az erőforrások listáját visszaadó válaszok, valamint az erőforrás-olvasás eredménye kötelező ttlMs és cacheScope mezőt kaptak. Az előbbi ezredmásodpercben adja meg, meddig tekinthető frissnek a válasz, az utóbbi (public vagy private értékkel) azt, hogy egy közbülső gyorsítótár eltárolhatja-e. A specifikáció azt is ajánlja, hogy a szerver mindig ugyanabban a sorrendben adja vissza az eszközeit, ami elsőre szőrszálhasogatásnak tűnik, pedig pénzről van szó: a nyelvi modellek szolgáltatóinál a prompt-gyorsítótár csak akkor csökkenti a számlát, ha a modellnek átadott eszközlista minden körben betűre azonos. A változásokról a kliens a subscriptions/listen hívással nyitott, hosszú életű adatfolyamon kaphat értesítést, amely a korábbi külön GET-végpontot és a resources/subscribe hívást váltja ki.

Állapotmentes üzemeltetés: egyszerűbb és olcsóbb szerverek

Az állapotmentes MCP-szerver bármelyik példánya kiszolgálhat bármelyik kérést, így a szerver egy hagyományos, körbeforgó terheléselosztó mögé tehető, közös munkamenet-tároló és ragadós munkamenetek nélkül. Ettől a szerver futhat szervermentes környezetben is, ahol a költség a tényleges hívásokhoz igazodik, míg a meglévő tűzfalak és átjárók az új fejlécek alapján szabályozhatják a forgalmat.

A hivatalos bejelentés kiemeli, hogy ehhez sem közös tárolóra, sem tartós kapcsolatra nincs szükség. A Microsoft a C# fejlesztői csomag 2.0-s verziójának bejelentésében, az InfoWorld idézése szerint, úgy fogalmazott, hogy egy MCP-kérés mostantól egyetlen, önmagát leíró HTTP POST, így a hétköznapi HTTP-infrastruktúra (terheléselosztók, proxyk, átjárók, webalkalmazás-tűzfalak) mély csomagvizsgálat nélkül tud vele dolgozni. A Cloudflare szerint egy MCP-szerver most már futhat egyetlen Workerben, állapotot tároló infrastruktúra nélkül. A cég saját Code Mode MCP-szervere a bejegyzés szerint másodpercenként több ezer kérésig skálázódott és több milliárd eszközhívást szolgált ki.

Pontos forintösszeget felelősen nem lehet mondani, mert a tárhelyköltség a forgalomtól és a szolgáltatótól függ, az irány viszont egyértelmű. Tegyük fel, hogy egy 30 fős cég belső MCP-szervere naponta néhány száz hívást kap, munkaidőben csúcsosodva, éjjel szinte semmit. A régi modellben ehhez is folyamatosan futó, munkamenetet tároló szerver kellett, az újban viszont a szerver elfuthat ugyanazon a konténeres vagy szervermentes platformon, ahol a weboldalad vagy az n8n-ed is üzemel, így a költsége a tényleges terheléshez igazodik.

Az állapotmentességnek ára is van, amit a tervezésnél figyelembe kell venni. Ha megszakad egy válaszfolyam, a folyamatban lévő kérés elvész, ilyenkor a kliensnek új azonosítóval újra el kell küldenie. Egy lekérdezésnél ez mindegy, egy számlarögzítésnél viszont duplikációhoz vezethet, ezért az írási műveleteket végző eszközöket idempotensre kell tervezni, vagyis úgy, hogy ugyanaz a kérés kétszer elküldve se hozzon létre két számlát.

Biztonság: RFC 9207 issuer-ellenőrzés és CIMD a dinamikus regisztráció helyett

Az MCP 2026-07-28 három ponton szigorít a hitelesítésen: a kliensnek ellenőriznie kell, melyik engedélyező szerver adta ki a visszakapott kódot (RFC 9207), a tárolt hitelesítő adatok az őket kiadó szerverhez kötődnek, a kliensregisztrációhoz pedig a Client ID Metadata Documents (CIMD) lett az ajánlott módszer a dinamikus regisztráció helyett.

Az MCP hitelesítése az OAuth szabványra épül, ugyanarra, amellyel a Google- vagy Microsoft-fiókoddal lépsz be más szolgáltatásokba. Amikor egy AI-kliens először csatlakozik a céges MCP-szerverhez, a felhasználó bejelentkezik egy engedélyező szervernél (authorization server) és hozzájárul a hozzáféréshez, majd a kliens kap egy egyszer használatos kódot, amelyet hozzáférési tokenre vált. A három változás ennek a folyamatnak a gyenge pontjait erősíti meg.

Mi az a mix-up támadás és hogyan zárja ki az RFC 9207?

Az RFC 9207 az IETF 2022-ben kiadott szabványa (OAuth 2.0 Authorization Server Issuer Identification), amely szerint az engedélyező szerver a visszaküldött kód mellé az iss paraméterben a saját azonosítóját is odaírja. Erre azért van szükség, mert egy AI-kliens egyszerre több MCP-szerverhez, így több engedélyező szerverhez is kapcsolódhat. Egy rosszindulatú szerver ilyenkor megpróbálhatja úgy összekeverni a folyamatokat, hogy a kliens egy másik szervertől kapott kódot nála váltsa be. Ezt nevezik keveredéses (mix-up) támadásnak.

Az új specifikáció szerint az engedélyező szervereknek ajánlott megadniuk az iss paramétert, a kliensnek pedig kötelező összevetnie a kapott értéket a korábban rögzített kiadóval, mielőtt beváltja a kódot. Hétköznapi hasonlattal élve a hivatalos levélen rajta van a kiállító hivatal pecsétje, a címzett így csak akkor intézkedik, ha a pecsét annak a hivatalnak a pecsétje, amelyhez ő maga fordult.

Kiadóhoz kötött hitelesítő adatok

A második szigorítás a kliens által tárolt hitelesítő adatokra vonatkozik. A kliensnek ezeket az engedélyező szerver kiadói azonosítójához kell kötnie, más szervernél nem használhatja fel őket újra, ha pedig a szerver megváltozik, újra kell regisztrálnia. Egy cégvezető ezt úgy fordíthatja le, hogy egy kulcs mostantól csak ahhoz a zárhoz jó, amelyhez kiadták, akkor is, ha a két ajtó egymás mellett van.

CIMD: a kliens névjegye egy webcímen

A Client ID Metadata Documents (CIMD) olyan OAuth-megoldás, amelyben a kliens azonosítója egy HTTPS-webcím, amely a kliens adatait tartalmazó JSON-dokumentumra mutat. Az engedélyező szerver a bejelentkezéskor letölti ezt a dokumentumot, ellenőrzi, hogy a benne szereplő azonosító pontosan egyezik-e a címmel, valamint azt is, hogy a visszairányítási cím szerepel-e az engedélyezettek között. A hivatalos dokumentáció mintája alapján egy ilyen dokumentum így néz ki:

{
  "client_id": "https://app.example.com/oauth/client-metadata.json",
  "client_name": "Példa Kft. belső AI-asszisztens",
  "redirect_uris": ["http://127.0.0.1:3000/callback"],
  "grant_types": ["authorization_code"],
  "response_types": ["code"],
  "token_endpoint_auth_method": "none"
}

Eddig a jellemző megoldás a dinamikus kliensregisztráció (DCR, RFC 7591) volt, amelyben a kliens minden új szervernél automatikusan regisztrálta magát. Ez kényelmes, csakhogy így minden kliens minden szerveren külön bejegyzést hoz létre, amelyet valakinek nyilván kell tartania. A CIMD-nél nincs ilyen lépés: a kliens azonosítója egy általa üzemeltetett webcím, amely a specifikáció szerint bármelyik engedélyező szervernél ugyanaz marad, így szerverváltáskor sem kell újraregisztrálni. A specifikáció által javasolt sorrend a következő: először az előre regisztrált adatok, ha vannak, utána a CIMD, ha az engedélyező szerver jelzi a támogatását, végső esetben a DCR, ha pedig egyik sem működik, a felhasználótól kell bekérni az adatokat.

A DCR nem szűnt meg, csak elavult: a régebbi engedélyező szerverekkel való kompatibilitás miatt továbbra is használható. Ha a kliens mégis ezt használja, az új szabály szerint kötelező megadnia az application_type értékét: az asztali, mobilos és parancssoros alkalmazások, valamint a localhoston futó webes felületek native, a távoli böngészős alkalmazások web típust jelölnek meg. Ez egy régi bosszúságot old meg, mert a paraméter nélkül az OpenID Connectet használó szerverek web típust feltételeztek és elutasíthatták a localhostra mutató visszairányítást, amitől egy asztali AI-kliens egyszerűen nem tudott bejelentkezni.

Mit jelentenek a szigorítások a te integrációidnak?

A biztonsági változtatások mögött valós kockázatok állnak. Szeptember 7-én arról szóltak a hírek, hogy a sok cégnél AI-átjáróként használt LiteLLM MCP-hitelesítésében aktívan kihasznált bejelentkezés-megkerülési hibát találtak, amelyen keresztül a csatolt eszközök is elérhetővé váltak. Egy MCP-szerver ugyanis nem újabb csevegőablak, hanem kulcs a céged rendszereihez, ezért a hitelesítését ugyanolyan komolyan kell venni, mint a banki belépést.

Ha kész klienst (Claude, ChatGPT, Copilot) és gyártói MCP-szervert használsz, a fenti szigorításokat a gyártók építik be, neked a frissítések telepítése és a jogosultságok átnézése marad. Saját szervernél viszont a fejlesztőd feladata, hogy az engedélyező szerver küldje az iss paramétert, a saját kliensek ellenőrizzék azt, a szerver támogassa a CIMD-t és ellenőrizze az Origin fejlécet (érvénytelen érték esetén 403-as válasszal), helyi futtatásnál pedig csak a 127.0.0.1 címen figyeljen. Ez utóbbi kettőt a specifikáció a DNS-rebinding elleni védelemként írja elő, illetve ajánlja, amely nélkül egy rosszindulatú weboldal elérhetné a gépen futó MCP-szervert.

Mi szűnik meg és meddig tart a 12 hónapos türelmi idő?

Az MCP 2026-07-28-ból azonnal kikerült az initialize kézfogás, a munkamenet-azonosító, a ping és az adatfolyamok folytathatósága. A Roots, a Sampling, a Logging és a dinamikus kliensregisztráció elavult, ezek legkorábban a 2027. július 28-án vagy azután kiadott első specifikációval tűnhetnek el, a régi HTTP+SSE átvitelre viszont rövidebb határidő vonatkozhat.

A kétféle kivezetést érdemes megkülönböztetni. Ami kikerült, az az új protokollverzióban már nem létezik, a régi kliensek viszont ettől még nem állnak le, mert egy szerver párhuzamosan több verziót is kiszolgálhat. A Vercel például ugyanazon a címen szolgálja ki mindkét verziót, a cég július 31-i bejelentése szerint a 2025-ös protokollra épülő kliensek pontosan úgy működnek tovább, mint korábban. A Cloudflare azt javasolja, hogy a régi, munkamenetes útvonal mellé építs egy szigorúan állapotmentes útvonalat, fokozatosan költöztesd át a funkciókat, hagyd lezárulni a futó munkameneteket, majd a türelmi időn belül kapcsold le a régi utat. Egy új kliens úgy ismeri fel a régi szervert, hogy először modern kérést küld: ha erre 400-as választ kap, de modern hibaüzenet nélkül, visszavált a régi kézfogásra.

A hivatalos nyilvántartás azt is rögzíti, hogy a legkorábbi dátum csak azt jelzi, mikortól lehet egy funkciót eltávolítani, a tényleges döntést a vezető karbantartók hozzák a kiadások előkészítésekor, így az eltávolítás később is jöhet. A 12 hónap tehát alsó határ, nem pontos határidő, a HTTP+SSE esetében viszont épp fordított a helyzet: mivel már 2025 márciusa óta elavultnak számít, rá egy átmeneti szabály vonatkozik, amely jóval rövidebb türelmi időt is lehetővé tesz. Ha a szervered még ezt a régi átvitelt használja, az legyen a teendőlista első tétele.

Az elavult funkciók közül üzletileg a Sampling a legérdekesebb. Ezzel a szerver a kliens nyelvi modelljét kérhette kölcsön, például egy összefoglaló megírására, így a tokenek költségét a kliens oldala fizette. Az ajánlott kiváltás szerint a szerver mostantól közvetlenül hívja a nyelvimodell-szolgáltató API-ját, ami saját API-kulcsot, saját költségkeretet és GDPR szempontjából egy újabb adatfeldolgozót jelent. A Roots a helyi fájlrendszer-hozzáférést szabályozta, ezt a jövőben eszközparaméterként vagy szerverbeállításként kell megadni. A Logging helyett az OpenTelemetry szabványos megfigyelési eszközei ajánlottak, amelyek amúgy is jobb rálátást adnak arra, mit csinál egy ügynök a rendszereidben.

Ki támogatja már az új MCP-t?

• szeptember 22-i állapot szerint az MCP négy első körös fejlesztői csomagja (TypeScript, Python, Go és C#) támogatja az új specifikációt, a Rust bétában. A Cloudflare Agents SDK az első naptól kezeli, a Vercel saját MCP-szervere július 31. óta, míg a Microsoft a C# csomag 2.0-s verziójával a kiadás napján állt át.

A Cloudflare augusztus 6-i bejegyzése szerint az Agents SDK-ban a korábbi McpAgent osztály helyett a createMcpHandler függvény az ajánlott út, a Durable Objects nevű állapottároló szolgáltatásra pedig csak akkor van szükség, ha magának az alkalmazásnak kell állapotot tárolnia, a protokollnak már nem. A Vercel a hivatalos MCP SDK 2-es és a saját mcp-handler csomagjának 2.x verziójával állt át, a telepítés módja nem változott.

A Microsoft a C# SDK 2.0-s kiadásában alapértelmezetté tette az állapotmentes HTTP-szervert és bevezette az MRTR-minta támogatását, az InfoWorld július 29-i cikke szerint a következő fókusz a teljes körű hitelesítés és jogosultságkezelés. A Microsoft Agent Framework 1.19.0-s kiadása az MCP-munkamenetek hatókörének szabályozását és biztonsági korlátozásokat hozott. Az n8n szeptemberi kiadásai (a szeptember 8-i 2.39.0 és a szeptember 15-i 2.40.0) az OAuth, a titkok kitakarása és az MCP-hibakezelés terén javítottak, ezekről külön cikkben írunk.

A protokoll közben egyre több helyen jelenik meg. Az Adobe szeptember 2-án 70-nél több eszközét tette elérhetővé a Slackben egy MCP-alapú boton keresztül, míg a Nature-ben bemutatott Paper2Agent 100 biológiai szakcikkből 74-et alakított emberi beavatkozás nélkül tesztelt MCP-szerverré. Érdemes elkülöníteni a WebMCP-t is: ez a böngészőben, a megnyitott weboldalon futó rokon szabványjavaslat, amelyről szintén külön cikkünk szól, a 2026-07-28-as specifikáció viszont a szerverek és a háttérrendszerek világát szabályozza.

Kit érint az átállás és kit nem?

Az érintettség attól függ, ki üzemelteti az MCP-szervert. Ha kész gyártói szervert és kész AI-klienst használsz, a teendőd minimális, mert a frissítést a gyártók végzik. Ha viszont saját vagy közösségi szerver fut a cégednél, különösen ha Sampling funkcióra vagy HTTP+SSE átvitelre épül, azt a következő hónapokban át kell állítani.

A gyakorlatban négy tipikus helyzettel találkozunk. Ha a Claude-ot a HubSpot hivatalos MCP-szerverével használod, elég a kliensek frissítése és esetleg egy újracsatlakozás. Ha az n8n, a Make vagy a Zapier MCP-csomópontjai kapcsolódnak külső szerverekhez, a platform frissítése után a munkafolyamatokat, különösen a hitelesítést, érdemes végigtesztelni. A saját fejlesztésű, távoli MCP-szerver (például egy Odoo-hoz vagy egyedi CRM-hez írt integráció) az átállás fő célpontja. A fejlesztők gépén, stdio-átvitellel futó helyi szervereket a kézfogás megszűnése és a Roots elavulása érinti, de ezek jellemzően egy csomagfrissítéssel rendbe tehetők.

Ha nem te fejlesztetted az integrációt, az alábbi kérdéseket tedd fel a beszállítódnak vagy az ügynökségednek:

• Melyik MCP-specifikációt támogatja a szerverünk és mikortól kezeli a 2026-07-28-as változatot?
• Kiszolgálja-e az átmeneti időben párhuzamosan a régi és az új klienseket?
• Használ-e a szerver Sampling, Roots, Logging vagy HTTP+SSE funkciót? Ha igen, mi a kiváltás terve és határideje?
• Ellenőrzi-e a hitelesítés a kiadóazonosítót, támogatja-e a CIMD-t?
• Felhasználónkénti jogosultsággal fut-e a szerver, vagy egyetlen adminisztrátori kulccsal?
• Idempotensek-e az írási műveletek, vagyis egy újraküldött kérés nem hoz-e létre duplikált rekordot?

Hogyan tervezz saját MCP-szervert Odoo-hoz?

Egy Odoo-hoz írt MCP-szervert 2026 őszén az új specifikációra, az Odoo 19 JSON-2 API-jára és felhasználónkénti API-kulcsokra érdemes építeni. Indulj kevés, feladatra szabott, csak olvasó eszközzel, az írási műveleteket pedig kösd jóváhagyáshoz és olyan azonosítóhoz, amely kiszűri az újraküldött kérések duplikátumait.

Mielőtt bármit építenél, nézz körül a kész megoldások között, mert közösségi Odoo MCP-szerverből több is létezik, az egyik ismertebb a nyílt forráskódú mcp-server-odoo. A projekt 2026. szeptember 14-i hibajegye jól mutatja, merre halad az Odoo: a 19-es verzió minden régi típusú hívásnál figyelmeztet, hogy a /xmlrpc, /xmlrpc/2 és /jsonrpc végpontok elavultak és a hibajegyben idézett üzenet szerint az Odoo 22-ben kerülnek ki. Utódjuk a JSON-2 API, ahol egy művelet egyetlen POST /json/2/<modell>/<metódus> kérés és az API-kulcs az Authorization fejlécben utazik. Új szervert tehát már erre építs, egy régi végpontokra épülő kész megoldásnál pedig kérdezd meg a fejlesztőt, mikor áll át.

Vegyünk egy képzeletbeli, 25 fős győri alkatrész-kereskedést, amelynek belső értékesítői a Claude-ból szeretnék elérni az Odoo-t. Egy jól megtervezett első verzió hat eszközzel indulhat:

A tervezésnél hét szabályt érdemes betartani:

• Feladatra szabott eszközök. Ne adj a modellnek olyan általános eszközt, amellyel tetszőleges Odoo-metódust hívhat, mert azzal a teljes adatbázist a kezébe adod. Hat jól körülhatárolt eszköz biztonságosabb és a modell is ritkábban téved közöttük.
• Felhasználónkénti hitelesítés. Minden kolléga a saját Odoo-jogosultságaival dolgozzon, saját API-kulccsal vagy OAuth-bejelentkezéssel, így az MCP-n keresztül sem lát többet, mint az Odoo felületén.
• Olvasással kezdj. Az első hetekben csak az olvasó eszközök fussanak élesben, az írási eszközöket pedig a specifikáció eszköz-annotációival (readOnlyHint, destructiveHint) is jelöld, hogy a kliens figyelmeztethessen.
• Jóváhagyás és értékhatár. Egy meghatározott összeg fölött az írási eszköz MRTR-alapú megerősítést kérjen, mielőtt bármit rögzít.
• Idempotencia. Minden írási hívás kapjon egy kliens által generált hivatkozási azonosítót, amely alapján a szerver kiszűri a megszakadt, majd újraküldött kérések duplikátumait.
• Állapot azonosítóval. A többlépéses műveleteknél a szerver adjon vissza piszkozatazonosítót, amelyet a következő lépés paraméterként kap meg.
• Tömör leírások és válaszok. A modell az eszközleírásból dönti el, mikor mit hív, ezért a pontos, magyar nyelvű leírás legalább annyit ér, mint a kód. A válaszokban csak a szükséges mezők szerepeljenek, mert minden felesleges mező tokenben fizetendő.

Akkor is legyen hitelesítés, ha a szerver csak a cég belső hálózatáról érhető el, a naplókban pedig maszkold a személyes adatokat (név, e-mail-cím, adószám), mert a GDPR szerint a naplózás is adatkezelésnek számít.

MCP-szerver CRM-hez: kész, közösségi vagy saját fejlesztés

CRM-nél először mindig azt nézd meg, van-e a gyártónak hivatalos MCP-szervere, mert annak frissítését és biztonságát a gyártó viszi. Saját szervert akkor érdemes építeni, ha egyedi CRM-et használsz, ha a kész szerver nem fedi le a folyamataidat, vagy ha több rendszert kell egyetlen eszközkészletbe fognod.

Jó példa a HubSpot, amelynek távoli MCP-szervere 2026. április 13. óta általánosan elérhető. A HubSpot fejlesztői változásnaplója szerint a szerver többek között a kapcsolattartókat, a cégeket, az üzleteket, a jegyeket, az árajánlatokat, a számlákat és a termékeket olvassa, létrehozni vagy módosítani pedig kapcsolattartót, céget, üzletet, jegyet, terméket és tevékenységet (hívást, találkozót, jegyzetet, feladatot, e-mailt) tud. A kapcsolódáshoz PKCE-vel kiegészített OAuth 2.1 kell, minden művelet a felhasználó meglévő HubSpot-jogosultságain belül marad. Bekapcsolt érzékenyadat-kezelés esetén a tevékenységobjektumok nem érhetők el az MCP-n keresztül. Egy HubSpotot használó cégnek tehát a legtöbb esetben nem kell saját szervert írnia, legfeljebb egy vékony kiegészítőt a hiányzó folyamatokhoz.

Más a helyzet egy saját fejlesztésű ügyfélnyilvántartásnál. Vegyünk egy képzeletbeli, 12 fős budapesti könyvelőirodát, amelynek egyedi webes CRM-je tartja nyilván az ügyfeleket, a bevallási határidőket és a hiányzó dokumentumokat. Itt négy eszköz elég az induláshoz: ügyfélkeresés, a következő 30 nap határidőinek listája, egy ügyfél hiányzó dokumentumai, valamint jegyzet rögzítése. Mivel az iroda ügyfelei adószámot, bankszámlaszámot és jövedelmi adatokat is megosztanak, ezek alapból maradjanak ki a válaszokból, a teljes adat pedig csak egy külön, naplózott eszközön keresztül legyen elérhető. Ha egy szolgáltató több ügyfél CRM-jét szolgálja ki egyetlen szerverről, az x-mcp-header jelöléssel fejlécbe tett ügyfélazonosító megkönnyíti az útválasztást, a jogosultságról viszont soha ne a fejléc, hanem a hitelesített felhasználó alapján dönts.

Lépésről lépésre: így készítsd fel az integrációidat az új MCP-re

Az alábbi tíz lépést egy néhány MCP-kapcsolattal dolgozó KKV-ra szabtuk, a fejlesztőddel vagy az ügynökségeddel közösen érdemes végigvinni.

• Készíts leltárt. Írd össze az összes MCP-kapcsolatot: melyik kliens, melyik szerver, ki üzemelteti és milyen adatokhoz fér hozzá.
• Derítsd ki a verziókat. Minden szervernél nézd meg, melyik protokollverziót beszéli, illetve használ-e Sampling, Roots, Logging vagy HTTP+SSE funkciót.
• Rangsorolj kockázat szerint. Elöl a HTTP+SSE-t használó szerverek álljanak, utánuk az írási joggal bíró integrációk, végül a csak olvasók.
• Frissítsd a fejlesztői csomagot. A TypeScript, a Python, a Go és a C# SDK aktuális verziója már támogatja a 2026-07-28-as specifikációt. A régi útvonalat egyelőre hagyd meg párhuzamosan.
• Váltsd ki a munkamenetet. A munkamenetben tárolt adatokat szerver által kiadott azonosítók vegyék át és az írási eszközöket tedd idempotenssé.
• Pótold az elavult funkciókat. Sampling helyett saját nyelvimodell-hívás kell külön költségkerettel, Roots helyett eszközparaméter, Logging helyett OpenTelemetry.
• Erősítsd meg a hitelesítést. Legyen kiadóazonosító-ellenőrzés, kiadóhoz kötött kliensadat és CIMD-támogatás. DCR esetén add meg helyesen az application_type értékét.
• Állítsd be az átjárót. Az Mcp-Method és Mcp-Name fejlécek alapján szabj hívásszám-korlátot, nginx mögött pedig kapcsold ki a válaszpufferelést az X-Accel-Buffering: no fejléccel, különben az adatfolyam akadozhat.
• Tesztelj régi és új klienssel. Próbáld ki a fejléc-eltérést, a megszakadt kérést és a visszaváltást a régi kézfogásra.
• Élesíts, majd vezesd ki a régit. Figyeld a régi útvonal forgalmát. Amikor elapadt, a türelmi időn belül kapcsold le és frissítsd a dokumentációt.

Mennyi munka és mennyibe kerül az átállás?

Saját becslésünk szerint egy kész gyártói szervert használó cégnek néhány óra ellenőrzés, egy saját, 5 és 10 eszköz közötti MCP-szerver átállítása 16 és 40 fejlesztői óra, egy új Odoo MCP-szerver megtervezése és megépítése pedig 40 és 80 óra közötti munka. A pontos szám a meglévő kód állapotán és a tesztelés mélységén múlik.

Egy feltételezett, 15 000 Ft-os nettó fejlesztői óradíjjal számolva a 16 és 40 óra közötti átállás 240 000 és 600 000 Ft közé esik, egy új, 60 órás Odoo MCP-szerver pedig 900 000 Ft körül jön ki. A táblázat óraszámait a saját ajánlataidhoz viszonyítsd, mert az óradíj szakemberenként jelentősen eltér.

A megtérülést is érdemes kiszámolni, szintén feltételezett számokkal. Ha az Odoo-asszisztens havonta 20 órát spórol meg a belső értékesítőknek, egy munkaóra teljes költsége pedig 6 000 Ft, a megtakarítás havi 120 000 Ft, így a 900 000 Ft-os fejlesztés a nyelvi modell és az üzemeltetés költsége nélkül nagyjából 7,5 hónap alatt térül meg. Ha ugyanez az asszisztens csak havi 5 órát spórol, a megtérülés két és fél évre nyúlik. Ilyenkor okosabb egy kész szerverrel vagy egy egyszerűbb n8n-munkafolyamattal kezdeni.

Buktatók, amelyekre az átállásnál figyelj

Egy működő MCP-szerver átköltöztetésénél az alábbi részleteket a legkönnyebb elnézni:

• Az állapot nem tűnt el, csak átköltözött. A szerver által kiadott azonosítók a beszélgetésen keresztül utaznak, ezért a szervernek minden hívásnál ellenőriznie kell, hogy az azonosító az adott felhasználóhoz tartozik-e, különben egy kitalált vagy elcsípett azonosítóval valaki más piszkozatához is hozzá lehetne férni.
• A fejléc csak ellenőrzés után megbízható. Ha az átjáród a fejlécek alapján korlátoz vagy irányít, a specifikáció szerint a régebbi protokollverziót jelző kéréseket ajánlott elutasítania, mert azoknál a szerver nem vetette össze a fejlécet a törzzsel.
• Túl korai vagy túl késői lekapcsolás. Ha a régi útvonalat túl korán kapcsolod le, a frissítetlen kliensek egyik napról a másikra leállnak, ha túl későn, akkor két kódágat tartasz karban, a régi, gyengébb hitelesítés pedig nyitva marad.
• Eltérő kliensek, eltérő ütem. A Claude, a ChatGPT, a Copilot és az n8n nem egyszerre frissít, ezért az átmeneti időben mindegyikkel külön tesztelj.
• Megváltozott hibakódok. A nem található erőforrás hibakódja -32002-ről -32602-re változott, a fejléc-eltérés a -32020-as kódot kapta, így a hibakódokra épülő figyelő- és riasztási szabályokat is frissíteni kell.

Miben segít a Convergo?

A Convergo abban segít, hogy az MCP-integrációid ne egy váratlan hibaüzenetnél kerüljenek elő, hanem tervezetten álljanak át az új specifikációra. Egyedi AI-integráció szolgáltatásunk keretében felmérjük a meglévő MCP-kapcsolataidat, rangsoroljuk a teendőket és elvégezzük az átállítást. Ha Odoo-t használsz, az Odoo ERP és integrációk csapatunk feladatra szabott, jogosultságkezelt MCP-szervert tervez a JSON-2 API-ra, egyedi ügyfélnyilvántartásnál pedig ugyanezt az egyedi CRM és webes rendszerek szolgáltatásunk keretében tesszük meg. Az első lépés egy ingyenes egyeztetés, ahol közösen átnézzük, melyik integrációdat érinti az MCP 2026-07-28 és mennyi munkával jár az átállás.