Az MCP 2.0 támogatásával egyszerűbbé válik a Mastra skálázása

Megszűnik a munkamenethez kötött kapcsolat

A Mastra 2026. október 21-i bejelentése szerint az új támogatás az MCP 2026-07-28 specifikációjára épül. A korábbi MCP 1.0 működésében a kliens minden kapcsolatot egy initialize kéréssel indított. A szerver ezután munkamenetet hozott létre, egy munkamenetazonosítót küldött vissza, és a további kérésekben ezt is továbbítani kellett.

Ez a megoldás a klienst ahhoz a szerverpéldányhoz kötötte, amely létrehozta a munkamenetet. Ha több szerver működött terheléselosztó mögött, egy újabb kérés olyan példányhoz kerülhetett, amely nem ismerte az azonosítót. Ilyenkor 400-as, session not found hiba jelentkezhetett. A lehetséges kerülőutak a munkamenetekhez kötött útválasztás, vagy egy megosztott munkamenettároló, például a Redis használata voltak. A Mastra szerint ezek működtek, de növelték a bonyolultságot, a késleltetést és adott esetben a költségeket.

Önálló HTTP-kérésként működik minden művelet

Az új specifikáció két fontos változást vezet be. A SEP-2575 eltávolítja az initialize kézfogást, a SEP-2567 pedig megszünteti az Mcp-Session-Id fejlécet és a protokollszintű munkameneteket. Így minden kérés önálló, hagyományos HTTP-kérésként működik.

Ennek köszönhetően bármelyik szerverpéldány válaszolhat egy kérésre, a hagyományos körkörös terheléselosztás pedig működhet munkamenetekhez kötött útválasztás vagy külön munkamenettároló nélkül. Ha egy példány leáll, a terheléselosztó a következő kérést egy másik példányhoz irányíthatja, miközben a kliens folytathatja a munkát.

Az új HTTP-kérések minden esetben tartalmazzák az Mcp-Method fejlécet, az eszközökhöz, promptokhoz és erőforrásokhoz kapcsolódó műveleteknél pedig az Mcp-Name fejlécet is. Ez lehetővé teszi, hogy az átjárók, a sebességkorlátozók és a tűzfalak a kérés törzsének értelmezése nélkül hozzanak döntéseket.

Gyorsítótárazás, felfedezés és felhasználói kérdések

Az olyan listázási műveletek, mint a tools/list és a resources/list, két, HTTP-gyorsítótárazásból átvett jelzést is használhatnak. A ttlMs azt adja meg, meddig marad friss az eredmény, a cacheScope pedig azt jelzi, hogy az eredmény megosztható-e a felhasználók között, vagy csak az adott hívó számára használható újra. A Mastra példájában a tools/list nyilvános, 60 000 ezredmásodperces, a resources/list pedig privát, 30 000 ezredmásodperces gyorsítótár-beállítást kap.

A server/discover metódus az MCP-szerver képességeinek megismerésére szolgál. A Mastrában a getServerInfo() visszaadja többek között a szerver nevét, verzióját és leírását. A válasz tartalmazhatja a támogatott MCP-specifikációs verziókat és a képességeket is.

A requestState funkcióval a szerver egy hívás közben kérdést tehet fel a felhasználónak anélkül, hogy nyitva kellene tartania a kapcsolatot. A Mastra példájában egy eszköz e-mail-címet kér be, majd a válasz folytatásakor a resumeData mezőből olvassa ki azt.

Feladatok, kompatibilitás és frissítés

A korábban kísérleti Tasks funkció hivatalos kiterjesztéssé vált. Egy hosszú ideig futó eszközhívás azonnal visszaadhat egy feladathivatkozást, miközben a háttérben folytatódik a feldolgozás. A kliens a tasks/get segítségével ellenőrizheti, elkészült-e az eredmény. A Mastra jelenleg vizsgálja a Tasks támogatásának lehetőségeit az @mastra/mcp csomagban. Addig a hosszú futású eszközök a context.mcp.progress() segítségével jelezhetik a haladást.

A specifikáció elavultnak minősíti a HTTP plusz SSE átvitelt, a roots, sampling és logging funkciókat, valamint az OAuth Dynamic Client Registration megoldást. Az @mastra/mcp 2.0 már eltávolította az SSE átvitelt, a roots, sampling és Dynamic Client Registration funkciókat, továbbá csak a 2026-07-28 specifikációt használó klienseket fogadja.

A frissítéshez a Mastra a legújabb @mastra/core és @mastra/mcp csomag telepítését javasolja. Ehhez legalább az @mastra/mcp 2.0.0 és az @mastra/core 1.76.0 szükséges. A fejlesztők MCPServer példányt hozhatnak létre, ehhez rendelhetik az eszközeiket, majd regisztrálhatják a szervert a Mastra példányán.