A Model-Client Protocol (MCP) lényegében egy JSON-RPC-alapú protokoll: kliens (az LLM-et hajtó oldal) és szerver (a képességeket kínáló oldal) között cserél üzeneteket egy kis, rögzített primitívkészleten keresztül. A specifikus primitívek:
- Tools (eszközök): hívható függvények nevekkel, leírásokkal és JSON Schema-val az inputokra. Ez a leggyakrabban említett rész, és a legtöbb éles telepítésben a munkát végzi: például "rendelés lekérése", "adatbázis-lekérdezés", "jegy létrehozása".
- Resources (erőforrások): olvasható kontextus URI-címezéssel — fájl, rekord vagy dokumentum, amelyet a kliens behozhat anélkül, hogy a modellnek külön függvényt kellene hívnia.
- Prompts (promptok): újrahasznosítható sablonok, amelyeket a szerver ajánl, így gyakori munkafolyamatokat nem kell minden alkalommal újra leírni.
Ezeken túl a specifikáció definiál szerverből a kliens felé irányuló képességeket is: Sampling arra ad módot, hogy a szerver a kliens modelljét használja szöveg generálására; az elicitation (2025-06-18-i revízióban került be) lehetővé teszi, hogy a szerver megszakítsa a folyamatot és emberi bemenetet kérjen; a roots pedig azt kommunikálja vissza, mely URI-k vagy könyvtárak érhetők el a szerver számára.
Ezek a primitívek külön-külön nem forradalmiak — az újdonság az, hogy ugyanaz az öt primitív érvényes függetlenül attól, melyik modell, keretrendszer vagy vendor van a kliensoldalon. Ez magában hordozza az MCP értékét, de ugyanakkor a lehetséges hibák forrását is.
Miért szakít más kategóriába az MCP?
A korábbi megközelítésnél LLM-et egy vállalati rendszerhez kötni tipikusan azt jelentette, hogy minden egyes modellre vagy agent-keretrendszerre külön adaptert írtatok: saját konvenciók a függvényhívásra, saját séma-leírások, saját hibakezelés. Több keretrendszer támogatása nem „kétszeres” munkát jelentett — hanem több, inkompatibilis másolatát ugyanannak a logikának.
MCP ezzel szemben egyetlen, egyszer megírt szerződést ad — a megfelelõ kliens bármelyik modell mögött használhatja. Ez mérhetően csökkenti a fenntartási terhet: a karbantartás már nem a támogatott keretrendszerek számával, hanem a rendszerek számával skálázódik.
A lényegi változás viszont az, hogy az integrációs döntés most már nem feltétlenül a kódotoknál történik. Hagyományos API-nál a végpontok, payloadok és verziózás előre meg vannak tárgyalva: a terv megelőzi a kódot. Egy MCP-szerver viszont nem tudja, hogy melyik agent, milyen sorrendben, mely más szerverekkel együtt és milyen emberi céllal fogja meghívni a rendelkezésre álló eszközöket — a terv a kliens (az agent) által, futásidőben komponálódik. Ez alapvetően más kategóriájú probléma, mert a komponálást végző fél már nem a te kódod, hanem egy modell, amely természetes nyelvű leírások alapján dönt, gyakran hónapokkal azután, hogy a leírás készült.
A leírás lett az interfész
A tools JSON Schema-ja megadja a paraméterek formáját — ezt a részt az MCP jól kezeli. Ugyanakkor a tool neve és szöveges leírása határozza meg, hogy az agent mikor használja éppen azt az eszközt, és miért részesítse előnyben egy másik, hasonló eszközzel szemben. Ez két külön feladat, és csak az egyik oldódik meg a jól formált sémával.
Példa: egy rövid, technikailag helyes leírás így nézhet ki:
{ "name": "get_status", "description": "Returns the current status of a record given its ID." }
Egy agent ebből nem fogja tudni, hogy ez melyik domainre vonatkozik, mit jelent a "record", milyen formátumú az ID, vagy hogyan különbözik ez egy másik, hasonló eszköztől. A részletesebb leírás viszont kontextust ad: pontosan milyen rekordról van szó, az ID-formátum példákkal, a visszaadott státuszok jelentésével, és egy megjegyzéssel arról, melyik közeli eszközzel szokott összetévesztés történni és miért.
Sok csapat indított éles MCP-szervert, amely technikailag korrekt volt, mégis az agentek rosszul használták, vagy elkerülték egy jobban leírt, de kevésbé helyes alternatíva javára. Ez nem ‘stack trace’-es hiba, hanem olyan viselkedés, amikor az agent magabiztosan a rossz eszközt hívja, vagy rossz feltevésekkel él, amit csak a downstream kimenet „kicsit furán” jelez. A jó tool-leírás készítése inkább technikai írás és terméktervezés, mint back-end fejlesztés — és sok integrációs csapatnál ez hiányzó készség volt.
Emergens komponíció: előny és kockázat egyszerre
Az MCP vonzereje, hogy egy agent össze tudja kombinálni olyan szerverek eszközeit, amelyek sosem egyeztettek előre együttműködést. Ez viszont strukturális kockázat: a komponálás logikája nem egy ember által előre megírt és review-olt szkriptben él, hanem a modell futásidejű érvelésében, amely minden feladatnál újat generál. Ezt nem lehet egységtesztelni úgy, mintha a döntés előre létezne.
Egy eszköz, amely izoláltan jól működik a szerző által tesztelt inputokkal, rossz eredményt adhat, ha egy agent más sorrendben hívja, vagy egy másik szerver kimenetét adja át neki bemenetként. Az ilyen hibák nem jelennek meg kód-review során, és csak akkor buknak elő, ha egy konkrét, előre nem látott kombináció előáll élesben — gyakran egyszeri, ügyfélre szabott incidensként.
A protokoll reagál a valós üzemeltetési tapasztalatokra
Az MCP nem áll mozdulatlanul; a specifikáció változásai sokat elárulnak arról, hol fájt leginkább a rendszer a termelésben. A 2024 novemberi indulás óta a legnagyobb revízió a 2026. július 28-i specifikáció volt, és minden jelentősebb változás mögött éles működésnél felmerült probléma állt.
Fontosabb változások:
- A protokoll magja stateless lett. Az eredeti megoldás MCP-Session-Id headerrel követte a sessionöket, ami egyetlen szerver esetén működhetett, de horizontálisan skálázott fleet mögött problémákat okozott. A szerver példányok közötti bármelyik képes válaszolni egy kérésre immár zökkenőmentesebb a load balancer-rel.
- Tasks: hosszú lefutású munkák (dokumentumfeldolgozás, többlépcsős jóváhagyások, ember a hurokban) protokoll-szintű fogalommá váltak. Korábban csapatok egyedi polling- és webhook-megoldásokat alkalmaztak, sok eltérésre és hibalehetőségre adva alkalmat.
- MCP Apps: a szerver immár interaktív UI-t is vissza tud adni, nem csak strukturált adatot — ez fontos, ha egy eszköz eredményét embernek kell megtekintenie és jóváhagynia.
- Autorizáció: az autentikációs és autorizációs részt közelebb hozták az OAuth 2.1 és OpenID Connect gyakorlatához.
- Formális deprekációs politika vezeti ki a régi HTTP+SSE transzportot 12 hónapos átmenettel.
Ezek a változások nem „izgalmas olvasmányok”, hanem a két évnyi éles üzem tapasztalatából származó operációs sebek begyógyításai. A mérhető terjedés is jelentős: az hivatalos regiszter közel 10 000 különálló szervert tart számon, a Tier 1 SDK letöltések havi több tízmilliós nagyságrendben futnak, és a TypeScript valamint Python SDK-k egyenként is átlépték az egymilliárd összesített letöltést. A protokoll eredeti szerzőjének versenytársai is hónapokon belül átvették a szabványt — ez a valós skála és a folyamatosan változó specifikáció együtt jó indikátor a protokoll tartósságára.
Kormányzás és biztonság: ahol a munka nagy része még várat magára
A 2026-os független biztonsági kutatások képe nem megnyugtató. Több ezer nyilvánosan regisztrált szerver szkennelésekor a legtöbb helyen találtak fájműveleti mintázatokat, amelyek path traversal-re hajlamosak. Jelentős részük ki volt téve command injectionnek vagy server-side request forgery-nek (SSRF). Dokumentált esetek vannak tool description poisoning-re, ahol a támadás maga abban a szövegben él, amit a modell olvas a döntéséhez, nem pedig a meghívott kódban. Hasonlóan veszélyes a configuration poisoning: a szerver operációs alapértékeinek (például jogosultságok, alapértelmezett beállítások) lopakodó megváltoztatása, amely átmehet egy normál code review-n, mert a rosszindulatú logika konfigurációs állapotban lakik, nem az alkalmazáskódban.
Több magas súlyosságú sebezhetőség is bejelentésre és javításra került, köztük legalább egy nagyobb forgalmú vendor saját éles csomagjában talált missing-authentication hiba.
Ezek nem azt jelentik, hogy el kell kerülni az MCP használatát, hanem azt, hogy ugyanúgy kell kezelni egy protokollt, amely autonóm hívónak komoly jogosultságot ad a rendszereidben: távolságtartóan és a szükséges kontrollokat előre megalkotva.
Ajánlott gyakorlatok a gyakorlatban:
- Minden agenthez explicit, kötelezően érvényesített allowlistet alkalmazz, ahelyett, hogy nyitva hagynád a felfedezést.
- Hitelesíts minden távoli végpontot, és ne engedj meg „belső” forgalomra vonatkozó csendes kivételeket.
- Központosított, változtathatatlan audit naplózd minden eszköhívást, amit az agentek végrehajtanak.
- A titkokat dinamikusan húzd be egy valódi secrets managerből, ne tartsd őket a szerver lokális konfigurációjában.
- A tool-leírásokat kezelj úgy, mint lektorált mérnöki outputot: teszteld valós agent-reakciók ellen, ne csak emberi jóváhagyással.
- Feltételezd, hogy nem tervezett komponációk előbb-utóbb megtörténnek: építs úgy, hogy az eszközök biztonságosan és jól szemléltethetően hibázzanak ilyen esetekben.
- Célzd a jelenlegi specifikációt (például a 2026. július 28-i baseline-t), ne régi példarepozitóriumokat másolj — a stateless mag és az autorizációs változások nem kozmetikai javítások.
Összegzés
Az MCP jogosan többet jelent, mint „még egy API-szabvány”. Nem attól vált fontosabbá, hogy tisztább REST vagy jobb SDK-k jelentek meg, hanem azért, mert megváltoztatta, ki vagy mi végzi el az integrációs munkát futásidőben: a modellek. A protokoll nem szabályoz mindent — például azt, mennyire jól van megírva egy eszköz leírása, hogyan viselkednek az eszközök váratlan komponációban, vagy milyen kormányzási kontrollok vannak élesben — és ezek azok a területek, amelyeket komolyan kell venni, mielőtt éles forgalmat bízol rá.
Ha a kiberbiztonság a feladatod része, a szerző felhívása szerint várják a visszajelzéseket egy jelentéshez: 11 rövid kérdésre lehet válaszolni.
