> Az MCP 2026-07-28 kivezeti a sessionöket és az initialize kézfogást. Szerveroldal: _meta, server/discover, MRTR, engedélyezés, migrációs ellenőrzőlista.
>
> Web page: https://balazscsorba.com/hu/blog/mcp-2026-07-28-stateless-migration-guide · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/mcp-2026-07-28-stateless-migration-guide.md) · [Deutsch](https://balazscsorba.com/de/blog/mcp-2026-07-28-stateless-migration-guide.md)
> Author: Balázs Csorba · Published: 2026-07-29 · Updated: 2026-09-01 · Keywords: mcp 2026-07-28, állapotmentes mcp, mcp migrációs útmutató, mcp sessionök eltávolítása, mcp-session-id eltávolítása, mcp server/discover, mcp többlépéses kérések, hogyan migráljunk mcp szervert az új specifikációra, mcp cimd kliensazonosító metaadat, mcp roots sampling logging elavult

[Blog](https://balazscsorba.com/hu/blog)/[MI-ügynökök](https://balazscsorba.com/hu/blog/category/agents)

# MCP 2026-07-28 migrációs útmutató: mi változik az állapotmentes MCP szervereknél

Az MCP 2026-07-28 kivezeti a sessionöket és az initialize kézfogást. Szerveroldal: \_meta, server/discover, MRTR, engedélyezés, migrációs ellenőrzőlista.

[Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. július 29.·frissítve 2026\. szeptember 1.·9 perc olvasás

-   [MCP](https://balazscsorba.com/hu/blog/tag/mcp)
-   Protocol migration
-   Stateless APIs
-   OAuth
-   Agents

![MCP 2026-07-28 migrációs útmutató: egy robot több egyforma automata egyikét használja, régi gépet szállítanak el.](https://balazscsorba.com/images/blog/mcp-2026-07-28-stateless-migration-guide/cover.webp?v=e9fbdaee62)

## A lényeg röviden

-   Az MCP 2026-07-28, 2026. július 28-án kiadva, eltávolítja az initialize kézfogást és az Mcp-Session-Id fejlécet, így minden kérés maga hordozza a verzióját és a képességeket.
-   A szervereknek implementálniuk kell a server/discover-t; a kliensek hívhatják elsőként, vagy küldhetnek bármilyen kérést, és kezelniük kell az UnsupportedProtocolVersionError-t.
-   A Multi Round-Trip Requests leváltja a szerver által kezdeményezett elicitationt, samplinget és rootsot: a szerver input\_required eredményt ad vissza, a kliens pedig inputResponses-szal újraküldi.
-   A hívások közötti állapot explicit handle-ökbe kerül, amelyek eszközargumentumként mennek tovább, a requestState-et pedig integritásvédetten kell kezelni, mert támadó kontrollálja.
-   A Roots, a Sampling, a Logging és a Dynamic Client Registration deprecated, a legkorábbi eltávolítás a 2027. július 28-án vagy később megjelenő első revízióban esedékes.

Ezen az oldalon

1.  [Miért dobta el az MCP a sessionöket?](https://balazscsorba.com/#why-sessions-were-dropped)
2.  [Hogyan működik egy állapotmentes MCP kérés?](https://balazscsorba.com/#how-stateless-mcp-works)
3.  [Mi váltja fel a szerver által kezdeményezett kéréseket? Multi Round-Trip Requests](https://balazscsorba.com/#multi-round-trip-requests)
4.  [Hová kerül most az állapot? Handle-ök, Tasks és subscriptions](https://balazscsorba.com/#state-tasks-subscriptions)
5.  [Mi változott az MCP engedélyezésében?](https://balazscsorba.com/#authorization-changes)
6.  [Mi deprecated, és mikor ne siessünk a migrációval?](https://balazscsorba.com/#deprecations-and-trade-offs)
7.  [MCP 2026-07-28 migrációs checklist és tesztterv](https://balazscsorba.com/#migration-checklist)
8.  [Források](https://balazscsorba.com/#sources)

Cikk meghallgatása

0:00

Az **MCP 2026-07-28** a Model Context Protocol 2026. július 28-án kiadott revíziója, és az állapottartó, sessionalapú protokollból állapotmentes kérés/válasz protokollt csinál belőle. Az `initialize` kézfogás és az `Mcp-Session-Id` fejléc eltűnt, minden kérés leírja magát, és a szerverek egy hívás közben már nem küldhetnek kérést a kliensnek. Bárki számára, aki MCP szervert üzemeltet, ez a legnagyobb breaking change, ami a távoli MCP megjelenése óta volt.

Ez a cikk megmutatja, mi változik valójában annak, aki MCP szervert ír, 2026. szeptemberében: hogyan áll össze egy állapotmentes kérés, mi váltja fel a szerver által kezdeményezett kéréseket, hová kerül a hívások közötti állapot, mi változott az engedélyezésben, és mikor jönnek a deprecated feature-ök. Jön egy migrációs checklist is, egy teszttervvel. Minden alább a hivatalos [changelogből](https://modelcontextprotocol.io/specification/2026-07-28/changelog) és a [kiadási bejegyzésből](https://blog.modelcontextprotocol.io/posts/2026-07-28/) származik; ahol a spec szövege az igazság forrása, oda linkelek. A kódhoz mellé érdemes nézni a [hivatalos referenciaszervereket](https://balazscsorba.com/hu/blog/mcp-reference-servers).

## Miért dobta el az MCP a sessionöket?

Az MCP azért dobta el a protokollszintű sessionöket, mert azok miatt nehezen lehetett szervert skálázni: egy session egy szerverpéldányon élt, így minden későbbi kérésnek ugyanazt a példányt kellett elérnie. Ha megszűnnek, bármelyik kérés bármelyik példányra kerülhet egy szokásos load balancer mögött.

A [2026-os roadmap](https://blog.modelcontextprotocol.io/posts/2026-mcp-roadmap/) (2026. március 9.) a „Transport Evolution and Scalability” témát teszi az első helyre a négy prioritás közül, és közvetlenül megnevezi a problémát: az állapottartó sessionök összeütköznek a load balancer-ekkel, a horizontális skálázáshoz pedig kerülőutak kellettek. A gyakorlatban ez sticky routingot, megosztott session store-t vagy mindkettőt jelentette. A serverless platformoknál rosszabb volt a helyzet, mert ott eleve nincs hosszú életű folyamat, amely egy sessiont tartana.

A kiadási bejegyzés egy mondatban megfogalmazza a célt: minden kérés mostantól bármelyik szerverpéldányra kerülhet egy egyszerű round-robin load balancer mögött, közös tároló nélkül. A changelog 9 nagy és 12 kisebb változást sorol fel az előző revízióhoz, a 2025-11-25-höz képest. A nagyok többsége ennek az egyetlen döntésnek a következménye.

## Hogyan működik egy állapotmentes MCP kérés?

Egy állapotmentes MCP kérés magában hordoz mindent, amire a szervernek szüksége van: a protokollverzió és a kliens képességei minden hívásban a `_meta` mezőben utaznak, a HTTP kérések pedig a fejlécekben megismétlik a metódust és az eszköz nevét. Nincs kézfogás, amit meg kellene jegyezni.

A 2025-11-25 alatt a kliens `initialize`\-t küldött, visszakapta a képességeket és egy session ID-t, megerősítette `notifications/initialized`\-del, majd a session ID-t minden hívásra rátette. A 2026-07-28 alatt die [verziózási szabályok](https://modelcontextprotocol.io/specification/2026-07-28/basic/versioning) kérésenként érvényesek:

-   Az `io.modelcontextprotocol/protocolVersion` és az `io.modelcontextprotocol/clientCapabilities` minden kérés `_meta` mezőjében kötelező. Egy kérés, amelyben ezek nincsenek, hibás, és `-32602`\-t (Invalid params) kap HTTP 400-zel.
-   Az `io.modelcontextprotocol/clientInfo` legyen minden kérésben, a szerverek pedig adják vissza az `io.modelcontextprotocol/serverInfo`\-t minden eredmény `_meta` mezőjében. Mindkettő önbevallás, és nem szabadhat biztonsági döntéseket.
-   Ha a szerver nem támogatja a kért verziót, `UnsupportedProtocolVersionError`\-t (`-32022`) ad vissza egy `supported` listával, és a kliens a lista egyik verziójával újrapróbálkozik.
-   A szervereknek **kötelező** implementálniuk az új `server/discover` RPC-t, amely verziókat, képességeket és identitást hirdet. A kliensek _hívhatják_ elsőként, de nem kötelesek.
-   Streamable HTTP-n a POST kéréseknek hordozniuk kell az `MCP-Protocol-Version`, `Mcp-Method`, és `tools/call`, `resources/read` illetve `prompts/get` esetén a `Mcp-Name` fejlécet ([SEP-2243](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http)). Ha egy fejléc ellentmond a törzsnek, a szerver 400-at ad `HeaderMismatch` hibával (`-32020`). A gatewayek és a WAF-ek mostantól fejlécek alapján tudnak útvonalazni és sebességkorlátot szabni anélkül, hogy JSON-t parseolnának.

![Állapottartó MCP 2025-11-25 és állapotmentes MCP 2026-07-28 egymás mellett: a session egy példányhoz köt.](https://balazscsorba.com/images/blog/mcp-2026-07-28-stateless-migration-guide/diagram-10.webp?v=7b1863980a)

Előtte és utána. 2025-11-25-ben a kézfogás létrehoz egy sessiont, ami egyetlen példányhoz rögzíti a klienst. 2026-07-28-ban minden kérés a \_meta mezőben hordozza a protokollverzióját és a kliens képességeit, a server/discover opcionális a kliensnek, és bármelyik példány válaszolhat.

Egy tools/call kérés az új revízióban így néz ki (szemléltető példa, a spec mezőneveit követve):

HTTP

```
POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search_issues

{"jsonrpc": "2.0", "id": 7, "method": "tools/call",
 "params": {"name": "search_issues", "arguments": {"query": "status = Open"},
  "_meta": {
    "io.modelcontextprotocol/protocolVersion": "2026-07-28",
    "io.modelcontextprotocol/clientCapabilities": {"elicitation": {}},
    "io.modelcontextprotocol/clientInfo": {"name": "my-agent", "version": "1.4.0"}
  }}}
```

## Mi váltja fel a szerver által kezdeményezett kéréseket? Multi Round-Trip Requests

A Multi Round-Trip Requests (MRTR, SEP-2322) a szervertől a kliens felé menő `elicitation/create`, `sampling/createMessage` és `roots/list` kéréseket váltja fel. Ahelyett, hogy a szerver egy nyitva tartott streamen, a hívás közben meghívná a klienst, egy „input required” eredménnyel zárja a kérést, a kliens pedig újraküldi az eredeti kérést, a válaszokkal együtt.

Az [MRTR oldal a specben](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/mrtr) definiálja a folyamatot. A szerver `InputRequiredResult`\-et ad vissza `resultType: "input_required"` mezővel, egy `inputRequests` térképpen (a kulcsok a szerver által választott ID-k, az értékek elicitation, sampling vagy roots kérések), és egy opcionális, átlátszatlan `requestState`\-tel. A kliens összegyűjti a válaszokat, majd újraküldi az eredeti hívást `inputResponses`\-szal, ugyanazokkal a kulcsokkal, visszaküldi a `requestState`\-et, és új JSON-RPC id-t használ. Ezzel az első kérés befejeződött; az újraküldés önálló kérés, amelyet bármelyik példány kezelhet.

![Multi Round-Trip Request: a szerver input_required választ ad, a kliens a felhasználótól kérdez, majd második hívást küld.](https://balazscsorba.com/images/blog/mcp-2026-07-28-stateless-migration-guide/diagram-16.webp?v=0cd6e2fb26)

MRTR: a szerver soha nem hívja a klienst. Visszaadja az input\_required eredményt a kérdésekkel és egy átlátszatlan requestState-tel, a kliens megkérdezi a felhasználót, és egy második, önálló tools/call hozza vissza a válaszokat.

Egy megerősítést igénylő eszköz rövidített közbenső eredménye így néz ki:

JSON

```
{"jsonrpc": "2.0", "id": 1, "result": {
  "resultType": "input_required",
  "inputRequests": {
    "confirm_transition": {
      "method": "elicitation/create",
      "params": {"mode": "form", "message": "Move PROJ-42 to Done?",
        "requestedSchema": {"type": "object",
          "properties": {"confirm": {"type": "boolean"}}, "required": ["confirm"]}}
    }
  },
  "requestState": "<HMAC-protected blob>"
}}
```

A spec három szabálya megváltoztatja, hogyan írod ezt a kódot:

-   **A `requestState` támadó által kontrollált bemenet.** Ha hatással van az engedélyezésre, az erőforrás-hozzáférésre vagy az üzleti logikára, meg kell védened az integritását (HMAC vagy AEAD), és el kell utasítanod azokat az állapotokat, amelyek nem mennek át az ellenőrzésen. A spec azt javasolja, hogy kösd bele a hitelesített Principalt, egy rövid lejáratot és az eredeti kérés digestjét. Ha egy állapotot legfeljebb egyszer szabad használni, ezt szerveroldalon kényszerítsd ki.
-   **Csak a `tools/call`, a `prompts/get` és a `resources/read`** adhat vissza `InputRequiredResult`\-et, és csak olyan kérés típusokkal, amelyeket a kliens a képességeiben deklarált.
-   **Minden eredményhez most `resultType` kell:** `"complete"` a normál eredményekhez. A kliensek a régebbi szerverektől érkező hiányzó mezőt complete-nek tekintik, az új szerver viszont mindig küldje el.

Az MRTR az időzítést is megváltoztatja. A kliens lehet, hogy soha nem küldi újra, ezért egy eszköz nem hagyhat félkész munkát hátra, amíg a válaszra vár. A mellékhatást a megerősítés után vidd végbe, nem előtte.

## Hová kerül most az állapot? Handle-ök, Tasks és subscriptions

A hívások közötti állapot kikerül a transportból az eszközökbe: egy eszköz explicit handle-t gyárt, visszaadja, a modell pedig szokásos argumentumként adja tovább. A hosszú futású munka a Tasks extensiont használja, az változásértesítések pedig az új `subscriptions/listen` streamet.

### Explicit handle-ök

A [tools spec](https://modelcontextprotocol.io/specification/2026-07-28/server/tools) egy kosarat használ példaként: a `create_basket` a `bsk_a1b2c3`\-at adja vissza, az `add_item` pedig a `basket_id`\-t veszi paraméterként. A kiadási bejegyzés szerint ez jobban működik, mint a rejtett session-állapot, mert a modell látja a handle-t, és átadja az egyik eszköztől a másiknak. A spec design-megjegyzéseit érdemes átvenni a review checklistédbe: hitelesített szervereknél a handle név, nem jogosultság, ezért hívásonként ellenőrizd a hívó engedélyeit; a handle-ök maradjanak átlátszatlanok; a létrehozó eszköz leírásában mondd ki a megőrzési szabályt; és lejárt handle esetén adj egy eszközhívási hibát (tool execution error) vissza, hogy a modell maga kijavíthassa.

### Tasks és subscriptions

A Tasks kikerült az experimentális magból a hivatalos `io.modelcontextprotocol/tasks` extensionbe (SEP-2663). A blokkoló `tasks/result` helyére polling jön `tasks/get`\-tel, az új `tasks/update` a kliens felől érkező bemenetet szállítja, a `tasks/list` pedig megszűnt. Az extensionöket egy új `extensions` mező egyezteti ki a kliens- és szerverképességekben.

A régi HTTP GET végpont és a `resources/subscribe` helyére a `subscriptions/listen` lép: egyetlen hosszú életű POST válaszstream, amelyben a kliens feliratkozik olyan értesítéstípusokra, mint a `toolsListChanged`. A stream folytathatósága is eltűnt: ha a válaszstream elszakad, elveszik a folyamatban lévő kérés, és a kliensnek új azonosítóval újra kell küldenie. Ez az idempotencia a te problémád. Ha egy eszközhívás kétszer is elküldhető, akkor biztonságosan kétszer lefuthat, vagy hordozzon egy kulcsot, amivel felismered a duplikátumot.

A listázási eredményeket olcsóbb cache-elni. A `tools/list`, `prompts/list`, `resources/list`, `resources/read` és `resources/templates/list` tartalmaznia kell a `ttlMs` és `cacheScope` mezőket (`"public"` vagy `"private"`), és a szervereknek determinisztikus sorrendben kell visszaadniuk az eszközöket. A stabil eszközlista melegen tartja a kliens prompt cache-ét, és ez költségkérdés (lásd [prompt caching és routing](https://balazscsorba.com/hu/blog/llm-cost-latency-prompt-caching-routing)).

## Mi változott az MCP engedélyezésében?

A 2026-07-28 engedélyezési változások lezárom egy engedélyezőszerver-összekeveredési rést, a kliens credentialöket ahhoz a szerverhez kötik, aki kiállította őket, és formálisan elavultnak jelölik a Dynamic Client Registrationet a Client ID Metadata Documents (CIMD) javára.

-   **Issuer-validáció (SEP-2468).** Az engedélyezőszervereknek az `iss` paramétert kellene bele foglalniuk az engedélyezési válaszba a [RFC 9207](https://www.rfc-editor.org/rfc/rfc9207) szerint, a klienseknek pedig egy jelen lévő `iss`\-t ellenőrizniük kell a rögzített issuer ellen, mielőtt beváltják a kódot.
-   **Credentialök issuer szerint kulcsolva (SEP-2352).** A klienseknek a tárolt credentialöket issuer-azonosító szerint kell kulcsolniuk, nem szabad más engedélyezőszerverrel újrahasznosítaniuk őket, és újra kell regisztrálniuk, ha az engedélyezőszerver megváltozik.
-   **`application_type` a regisztrációnál (SEP-837).** Ezért láttak egyes desktop- és CLI-kliensek `redirect_uri` hibákat a localhost callbackeknél.
-   **CIMD DCR helyett.** A [CIMD](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration) esetén a kliens ID egy HTTPS URL, amely egy JSON dokumentumra mutat, amiben legalább `client_id`, `client_name` és `redirect_uris` van. Az engedélyezőszerverek a `client_id_metadata_document_supported` mezővel jelzik a támogatást. A DCR a visszafelé kompatibilitás miatt még mindig működik.

Ha a szervered csak tokeneket validál, ennek nagy része a kliensre és az engedélyezőszerverre esik. A te szervered feladata nem változik, és továbbra is szigorú: csak azokat a tokeneket fogadd el, amelyek neked lettek kiállítva, és soha ne add tovább őket felsőbb szintű API-knak. Az [MCP szerver biztonsági checklist](https://balazscsorba.com/hu/blog/mcp-server-security-checklist) foglalkozik ezzel az oldallal.

## Mi deprecated, és mikor ne siessünk a migrációval?

A Roots, a Sampling és a Logging deprecated (SEP-2577), és ugyanígy a Dynamic Client Registration és a régi HTTP+SSE transport. Eddig semmit nem távolítottak el, szóval a valódi trade-off nem az, hogy „migrálok vagy törem”, hanem hogy mennyi ideig üzemeltetsz egy szervert, amely még mindkét korszakot szolgálja.

A [deprecated feature-ök registryje](https://modelcontextprotocol.io/specification/2026-07-28/deprecated) a Roots, a Sampling, a Logging és a DCR legkorábbi eltávolítását arra a revízióra teszi, amely 2027. július 28-án vagy később jelenik meg. A javasolt migrációk konkrétak: a könyvtárakat add át eszközparamétereken vagy konfiguráción keresztül a Roots helyett, hívd közvetlenül az LLM szolgáltatót a Sampling helyett, és logolj `stderr`\-re vagy OpenTelemetrybe a Logging helyett. A `ping` és a `logging/setLevel` már kikerült a protokollból; a log szint most kérésenként mint `io.modelcontextprotocol/logLevel` utazik.

A terepen lévő kliensek nem egyszerre fognak átállni, ezért a spec definiál egy [visszafelé kompatibilitási utat](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http). Egy modern kliens először modern kéréssel próbál, és csak akkor esik vissza az `initialize`\-re, ha egy 400 válasz törzse nem modern JSON-RPC hiba. Egy szerver, amely csak az új revíziót beszéli, a HTTP GET és DELETE kérésekre 405-öt válaszoljon, hagyja figyelmen kívül az `Mcp-Session-Id`\-t anélkül, hogy kiállítana egyet, és hagyja figyelmen kívül a `Last-Event-ID`\-t.

A véleményem: ha minden kliensed SDK-alapú, és te irányítod őket, egy lépésben migrálj. Ha olyan harmadik felek hosztjait szolgálod ki, amelyeket nem kontrollálsz, futtasd egy ideig mindkét korszakot, és figyeld az `MCP-Protocol-Version`\-t a hozzáférési naplókban, hogy eldöntsd, mikor ejtsd el a legacy útvonalat. A négy Tier 1 SDK (TypeScript, Python, Go és C#) támogatja a revíziót, Rustban beta, így a migráció nagyrészt SDK-frissítés meg a fenti designváltozások.

2025-11-25 mechanizmus

2026-07-28

Mit kell változtatni a szervereden

az `initialize` kézfogás

Eltávolítva; verzió és képességek minden `_meta`\-ban

Olvasd kérésenként; adj vissza `-32022`\-t a támogatott verziókkal

Semmi

`server/discover` (a szervereknek implementálniuk kell)

Hirdesd a verziókat, képességeket és az identitást

`Mcp-Session-Id`

Eltávolítva

Vidd az állapotot explicit, autorizált handle-ökbe

Szerver által kezdeményezett elicitation, sampling, roots

MRTR: `input_required` + újraküldés

Adj vissza `InputRequiredResult`\-et; írd alá a `requestState`\-et

GET stream, `resources/subscribe`

`subscriptions/listen`

A GET és DELETE kérésekre 405-öt válaszolj

`Last-Event-ID` folytathatóság

Eltávolítva

Tedd biztonságossá az eszközhívások újraküldését

Experimentális tasks, `tasks/result`

Tasks extension, `tasks/get` polling

Pollolj; hagyd ki a `tasks/list`\-et

Csak JSON törzs

`Mcp-Method` / `Mcp-Name` fejlécek

Utasítsd el a fejléc-törzs eltéréseket (`-32020`)

Nem található erőforrás `-32002`

`-32602`

Frissítsd a hiba-leképezést és a teszteket

## MCP 2026-07-28 migrációs checklist és tesztterv

Egy MCP szerver átállítása 2026-07-28-ra lényegében arról szól, hogy frissítsd az SDK-t, vedd ki minden sessionre épülő feltételezést, és bizonyítsd, hogy két egymás utáni kérés két különböző példányra eshet. Ebben a sorrendben dolgoznék:

1.  **Frissíts egy Tier 1 SDK-ra, amely 2026-07-28-at beszél,** és előbb olvasd el a migrációs jegyzeteit; az SDK-k elnyelik a legtöbb transportváltozást.
2.  **Keress a kódodban session ID-kre** és kapcsolatonkénti cache-ekre. Mindegyiket cseréld explicit handle-re vagy a kérésben szereplő adatra.
3.  **Implementáld a `server/discover`\-t,** és add vissza a `serverInfo`\-t az eredmény `_meta` mezőjében.
4.  **Írd át minden szerver által kezdeményezett kérést MRTR-re,** ahol a `requestState` integritása védett, és kösd a felhasználóhoz, a lejárathoz és a kéréshez.
5.  **Add hozzá a `resultType`, `ttlMs` és `cacheScope` mezőket,** és rendezd a `tools/list`\-et determinisztikusan.
6.  **Ellenőrizd az `Mcp-Method` és `Mcp-Name` fejléceket** a törzssel szemben, és frissítsd a hibakódokat (`-32602`, `-32020` → `-32022`).
7.  **Cseréld le a Roots, Sampling és Logging elemeket** eszközparaméterekkel, közvetlen szolgáltatóhívásokkal és OpenTelemetryvel. A trace kontextusnak mostantól dokumentált `_meta` kulcsai vannak (`traceparent`, SEP-414).
8.  **Döntsd el, meddig tartasz mindkét korszakot,** és naplózd minden kérés protokollverzióját.

### Tesztterv

-   Futtass két példányt round-robin mögött, és a több hívásból álló munkafolyamat minden lépését küldd a másikra.
-   Szakíts meg egy válaszstreamet a hívás közben, és ellenőrizd, hogy az újraküldött hívás nem végez dupla munkát.
-   Módosítsd, játsszad vissza és járts le egy `requestState`\-et; mindhármat el kell utasítani.
-   Mutass be egyik felhasználó handle-jét a másik felhasználó tokenjével; ennek el kell buknia.
-   Irányíts egy régi 2025-11-25 klienst a szerverre, és erősítsd meg a választott visszaesést.

Az állapotmentes transport megváltoztatja azt is, hogyan kell gondolkodni az eszköztervezésen, mert a handle-ök és a megerősítések mostantól az eszközeid sémáiban vannak. Ha a saját szervereidre tervezel ilyen migrációt, az része annak, amit [AI mérnökként](https://balazscsorba.com/hu/expertise/ai-engineer) csinálok.

## Források

1.  [The 2026-07-28 Specification](https://blog.modelcontextprotocol.io/posts/2026-07-28/) – MCP blog, 2026. július 28.
2.  [MCP 2026-07-28 Key Changes (changelog)](https://modelcontextprotocol.io/specification/2026-07-28/changelog)
3.  [MCP 2026-07-28: Versioning and Compatibility](https://modelcontextprotocol.io/specification/2026-07-28/basic/versioning)
4.  [MCP 2026-07-28: Streamable HTTP transport](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http)
5.  [MCP 2026-07-28: Multi Round-Trip Requests](https://modelcontextprotocol.io/specification/2026-07-28/basic/patterns/mrtr)
6.  [MCP 2026-07-28: Tools (state handles)](https://modelcontextprotocol.io/specification/2026-07-28/server/tools)
7.  [MCP 2026-07-28: Client registration (CIMD)](https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization/client-registration)
8.  [MCP 2026-07-28: Deprecated features registry](https://modelcontextprotocol.io/specification/2026-07-28/deprecated)
9.  [The 2026 MCP Roadmap](https://blog.modelcontextprotocol.io/posts/2026-mcp-roadmap/) – MCP blog, 2026. március 9.
10.  [RFC 9207: OAuth 2.0 Authorization Server Issuer Identification](https://www.rfc-editor.org/rfc/rfc9207)

## Gyakori kérdések

Támogatja még az MCP 2026-07-28 az initialize kézfogást?

Nem. A 2026-07-28 revízió eltávolítja az initialize-et és a notifications/initialized-et. Helyette minden kérés a \_meta mezőben hordozza a protokollverzióját és a kliens képességeit. Egy szerver továbbra is kiszolgálhat régebbi klienst úgy, hogy a 2025-11-25 viselkedést is implementálja, a modern kliensek pedig akkor esnek vissza az initialize-re, ha egy 400 válasz törzse nem felismert modern JSON-RPC hiba.

Hogyan tartsak állapotot az MCP eszközhívások között session nélkül?

Gyárts egy explicit handle-t egy eszközben, például egy kosár- vagy munkafolyamat-azonosítót, add vissza az eredményben, és fogadd el szokásos argumentumként a későbbi hívásokban. Tárold az állapotot szerveroldalon azzal a kulccsal, hívásonként ellenőrizd a hívó engedélyét a handle-re, maradjon a handle átlátszatlan, és adjon a szerver egyértelmű hibát, ha a handle lejárt.

Mi a requestState az MCP Multi Round-Trip Requestsben?

A requestState egy átlátszatlan string, amelyet a szerver az input\_required eredménnyel ad vissza, és a kliens az újraküldéskor visszaküld. Ez teszi lehetővé, hogy egy állapotmentes szerver folytassa a munkáját. A spec támadó által kontrollált bemenetnek tekinti: ha hatással van az engedélyezésre vagy az üzleti logikára, védd HMAC-kel vagy AEAD-del, kösd a felhasználóhoz, egy rövid lejárathoz és az eredeti kéréshez, és utasítsd el, ami nem megy át az ellenőrzésen.

Mikor távolítják el a Roots, a Sampling és a Logging elemet az MCP-ből?

A 2026-07-28 revízióban deprecatedek, de még teljesen működnek. A deprecated feature-ök registryje a legkorábbi eltávolításként azt a spec revíziót adja meg, amely 2027. július 28-án vagy később jelenik meg, a tényleges eltávolítást viszont a maintainer dönti el. A javasolt helyettesítők: a Roots helyett eszközparaméterek vagy konfiguráció, a Sampling helyett közvetlen LLM szolgáltatóhívás, a Logging helyett pedig stderr vagy OpenTelemetry.

Írta: Csorba Balázs

Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket.

[AI fejlesztés és MCP szerverek →](https://balazscsorba.com/hu/expertise/ai-engineer)[Rólam →](https://balazscsorba.com/hu/about)

## További cikkek

-   [Eszközök tervezése AI-ügynököknek: nevek, leírások, sémák és hibaüzenetek](https://balazscsorba.com/hu/blog/agent-tool-design-descriptions-errors)
-   [Böngészőügynökök E2E-teszteléshez: írják az ügynökök a Playwright-teszteket, ne futtassák](https://balazscsorba.com/hu/blog/browser-agents-e2e-testing-playwright)
-   [Az A2A protokoll: agent cardok, taskok, és a helye az MCP mellett](https://balazscsorba.com/hu/blog/a2a-protocol-agent-interoperability)
-   [OpenCode teszt: a nyílt forráskódú kódolóügynök bármely modellhez](https://balazscsorba.com/hu/blog/opencode)

## Pont erre van szükséged?

Írj a projektedről vagy a pozícióról – szívesen hallok felőled.

[Lépj velem kapcsolatba](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)