MCP-architektúra: teljes technikai áttekintés diagramokkal

Az MCP-architektúra azoknak az alapvető komponenseknek és kommunikációs szabályoknak az összessége, amelyek lehetővé teszik az MCP (Model Context Protocol) működését. Az MCP nyílt forráskódú szabvány, az MCP-architektúra pedig az az alapinfrastruktúra, amelyen fut.

Minden MCP-architektúra három alapvető komponensből áll, és ezekre épül: a hostra, a kliensre és a szerverre. Az MCP kommunikációs keretrendszerét gyakran úgy írják le, mint amely egy adatrétegből és egy szállítási rétegből áll. Az adatréteg azoknak a szabályoknak az összessége, amelyek meghatározzák az üzenetek formátumát (az MCP-kéréseket JSON-RPC 2.0 formátumban küldik). A szállítási réteg továbbítja ezeket az üzeneteket, külső kapcsolatok esetén Streaming HTTP használatával.

Az MCP-architektúra egy szerverkeretrendszer, amely a Model Context Protocolt valósítja meg. Ez egy nyílt szabvány, amely az AI-modelleket eszközökhöz kapcsolja, valamint erőforrásokhoz, például adatbázisokhoz, és a bemeneti kontextust bővítő promptokhoz. Ezeket összefoglaló néven „primitíveknek” nevezik. Végső soron az MCP-architektúra lehetővé teszi, hogy az LLM-ek felderítsék, mely eszközök érhetők el, és munkafolyamatokat hajtsanak végre, mindezt anélkül, hogy a kliensoldalon rendszeres frissítésekre lenne szükség.

Az MCP-architektúra diagramja: egy AI-alkalmazás kéréseket vált egy MCP-szerverrel, amely eszközöket, erőforrásokat és promptokat biztosít.

Mióta az Anthropic bemutatta, az MCP-architektúra széles körben elterjedt az AI-munkafolyamatokban. Ez nagyrészt annak köszönhető, hogy a teljesítmény feláldozása nélkül váltja fel a nagyobb karbantartási igényű rendszereket, például a több API-kapcsolatra épülőket. Mivel minden elérhető funkció az MCP-szerver mögött található, csak egyetlen kapcsolatra van szükség, a frissítések és az új funkciók pedig azonnal elérhetők a kliensalkalmazás számára.

Az MCP lehetővé teszi az LLM-ek számára, hogy felderítsék és meghívják a számukra elérhető eszközöket, promptokat és erőforrásokat, akár a hostalkalmazás helyi rendszerén, akár egy külső szolgáltatótól.

Az eszközök esetében, amelyek külső funkciókhoz biztosítanak hozzáférést, a felderítés során a host egy tools/list hívást intéz az MCP-szerverhez, hogy megtudja, mely eszközök érhetők el. Ezután az LLM (vagy bizonyos esetekben a host) elolvashatja az elérhető eszközök leírását, és szükség szerint kérheti azokat. A promptok és az erőforrások hasonló folyamatot használnak.

Az MCP-architektúra komponenseinek diagramja: egy LLM-et, egy orkesztrátort és egy klienst tartalmazó host két lépésben – először felderítéssel, majd kérésekkel – csatlakozik egy MCP-szerverhez, amely eszközöket, erőforrásokat és promptokat tesz elérhetővé.

Ez szemben áll az egyedi, API-alapú architektúrával, amely eddig a szoftverfejlesztés bevett gyakorlata volt, és amelyben az alkalmazáson kívüli funkciókat dedikált kapcsolatokon keresztül, pontosan formázott kérésekkel kellett meghívni.

A hostalkalmazás a központi orkesztrációs platform, amely egy LLM-hez csatlakozik. Az olyan jól ismert eszközök, mint a Perplexity és a Claude Desktop, hostként működhetnek egy MCP-rendszerben.

Egy egyszerű munkafolyamatban a felhasználó a csevegőfelületen keresztül tesz fel egy kérdést. A host orkesztrátor komponense ezután kontextussal egészíti ki a kérdést: közli az LLM-mel, mely MCP-primitívek érhetők el, és leírja azok képességeit.

A kliens az AI-alkalmazás egyik szoftverkomponense. Az MCP szabványos interfészt biztosít ahhoz, hogy a kliens a host vagy az LLM utasításai alapján kommunikáljon a belső és külső MCP-szerverekkel. A feladata a kapcsolat létrehozása, a JSON-RPC-üzenetek formázása, a kérések elküldése és a válaszok fogadása.

Az „MCP-host” és az „MCP-kliens” kifejezéseket néha egymás szinonimájaként használják. A megkülönböztetés azonban hasznos, mert egy host, például a Perplexity, egyszerre több MCP-klienst is koordinálhat. Egy összetett AI-munkafolyamat akár több tucat vagy több száz különálló MCP-szerverhez is igényelhet hozzáférést, és mindegyik külön kapcsolatot használ.

Egy MCP-host – például a Perplexity – diagramja, amely három MCP-klienst koordinál; mindegyik kliens a saját MCP-szerveréhez csatlakozik, például egy adatbázishoz, fájlokhoz vagy egy külső API-hoz.

A szerver az összes olyan eszközt elérhetővé teszi, amelyet az AI-alapú eszköz használhat. Architekturális szempontból az MCP-szerver értelmezi a beérkező kérést, és szükség esetén csatlakozik a kért primitívekhez.

Az MCP-szerverek a primitívek három kategóriájához biztosíthatnak hozzáférést:

Eszközök: Ezek lényegében külső szoftverfunkciók. A hagyományos, API-alapú megközelítésben egy webanalitikai alkalmazás például egy külső szerverhez intézett, formázott kéréssel kérheti le az adatokat. Az MCP-architektúrában egy szolgáltató összes külső funkciója egyetlen kapcsolaton keresztül érhető el, a kérések pedig szabványos formázási szabályok szerint készülnek.
Erőforrások: Az erőforrások olyan adatforrások, amelyek csak olvasható kontextust biztosítanak. Jó példák erre az adatbázissémák. Az MCP-szerver elérhetővé teszi a host számára rendelkezésre álló különféle információforrásokat. Ha a host lekérdezi az adatbázist, például egy LLM által generált SQL-kereséssel, az eszközkérésnek minősül.
Promptok: Ezek újrafelhasználható promptsablonok, amelyek segítik az LLM-eket bizonyos feladatok elvégzésében. A felhasználó vagy a host akkor hív meg eszköz helyett promptot, ha egy feladat elvégzéséhez előre elkészített utasításokra van szükség. A hostalkalmazásokban az előre beállított feladatokat – például a „kód áttekintése” vagy az „adatok elemzése” lehetőséget – gyakran promptként tárolják, amelyeket a felhasználó kiválaszthat.

Érdemes azt is megjegyezni, hogy az MCP és az API nem egymást kizáró technológiák. Az MCP-szerver olyan API-hívásokat is elérhetővé tehet, amelyek egy felderítési kérésre válaszul érhetők el. A lényeg az, hogy ezek karbantartása az MCP-szolgáltató feladata, nem a kliensé.

Az MCP-architektúra adatrétege azoknak a szabályoknak az összessége, amelyek meghatározzák a kérések, a válaszok és az értesítések formátumát. Az üzenetek szabványos nyelve a JSON-RPC.

Minden MCP-architektúra egy alapvető folyamatot követ: (1) a host inicializál és felderítést végez, (2) az MCP-szerver válaszol, (3) a host hívást indít (ezt néha az LLM dönti el), és minden szakasz egy-egy külön JSON-üzenetnek felel meg.

Az MCP adatrétegének diagramja: a felhasználó promptot küld a hostalkalmazásnak, ahol az LLM az MCP-klienssel együtt dolgozik; a kliens kérést küld az MCP-szervernek (eszközök, erőforrások, promptok), és megkapja az eredményt, a host pedig választ ad a felhasználónak.

Nézzük meg két példán keresztül, hogyan működik az eszközfelderítés (ezek az erőforrásokra és a promptokra is vonatkozhatnak):

Eszközök felderítése az LLM-generálás előtt: A host elindítja az MCP-klienst, amely egy tools/list kérést küld (ez az MCP-szerveren elérhető eszközök listája). Az LLM a generálási folyamat során áttekinti ezt, és eldönti, szükség van-e egy adott eszközre, erőforrásra vagy promptra.
Keresési lehetőség biztosítása az LLM számára: Egy ágensalapú rendszerben a host egy felderítési lehetőséget – például a search-tools eszközt – ad hozzá a kontextusbemenethez, és az LLM szükség esetén keresést kérhet.

Az eszközöket, amelyek nagyrészt külső alkalmazásfunkciók, jellemzően az LLM vagy a host választja ki. Az erőforrásokat és a promptokat általában a felhasználó kérésére vagy a host kéri le.

Így néz ki egy képzeletbeli jegyzetalkalmazás tools/list kérése egy MCP-szerver felé:

json

{
  "jsonrpc": "2.0",
  "id": 101,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

Ebben a példában az “id”:101 egy azonosítóval azonosítja a kérést, hogy a kliens párosítani tudja a válaszokat, a “params” mező pedig további információkat tartalmaz a kliensről, például a kliens nevét (notes-app-client) és képességeit.

Válaszul az MCP-szerver visszaadja az eszközdefiníciókat, amelyek tartalmazzák az elérhető eszközök nevét és a hozzájuk tartozó részleteket. A lista tartalmazhat például egy add-task eszközt, amellyel a jegyzetalkalmazás feladatokat hozhat létre egy csatlakoztatott feladatkezelő vagy naptáralkalmazásban, és minden feladathoz címet és prioritást rendelhet.

Így nézhet ki egy kérés:

json

{
  "jsonrpc": "2.0",
  "id": 202,
  "method": "tools/call",
  "params": {
    "name": "add-task",
    "arguments": {
      "title": "Review the draft",
      "priority": "medium"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

A “method” mező jelzi az MCP-szervernek, hogy eszközhívásról van szó, a “name” megadja, melyik eszközt kell meghívni, az “arguments” pedig a szükséges bemeneteket tartalmazza.

Ha az adatréteg azt határozza meg, hogy mi zajlik a kliens és az MCP-szerver közötti kapcsolatban, akkor a szállítási réteg azt, hogy hogyan. Meghatározza az üzenetek továbbításának módját: a konkrét csatornát és azokat a szabályokat, amelyek a kérések és a válaszok kézbesítését szabályozzák.

Az MCP két szállítási módot kínál:

Szabványos bemenet/kimenet: Ezt akkor használják, ha az MCP-szerver ugyanabban a helyi környezetben fut, mint a hostalkalmazás. A kliens a JSON-kérést a szerver szabványos bemenetére írja. A szerver beolvassa, végrehajtja a kért műveletet, és a választ a szabványos kimenetre írja.
Streamable HTTP: Ha az MCP-szerver a hostalkalmazáson kívül fut, az MCP-kliens HTTP POST segítségével küld kéréseket a szervernek. A szerver vagy egyetlen JSON-üzenettel, vagy egy Server-Sent Events (SSE) streammel válaszol. Ez utóbbi egy állandó, „figyelő” csatorna, amely lehetővé teszi, hogy a szerver idővel több üzenetet is visszaküldjön.

A többbérlős MCP-architektúra olyan megvalósítási forma, amely egyszerre több felhasználót (bérlőt) képes kiszolgálni.

Bérlő ebben az esetben lehet egy magánszemély, személyek egy csoportja vagy egy szervezet. A megvalósítás jelentheti azt, hogy minden bérlőhöz külön MCP-szerver fut, hogy egyetlen közös szerverhez biztosítanak hozzáférést, vagy hogy szerverek egy csoportját egy központi átjáró mögé helyezik. Átjáró használata esetén az átjáró a felhasználó identitása vagy a kérés jellege alapján irányítja a kéréseket a megfelelő végpontokhoz.

Ugyanazon az alapelven működik, mint a szabványos MCP-architektúra, de az egyes felhasználói kérések saját munkaterületen futnak (még ha ez közös erőforrásokkal jár is), és hitelesítésük külön történik. Vállalati környezetekben gyakori, és ilyenkor gyakran a közös erőforrásokat részesítik előnyben, mert több MCP-szerver futtatása szükségtelenül költséges lenne.

Hogyan néz ki a gyakorlatban egy teljes, elejétől a végéig tartó MCP-kérés? Nyolc fő szakaszból áll, és mindegyikben egy-egy külön architektúrakomponens vesz részt.

Egy teljes MCP-kérés folyamatábrája nyolc lépésben: eszközfelderítés, felhasználói bemenet, modellfeldolgozás, eszközkiválasztás, kérés, eszközvégrehajtás, eredmény és válaszgenerálás.

Így néz ki egy MCP-eszközhívás a gyakorlatban, az előző példa alapján, amelyben egy jegyzetalkalmazás egy feladatkezelő szolgáltatáshoz csatlakozik:

Eszközfelderítés: A jegyzetalkalmazás (host) az MCP-kliensén keresztül egy tools/list kéréssel lekéri a szerveren elérhető eszközöket. A szerver visszaadja azok nevét, leírását és várt bemeneteit, beleértve az add-task eszközéit is. Ez akár azelőtt is megtörténhet, hogy elküldené a promptot.
Felhasználói bemenet: Az alkalmazásba épített csevegőroboton keresztül kérést küld az LLM-alapú jegyzetalkalmazásnak, például: „Hozz létre egy közepes prioritású feladatot a naptáramban az új piszkozatom áttekintésére.”
Modellfeldolgozás: A host elküldi a kérését és a releváns eszközdefiníciókat az LLM-nek.
Eszközkiválasztás: Az LLM strukturált eszközkérést generál, amelyben megadja az eszközt és annak bemeneteit: add-task, title: Review the draft és priority: Medium. A host ellenőrzi, hogy a művelet engedélyezett-e, majd továbbítja a kérést az MCP-kliensnek, amely JSON-RPC-üzenetet küld.
Kérés: Az MCP-kliens tools/call kérést küld az MCP-szerverének.
Eszközvégrehajtás: Az MCP-szerver meghívja a feladatkezelő alkalmazás API-ját, hogy létrehozzon egy új feladatot a megadott címmel és prioritással.
Eredmény visszaadása: A szerver visszaküldi az eredményt az MCP-kliensnek, amely továbbítja azt a hostnak. A host hozzáadja az LLM-nek átadott információkhoz.
Válaszgenerálás: Az LLM az eredmény alapján választ generál a felhasználónak, például: „Létrehoztam egy közepes prioritású feladatot a piszkozat áttekintésére.”

Az MCP-t és a hagyományos API-architektúrát gyakran összekeverik, pedig egymást kiegészítő technológiák. Az MCP-t kifejezetten AI-alapú alkalmazásokhoz tervezték. Kiküszöböli a több, fixen kódolt API-kapcsolat megvalósításával és kezelésével járó nagy karbantartási terhet.

Azzal, hogy a hostalkalmazás funkciószolgáltatónként vagy belső erőforrásonként egyetlen kapcsolatot kap, az MCP segít orvosolni a túlduzzasztott kontextusbemenet (az összes API felsorolása) vagy a korlátozott, API-alapú alkalmazásszkriptek problémáját.

Ehelyett az MCP-k az eszközlistájuk részeként tehetik elérhetővé az API-kat (pontosabban az API-kat meghívó funkciókat). Amikor egy szolgáltató frissíti az alkalmazását, és új API jelenik meg, vagy ha a dokumentáció megváltozik, egyszerűen frissíti az MCP-szervert. A hostalkalmazás oldalán nincs szükség kódmódosításra.

Az MCP biztonsága a bevezetése óta sok vita tárgya. Bár általában biztonságos technológiának tartják, számos biztonsági kockázattal jár, amelyek közül sok az összetett architektúrájú megvalósításokban jelentkezik hangsúlyosabban.

Az MCP-architektúra lehetséges gyenge pontjai a következők:

Promptinjektálás: Egy felhasználó rosszindulatú promptot illeszt külső adatokba, amelyet az AI-modell tévesen utasításként értelmez.
Túlzott jogosultságú hozzáférés: Az MCP-szerverek akár nagy számú eszközt is elérhetővé tehetnek egy AI-modell számára, ami növelheti a biztonsági problémák lehetőségét (a lehetséges kár hatókörét, az ún. „blast radiust”).
Véletlen adatszivárgás: A rosszul konfigurált megvalósítások azt eredményezhetik, hogy bizalmas információk, például API-kulcsok vagy adatbázis-hitelesítő adatok jutnak el egy LLM-hez.
A helyi rendszer manipulálása: A helyi MCP-szerverek ugyanúgy ki vannak téve a helyi rendszert érintő problémáknak, például a rosszindulatú szkripteknek, mint bármely más alkalmazás, azzal a további kockázattal, hogy az ágensalapú AI-rendszerekre is továbbgyűrűző káros hatással lehetnek.

Egyik probléma sem leküzdhetetlen. Gyakran a bevált intézkedések is elegendők a rendszer biztonságának garantálásához. Az olyan intézkedések, mint az emberi felügyelet bevonása (human in the loop), a bizalmas adatokra vonatkozó szigorú ellenőrzések érvényesítése és a szervereket érő támadások elleni védelem, mind bevett gyakorlatnak számítanak.

Az MCP hasznos és népszerű nyílt szabványnak bizonyult a fejlesztők körében. Kiküszöböli a fixen kódolt API-k számos problémáját az LLM-alapú alkalmazásokban, és jelentősen csökkenti a fejlesztőkre háruló kódolási terhet.

A jövőben az MCP alapját képező host- és szerverarchitektúra szinte biztosan változatlan marad. A jövőbeli újítások a többlépéses munkafolyamatokon átívelő, fejlett ágensalapú képességekre összpontosítanak majd.

Emellett az ágensalapú funkciók bevezetésével erősebb biztonsági védelemre, az AI-rendszerek kiterjedtebbé és összetettebbé válásával pedig skálázható architektúrára – különösen a szállítási rétegben – is szükség lesz.

Mi az MCP-architektúra?

Az MCP-architektúra komponensei: hostok, kliensek és szerverek

Host

Kliens

Szerver

Mi az adatréteg az MCP-architektúrában?

Mi a szállítási réteg az MCP-architektúrában?

Mi a többbérlős MCP-architektúra?

Az MCP-architektúra diagramja: lépésről lépésre

Miben különbözik az MCP-architektúra a hagyományos API-architektúrától?

Biztonságos az MCP-architektúra?

Mi vár az MCP-architektúrára a jövőben?