Mi ez, egy mondatban
Az MCP — Model Context Protocol — arra való, hogy az AI-nak ne kelljen minden eszközhöz külön integrációt írni. Egy szabványos protokoll: a szerver leírja, milyen eszközei vannak, a kliens (az agent) pedig ugyanazon a nyelven kérdez, akármelyik szerverről legyen szó.
A gyakorlati haszna innen látszik: ha van MCP-szervered a saját rendszeredhez, akkor bármelyik agent hozzá tud kapcsolódni, amelyik beszéli a protokollt — nem kell mindegyikhez külön fejleszteni.
Ami 2025 óta megváltozott: már nem egy cég protokollja
Ez a legfontosabb aktualizálás, mert sok forrás még mindig „egy modellfejlesztő cég protokolljaként" írja le.
A hivatalos kormányzási dokumentum szerint az MCP ma a Linux Foundation ernyője alatt működő projekt. A kódra és a specifikációra Apache 2.0 licenc vonatkozik, a dokumentációra Creative Commons.
És van egy alapelv, amit érdemes szó szerint ismerni: a technikai kormányzásban a tagság személyekhez kötődik, nem cégekhez — nincsenek konkrét cégeknek fenntartott helyek.
Ez nem formaság. Azt jelenti, hogy az a szabvány, amire az integrációidat építed, nem egyetlen cég üzleti döntésétől függ.
A 2026-os specifikáció nem finomhangolás
A verziószámozás maga is informatív: az MCP dátumos verziókat használ, és a szám azt a napot jelöli, amikor utoljára visszafelé nem kompatibilis változás történt. A jelenlegi: 2026-07-28. Az eddigi sor: 2024-11-05 → 2025-03-26 → 2025-06-18 → 2025-11-25 → 2026-07-28.
Az utolsó lépés az architektúrát írta át:
- Megszűntek a protokollszintű munkamenetek. A munkamenet-azonosító fejléc törölve. Ha egy szervernek hívások között állapotot kell tartania, azt explicit, a szerver által kiadott azonosítóval teszi, ami sima eszközargumentumként utazik.
- Az MCP állapotmentes lett. Törölve a bevezető kézfogás is — minden kérés magával viszi a protokollverziót és a kliens képességeit.
- Új kötelező hívás, amivel a szerver megmondja, milyen verziókat és képességeket támogat.
- Elavulttá vált három korábbi funkció, és formálisan elavult a régi HTTP-alapú átvitel is.
A gyakorlati üzenet: ha egy leírás bevezető kézfogásról vagy munkamenet-azonosítóról beszél, az elavult. Ez 2026 nyara óta így van.
Egy jó hír is jött ugyanekkor: bevezettek egy elavulási szabályzatot. A funkciók állapota aktív / elavult / eltávolított lehet, az elavulási ablak legalább tizenkét hónap (gyorsított esetben is minimum kilencven nap), és van nyilvános nyilvántartás a kivezetett funkciókról. Ez a felnőtté válás jele egy protokollnál.
Mekkora az ökoszisztéma?
Van hivatalos nyilvántartás, és le lehet kérdezni. Megtettem — a teljes regisztert végiglapoztam 2026. szeptember 12-én:
| Mutató | Érték |
|---|---|
| Egyedi szerver | 31 449 |
| Verzióbejegyzés összesen | 101 682 |
| Ebből elavultnak jelölt | 1 182 |
| Távoli végponttal rendelkező bejegyzés | 41 066 |
| A legkorábbi bejegyzés dátuma | 2025. szeptember 8. |
(Saját mérés a hivatalos nyilvántartás API-ján, 1 017 lap végiglapozásával.)
Vagyis egy év alatt több mint harmincezer egyedi szerver — szerverenként átlagosan három közzétett verzióval. A lekérdezés napján is érkezett új bejegyzés.
Két korlát, amit fontos tudni. A nyilvántartás előzetes állapotban van — a fenntartói maguk írják, hogy törő változások vagy adat-visszaállítás előfordulhat. És nem tartalmaz privát vagy belső szervereket, tehát a valódi szám ennél nagyobb.
A harmadik korlát a legfontosabb, és biztonsági: a nyilvántartás kifejezetten leírja magáról, hogy a biztonsági átvizsgálást átdelegálja a csomagregisztereknek és a továbbfeldolgozó piactereknek. Ő maga a névtér-hitelesítéssel és a metaadatokkal foglalkozik.
A hivatalos nyilvántartásba kerülés tehát nem biztonsági tanúsítvány.
A biztonsági oldal
Ez a rész indokolja, miért nem lehet az MCP-t „csak bekötni".
Saját mérés, ugyanaznap, a nemzeti sebezhetőségi adatbázisban:
| MCP-hez köthető sebezhetőség összesen | 78 |
| 2025-ben közzétéve | 23 |
| 2026-ban közzétéve (szeptemberig) | 55 |
| Kritikus | 17 |
| Magas | 38 |
Egy év alatt több mint kétszereződött, és a találatok mintegy 70%-a magas vagy kritikus besorolású.
Négy mintázat emelkedik ki belőlük, és mind a négy tanulságos.
Az első: a referencia-implementációk sem kivételek. A protokoll megalkotóinak egyik saját szerverén kattintás nélküli adatszivárgás volt lehetséges (kritikus, 9,3-as pontszám, 2025 júliusa): az agent olyan üzenetet generált, amiben a támadó által beszúrt hivatkozás rejtve vitte az adatot, és a linkelőnézetet készítő robot magától lekérte. Ugyanaznap két másik hivatalos szerveren is kiderült, hogy ki lehet lépni az engedélyezett könyvtárakból.
A második: a hivatalos fejlesztőeszközök is. A protokoll saját hibakeresője kritikus, 9,4-es pontszámú távoli kódfuttatási hibát kapott, mert nem volt hitelesítés a kliens és a proxy között.
A harmadik, és ez a legbeszédesebb: mind az öt hivatalos SDK ugyanabba a csapdába esett. A Python, a TypeScript, a Go, a Java és a Rust változat mind ugyanazt a hibát hozta — alapértelmezésben nem volt védelem egy adott, régóta ismert hálózati támadás ellen, így egy rosszindulatú weboldal el tudta érni a saját gépeden futó MCP-szervert. Ez nem egy hanyag fejlesztőről szól, hanem arról, hogy a hiba a protokoll körül keletkezett, nem alatta.
A negyedik: a jogosultságellenőrzés rossz rétegben. Egy szervernél három környezeti változót dokumentáltak hozzáférés-vezérlésként — de ezek csak az eszközlistázásnál érvényesültek, a tényleges hívásnál nem. Aki tudta egy eszköz nevét, közvetlenül meghívhatta. A lista szűrése nem jogosultságkezelés — ennél tisztább tankönyvi példa nincs.
És van egy támadás, aminek nincs sebezhetőségi száma, mert nem implementációs hiba: az eszközmérgezés. Egy rosszindulatú szerver olyan eszközleírást ad, ami magát az agentet veszi rá valamire. A publikált demóban az agent kiszivárogtatta a saját konfigurációs fájlját és az SSH-kulcsokat. A ravaszabb változatban a leírás egy másik, megbízható eszköz viselkedését írja felül — a publikált példában egy ártalmatlan összeadó eszköz leírásába rejtve az az utasítás, hogy a levélküldő eszköz mostantól minden levelet a támadó címére küldjön, és ezt ne említse a felhasználónak.
Amit a specifikáció maga mond
Érdemes elolvasni, mert szokatlanul őszinte.
A biztonsági fejezet nyitómondata: a protokoll tetszőleges adathozzáférést és kódfuttatási utakat tesz lehetővé, és ezzel a hatalommal fontos bizalmi megfontolások járnak.
A követelmények kötelező formában:
- a felhasználónak kifejezetten hozzá kell járulnia minden adathozzáféréshez és művelethez, és meg kell értenie azokat;
- a hosztnak kifejezett hozzájárulást kell szereznie, mielőtt felhasználói adatot ad át egy szervernek;
- eszköz meghívása előtt kifejezett hozzájárulás kell;
- és a legfontosabb mondat: az eszközök viselkedését leíró szöveget megbízhatatlannak kell tekinteni, hacsak nem megbízható szerverről jött.
Ez az utolsó pont pontosan az eszközmérgezésre vonatkozik — a specifikáció maga figyelmeztet rá.
De a legőszintébb mondat ez: a protokoll ezeket az elveket protokollszinten nem tudja kikényszeríteni. A felelősség a kliensé.
A hivatalos biztonsági útmutató ezen felül tíz nevesített támadást ír le sémákkal — a megtévesztett helyettestől a tokenátengedésen és a belső hálózat elérésén át a helyi szerver kompromittálásáig. Ez nem elméleti kockázatlista: a protokoll saját dokumentációja tíz konkrét módját sorolja fel annak, ahogy elromolhat.
A2A: nem versenytárs
Gyakori kérdés, hogy az MCP-nek van-e konkurense. A rövid válasz: nem konkurens, hanem kiegészítő — és ezt mindkét oldal így írja le.
| Mire való | |
|---|---|
| MCP | agent ↔ eszköz kommunikáció: hogyan kapcsolódik az agent az eszközeihez, API-jaihoz, erőforrásaihoz |
| A2A | agent ↔ agent kommunikáció: hogyan találják meg egymást, adnak át feladatot, osztanak meg eredményt |
És egy érdekes megfigyelés: az A2A-t egy nagy technológiai cég fejlesztette, majd szintén a Linux Foundationnek adományozta, nyolc szervezet képviselőiből álló irányító testülettel, szintén Apache 2.0 alatt.
Vagyis 2026-ra az agent-interoperabilitás két fő szabványa egyaránt kikerült az alapító cég kezéből egy semleges alapítványhoz. Ez önmagában is hír.
Tipikus félreértések
- „Az MCP egy cég protokollja." Már nem. A Linux Foundation alatt van, Apache 2.0 licenccel, és a kormányzásban nincsenek cégekhez rendelt helyek.
- „Ha benne van a hivatalos nyilvántartásban, biztonságos." A nyilvántartás maga írja le, hogy a biztonsági átvizsgálást másra hagyja. Névtér-hitelesítést ad, nem tanúsítványt.
- „A hivatalos szerverek biztonságosak." A referencia-implementációk között volt kritikus, kattintás nélküli adatszivárgás, és mind az öt hivatalos SDK ugyanazt a hibát hozta.
- „Az eszközleírás csak dokumentáció." A specifikáció szerint megbízhatatlan bemenet, amiből működő támadás építhető.
- „A protokoll kikényszeríti a jóváhagyást." Nem tudja. Kötelezővé teszi, de a betartatás a kliensen múlik.
- „A listából kiszűrtem, tehát nem érhető el." Nem. Legalább egy dokumentált esetben a szűrés csak a listázásra vonatkozott, a hívásra nem.
Amit érdemes elvinni
Az MCP jó dolog: egy szabvány, ami megszünteti az integrációk négyzetes növekedését, és ma már semleges alapítvány gondozza, elavulási szabályzattal és szabványos megfigyelhetőséggel. Felnőtt protokoll.
De két dolgot érdemes fejben tartani. Az egyik: a bekötés nem telepítés, hanem bizalmi döntés — az eszközleírás bemenet, nem dokumentáció, és a protokoll ezt nem tudja helyetted eldönteni. A másik: a jogosultságot a hívásnál kell ellenőrizni, nem a listázásnál — és ezt a hibát nem egy amatőr követte el, hanem több élő szerver.
Hogy az eszközhívás mechanizmusa pontosan hogyan működik a modell oldaláról, arról a tool use és a function calling poszt szól részletesen; a jogosultságok szűkítéséről pedig a legkevesebb jogot kapó agent poszt ad gyakorlati receptet.