MCP weboldal-chatbotokhoz: Eszközök csatlakoztatása OAuth-val és jóváhagyásokkal

Az MCP cselekvőképesebbé teszi a weboldal-chatbotokat – de csak egyértelmű határokkal

Az AI-chatbotokhoz készült MCP nem egy csatlakozó, amely hirtelen tetszőleges rendszereket bíz egy weboldal-chatbotra. A Model Context Protocol sokkal inkább egy közös interfészt ír le, amelyen keresztül a modell eszközöket fedezhet fel és hívhat meg: például keresést egy tudásbázisban, jegylekérdezést, időpontfoglalási logikát vagy belső ellenőrzést termékadatok alapján. Ez különösen vonzó a weboldal-chatbotok esetében, mert sok párbeszéd nem ér véget egy egyszerű válasszal. A látogatók a szállítási státuszról, árakról, kapcsolattartási módokról, űrlapokról, elérhetőségről vagy a következő lépésekről érdeklődnek. Eszközök nélkül a bot csak magyarázni tud. Eszközökkel – ellenőrzött és nyomon követhető módon – releváns adatokat kérhet le, vagy előkészített műveleteket indíthat el.

A döntő kérdés ezért nem az: Tud-e a chatbot eszközöket használni? A kérdés így szól: Milyen eszközöket láthat milyen kontextusban, milyen tokennel hívhat meg azokat, milyen emberi jóváhagyással hajthatja végre, és milyen naplózással tudja azokat később megmagyarázni? A végleges, 2026. július 28-i MCP-specifikáció pontosan ezeket Az üzemeltetési kérdéseket szigorítja. Állapotmentessé teszi a magot, kérésenként releváns metaadatokat követel meg, és pontosítja, hogyan függ össze a távoli HTTP-autorizáció, az OAuth, a hatókörök (scopes) és a token-audience kötés.

Mit változtat a 2026-07-28 specifikáció a weboldalért felelős csapatok számára

A legfontosabb architektúraváltozás a stateless core (állapotmentes mag). Egy MCP-szerver nem tételezheti fel, hogy az ugyanazon a kapcsolaton lévő korábbi kérések már létrehozták a kontextust, a kliens képességeit vagy egy munkamenetet. Mindennek, ami a feldolgozáshoz szükséges, az aktuális kérésben kell szerepelnie. Az elosztott weboldal-infrastruktúrák számára ez praktikus: a kérések terheléselosztók, edge-gateway-ek vagy worker-platformok mögött különböző példányokra érkezhetnek. A megvalósítások szempontjából azonban ez azt is jelenti: nincsenek rejtett feltételezések a transzport-munkamenetekről, nincsenek csendes jogosultságok egy előző kapcsolatból, és a chat-beszélgetés nem szolgál biztonsági határként.

Minden kéréshez szükség van a szükséges _meta metaadatokra. Ebbe beletartozik különösen a protokollverzió és a kliens képességei (Capabilities); a kliens-információk hasznosak a megjelenítéshez, naplózáshoz és hibakereséshez, de nem alkalmasak biztonsági bizonyítékként. Ha egy weboldal több bot-példányt, nyelvet vagy ügyfélterületet szolgál ki, ezt a metaadat-réteget tudatosan ellenőrizni és naplózni kell. Nem helyettesíti a szakmai autorizációt, de biztosítja, hogy a szerver megfelelően be tudja sorolni a kéréseket.

A tool-listák dinamikusak, de nem tetszőlegesek

A tools/list a jelenlegi specifikációban lapozható és gyorsítótárazható. A válaszok gyorsítótár-útmutatásokat tartalmazhatnak, mint például ttlMs és cacheScope. Ugyanakkor a sorrendnek determinisztikusnak kell maradnia, amíg a háttérben lévő eszközmennyiség nem változik. Ez több mint teljesítménybeli kozmetika: ha az eszközkatalógusok stabilan rendezettek, a kliensek megbízhatóbban tudják azokat gyorsítótárazni, és a modellkontextusok nyugodtabbak maradnak.

Fontos az autorizáció árnyalata. Az eszközök köre kérésenként változhat a bemutatott autorizáció alapján, például azért, mert egy token csak olvasási jogot engedélyez a támogatási adatokhoz, de írási jogot nem tesz lehetővé a CRM-ben. Ugyanakkor nem ingadozhat véletlenszerűen, az ugyanazon a kapcsolaton lévő korábbi kérések mellékhatásaként. A weboldal-chatbotok számára ebből egyértelmű minta adódik: a látható eszközkatalógus az aktuális kérés szerepköréből, hatóköréből (scope), bérlőjéből (tenant), nyelvéből, kontextusából és kockázatából tevődik össze.

Az eszközleírások nem képezik a bizalom alapját

Az MCP-eszközök leírják a nevüket, bemeneteiket, opcionálisan kimeneteiket és annotációikat. Ezek a metaadatok segítenek a modellnek és a felhasználói felületnek megérteni a funkciót. Azonban nem képeznek biztonsági horgonyt. A specifikáció világosan kimondja, hogy a klienseknek megbízhatatlanként kell kezelniük az eszközök annotációit, kivéve, ha azok megbízható szerverekről származnak. Egy olyan eszközt, amely írásvédettként írja le magát, szerveroldalon mégis úgy kell megépíteni, hogy ne hajtson végre írási mellékhatásokat.

Ez vonatkozik a strukturált eredményekre is. Az outputSchema segít a válaszok validálásában, és nem csak törzsszöveget ad át a modellnek. Ennek ellenére a szervereknek ellenőrizniük kell a bemeneteket, szabályozniuk kell a hozzáférést, kéréskorlátokat (Rate Limit) kell beállítaniuk, és tisztítaniuk kell a kimeneteket. Egy weboldal-chatbot nem veheti át szűretlenül az eszközeredményeket a látható válaszokba, különösen akkor, ha külső API-k, ügyféladatok vagy HTML-közeli tartalmak érintettek.

OAuth: Az MCP-szerver egy védett erőforrás

A Remote-HTTP-MCP esetében a szerepkörök elosztása döntő fontosságú. Egy védett MCP-szerver OAuth Resource Serverként működik. Az MCP-kliens egy Resource Owner (erőforrás-tulajdonos), azaz jellemzően egy felhasználó vagy egy szervezet nevében jár el. Az Authorization Server interakcióba lép a felhasználóval, ha szükséges, és Access Tokeneket állít ki. Az MCP-szervernek biztosítania kell a Protected Resource Metadata-t, hogy a kliensek felfedezhessék a megfelelő Authorization Server-t. Az Authorization Server legalább az egyik felderítési eljárást biztosítja: az OAuth Authorization Server Metadata-t vagy az OpenID Connect Discovery-t; az MCP-kliensnek mindkettőt támogatnia kell.

A termékcsapatok számára ez azt jelenti: a chatbot maga ne kezeljen jelszavakat, API-kulcsokat vagy idegen tokeneket, ha OAuth-folyamat van előlirányozva. A felhasználót egyértelmű jóváhagyáshoz kell vezetnie, ezt követően egy célhoz kötött Access Tokent kell használnia, és az azzal engedélyezett eszközöket láthatóan korlátoznia kell. A kliensregisztrációhoz a Client ID Metadata Documents előnyben részesítettek; a Dynamic Client Registration csak visszamenőlegesen kompatibilis marad, és elavultnak számít (deprecated). Különösen az olyan integrációknál, mint a naptár, CRM, helpdesk, dokumentumtár vagy webáruház-rendszerek, fontos ez a szétválasztás, mert ugyanaz a beszélgetés gyakran vált a nyilvános kérdések és a fiókfüggő műveletek között.

A tokeneket a célforráshoz kell kötni

A jelenlegi autorizációs specifikáció megköveteli az RFC 8707 szerinti Resource Indicatorokat. A kliensnek az autorizációs és tokenkérésekben be kell állítania a resource paramétert, és ezzel meg kell adnia annak az MCP-szervernek a kanonikus URI-ját, amelyhez a tokent szánták. Az MCP-szervernek ellenőriznie kell, hogy az Access Token pontosan az ő erőforrására lett-e kiállítva. A tokeneket nem szabad query stringen keresztül továbbítani, hanem az Authorization Headerben a helyük.

Ez az audience-kötés megakadályoz egy veszélyes rövidítést: az A szolgáltatáshoz szánt tokent nem szabad a B szolgáltatásnál elfogadni vagy továbbadni. A weboldal-chatbotoknak ezért tisztán elhatárolt token-határokra van szükségük MCP-szerverentént és környezetenként. A Preview, Staging és Production környezetek nem használhatják ugyanazt az audience-t, ha különböző erőforrásokat képviselnek. Hasonlóképpen, egy olyan aggregátor, amely több MCP-szervert egyesít egy modell előtt, nem keverheti a tokeneket.

A hatókörök (scopes) UX- és biztonsági szerződést jelentenek

A hatóköröknek kicsiben kell kezdődniük. A specifikáció azt javasolja, hogy a WWW-Authenticate kihívásokból származó scope-útmutatásokat használjuk, és hiányzó jogosultságok esetén tegyünk lehetővé egy step-up folyamatot. A gyakorlatban ez azt jelenti: a látogató először csak olvasási eszközzel dolgozhat. Csak akkor kérdez rá a rendszer célzottan a kiegészítő jóváhagyásra, ha egy műveletnek több jogosultságra van szüksége, például egy jegy létrehozásához, egy fájl megírásához vagy egy rendelés előkészítéséhez.

A jó beleegyezési tervezés (Consent Design) nemcsak az integráció nevét nevezi meg, hanem a hatását is: Milyen adatokat olvas el? Milyen műveletet készít elő? Eltárolnak, elküldenek vagy véglegesen módosítanak valamit külsőleg? A érzékeny műveleteknél a felhasználónak valódi megerősítést kell látnia, és képesnek kell lennie azt visszautasítani. Ez nem egyéni jogi tanácsadás, hanem egy technikai tervezési szabály: a jóváhagyásoknak az emberek számára érthetőnek, a szerverek számára kikényszeríthetőnek és az auditok számára nyomon követhetőnek kell lenniük.

Teherbíró architektúra MCP-vel rendelkező weboldal-chatbotokhoz

Egy robusztus architektúra elválasztja a modellt, az eszközhomlokzatot (Tool Facade) és a célrendszereket. A weboldal-chatbot nem közvetlenül kommunikál minden harmadik féltől származó szolgáltatóval, hanem egy MCP-klienssel vagy Gateway-jel, amely ellenőrzi a protokollverziót, a kliens képességeit, az auth-státuszt, a kéréskorlátokat és az megfigyelhetőséget (Observability). Mögötte MCP-szerverek találhatók az egyes integrációkhoz vagy szakterületekhez. Minden szerver csak azokat az eszközöket deklarálja, amelyek az aktuális kéréshez engedélyezettek, és minden hívást újra validál.

Az eszközhomlokzatnak stabil neveket, szűk bemeneti sémákat és egyértelmű kimeneti sémákat kell használnia. Az eszközneveknek elég egyértelműnek kell lenniük, különösen akkor, ha több szerver kínál hasonló funkciókat, mint például search, create vagy lookup. Az aggregációnál segít egy névtér vagy előtag. A paramétereket úgy kell kialakítani, hogy a modellnek ne kelljen titkos nyers adatokat kitalálnia. Ha egy folyamat több kérésen keresztül fut, a szervernek egy kifejezett, rövid életű handlet kell visszaadnia, és ezt minden következő hívásnál újra fel kell jogosítania.

A második építőelem a felhasználói felület. A látogatóknak látniuk kell, ha egy eszközt meghívnak, milyen bemeneteket küldenek el, és mikor van szükség jóváhagyásra. A tiszta olvasási hozzáférésekhez gyakran elegendő egy átlátható státusz. Az írási, fizetős, külső vagy személyes adatokra vonatkozó műveletekhez tudatosabb megerősítésre van szükség. A specifikáció nyitva hagyja a felületi mintákat, de egyértelműen megköveteli, hogy az alkalmazások tegyék lehetővé az eszközhívások emberi ellenőrzését.

Kiépítési ellenőrzőlista az AI-chatbotokhoz készült MCP-hez

1. Eszközkészlet létrehozása: Mely rendszereket kell csatlakoztatni, mely eszközök csak olvasási jellegűek, melyek módosítják az adatokat, és melyekhez van szükség emberi megerősítésre?
2. Scope-ok meghatározása: A jogosultságokat műveletek szerint kell felosztani, nem pedig belső csapatok szerint. A státuszlekérdezésekhez használt eszköznek más scope-okra van szüksége, mint a létrehozásra, módosításra vagy küldésre szolgáló eszköznek.
3. OAuth-Discovery ellenőrzése: A Protected Resource Metadata, Authorization Server Metadata, kliensregisztráció és átirányítási URI-k tesztelése környezetenként.
4. Audience-kötés kikényszerítése: A tokeneket csak a kanonikus MCP-szerver URI-hoz fogadja el, soha ne adja tovább hibás erőforrásokhoz, és soha ne helyezze azokat URL-ekbe.
5. tools/list determinisztikussá tétele: A stabil rendezés, lapozás, gyorsítótár-útmutatások és autorizációs szűrők együttes tesztelése.
6. A sémák szűken tartása: Validálja a bemeneteket, használjon strukturált kimeneteket, és alapértelmezés szerint tiltsa le a külső $ref célok automatikus hálózati betöltését; opcionálisan csak engedélyezési listával (Allowlist), időkorláttal (Timeout), méretkorláttal és naplózással.
7. Jóváhagyások építése a UI-ban: Tegye láthatóvá az eszköz nevét, célját, bemeneteit, célrendszerét, a scope-frissítést és a visszautasítási opciót.
8. Megfigyelhetőség (Observability) rögzítése: Naplózza a Request-ID-t, eszköznevet, scope-ot, döntést, hibát, látens időt és eredménytípust anélkül, hogy a érzékeny tartalmakat feleslegesen eltárolná.
9. Hibaútvonalak gyakorlása: Kezelje a 401, 403, lejárt tokeneket, hiányzó scope-okat, ismeretlen handle-eket, időtúllépéseket és visszautasított jóváhagyásokat normális termékállapotként.
10. Kicsiben indítani: Először csak egy-két alacsony kockázatú olvasási eszközt élesítsen, majd fokozatosan adja hozzá a step-up-ot, az írási műveleteket és a további integrációkat.

Jellemző hibák a megvalósítás során

A leggyakoribb hiba a túl széles első token. Ha egy weboldal-chatbot az első bejelentkezés után azonnal átfogó írási jogokat kap, minden modell-döntés kockázatosabbá válik. Jobb egy minimális kezdő scope célzott step-up-pál. A második hiba az olyan eszközkatalógus, amely a belső rendszernevekből áll a felhasználói szándékok helyett. Egy modell megbízhatóbban működik egyértelmű, szűken leírt műveletekkel, mint az általános, univerzális végpontokkal.

A harmadik hiba a modellbizalom és a szerverbizalom közötti elválasztás hiánya. A modell javasolhat egy műveletet, de a szerver dönti el, hogy a bemenetek érvényesek-e, a token megfelelő-e, és rendelkezésre áll-e a jóváhagyás. A negyedik hiba a nyomon követhetőség hiánya. Ha később nem világos, hogy melyik eszköz milyen scope-pal mely adatokat olvasta vagy módosította, sem a támogatási, sem a biztonsági feladatok nem üzemeltethetők tisztán.

További elmélyülési lehetőségek

Ez a cikk az MCP-integrációs réteggel foglalkozik: stateless core, tools/list és HTTP-OAuth. A következő cikkek az általános eszközbiztonságot és az üzemeltetést mélyítik el: A jogosultsági modellhez illeszkedik az AI-chatbotok: Eszközök biztonságos használata jogosultságokkal és megerősítésekkel. A konkrét eszközhívásokhoz érdemes elolvasni az AI-chatbot eszközhívások biztonságos kialakítása című cikket. Ha az eszközeredményeknek géppel olvashatónak kell maradniuk, a Strukturált AI-chatbot kimenetek validálása illik ide. Az üzemeltetéshez és a hibakereséshez az AI-chatbot megfigyelhetőség (Observability) a nyomkövetésekhez (Traces), lekérdezésekhez (Retrieval) és eszközökhöz a technikai folytatás.

Hivatalos források

A szakmai alap a végleges MCP-specifikáció 2026-07-28: az MCP Tools oldal, az MCP Authorization, a hivatalos cikk: The 2026-07-28 Specification és a Base Protocol Overview.

Összegzés

Az AI-chatbotokhoz készült MCP akkor válik értékessé, ha a weboldalért felelős csapatok nem nyitott szerszámosládaként, hanem ellenőrzött integrációs rétegként tekintenek rá. A 2026-07-28-as specifikáció jól illeszkedik a modern webes infrastruktúrához: állapotmentes kérések, gyorsítótárazható listák, irányítható HTTP-fejlécek és erőforrásonkénti explicit autorizáció. Ugyanakkor még egyértelműbbé teszi a felelősséget. Az eszközkínálatnak illeszkednie kell az aktuális tokenhez, a érzékeny műveleteknek emberi ellenőrzésre van szükségük, és minden hívást szerveroldalon validálni kell.

A pragmatikus kezdés kicsi: egy olvasási eszköz, egy szűk scope, egy egyértelmű beleegyezési szöveg, determinisztikus eszközfelderítés és jó naplók. Ezt követően további eszközök csatlakoztathatók anélkül, hogy a chatbot fekete dobozzá válna. Így a weboldal-chatbotból nem egy ellenőrizetlen ágens válik, hanem egy nyomon követhető asszisztens, amely pontosan azokat a rendszereket használhatja, amelyek az aktuális felhasználó és az aktuális feladat számára engedélyezve vannak.