Mi az MCP, és miért beszéli hirtelen minden AI-eszköz?
Az elmúlt évtized nagy részében egy AI-modell összekötése a cég eszközeivel minden párhoz egyedi integrációt jelentett. A Model Context Protocol, a nyílt szabvány, amelyet az Anthropic 2024 novemberében mutatott be, ezt egyetlen, mindenhol illeszkedő csatlakozóval váltotta fel — és az OpenAI, a Google és a Microsoft azóta mind átvette. Íme, hogyan működik valójában, és egy valódi ellenőrzőlista, mielőtt egyet a csapat adataira kötne.
Nyissa meg a Claude asztali alkalmazását, és kérje meg, hogy ellenőrizze a csapat nyitott pull requestjeit — és egyszerűen megteszi. Nem azért, mert az Anthropic GitHub-integrációt épített a Claude-ba. Hanem azért, mert valahol — az IT-csapat, egy szállító, egy fejlesztő a GitHubon — valaki írt egy kis programot, amely MCP nevű protokollt beszél, és a Claude már tud beszélni bármivel, ami ezt beszéli. Ugyanez igaz most a ChatGPT-re, a Google Geminiére és a Microsoft Copilotra. Ez a konvergencia, még inkább, mint bármelyik egyedi funkció megjelenése, az oka annak, hogy az MCP lett az a szabvány, amelynek támogatásán szinte minden AI-szállító dolgozott az elmúlt évben.
Mi az MCP valójában
Az MCP a Model Context Protocol rövidítése. Az Anthropic tervezte, és 2024. november 25-én nyílt forráskódúként adta ki a specifikációt az első SDK-kkal együtt. Saját bejelentő anyagai egy megragadó hasonlattal írták le az ötletet: gondoljon az MCP-re úgy, mint egy USB-C-portra az AI-alkalmazások számára — egyetlen fizikai csatlakozószabvány, külön kábel helyett minden tartozékhoz. Az induláskor az Anthropic megnevezte a korai alkalmazókat, akik már MCP-támogatást építettek a saját termékeikbe, köztük a Block és az Apollo vállalati szoftvercégeket, valamint a Zed, Replit, Codeium és Sourcegraph fejlesztőeszköz-készítőket. A Claude asztali alkalmazása ugyanazon a napon jelent meg azzal a képességgel, hogy MCP-szervereket futtasson helyben, a felhasználó saját gépén.
A probléma, amelyet megold: N eszköz szorozva M adatforrással
A problémának, amelyet az MCP megold, van egy neve, amelyet a mérnökök lazán használnak: az N-szer M integrációs probléma. Tegyük fel, hogy egy cég öt AI-eszközt használ, amelyeknek a céges adatokkal kell dolgozniuk — Claude, ChatGPT, GitHub Copilot, Cursor és egy belső támogatási bot —, és ezek az adatok nyolc helyen találhatók: Slack, GitHub, egy Postgres-adatbázis, Salesforce, Notion, Google Drive, Jira és egy belső API. Közös protokoll nélkül ahhoz, hogy minden eszközt hasznos módon összekössünk minden forrással, akár negyven külön integráció kell — ötször nyolc —, mindegyiknek saját hitelesítési sémájával, saját hibakezelésével és saját karbantartási terhével, valahányszor az egyik API megváltozik. Adjon hozzá egy hatodik AI-eszközt, és a szám negyvennyolcra ugrik. A gyakorlatban senki sem építette meg mind a negyvenet. Minden AI-szállító azt a maréknyit építette meg, amelyet érdemesnek ítélt a mérnöki időre, és minden más kézi maradt: másolás, beillesztés, újramagyarázás, ismétlés.
Az MCP a szorzást összeadássá változtatja. Egy cég, amely azt szeretné, hogy a Claude a Postgres-adatbázisából olvasson, nem Claude-specifikus Postgres-csatlakozót épít. Épít — vagy újrahasznosít egyet, amelyet valaki más már közzétett — egy MCP-szervert, amely elérhetővé teszi a Postgreset, és ez a szerver további kód nélkül működik a Claude-dal, a ChatGPT-vel, a Geminivel vagy bármely más MCP-kompatibilis ügynökkel. Az Anthropic saját listája az induláskor előre elkészített szervereket nevezett meg a Google Drive-hoz, a Slackhez, a GitHubhoz, a Githez, a Postgreshez és egy Puppeteer nevű böngészőautomatizálási eszközhöz. A lényeg soha nem az volt, hogy az Anthropic megépíti mindet. Hanem az, hogy bárki megtehette, és az elérhető szerverek katalógusa jóval túlnőtt azon, amit egyetlen cég emberi erőforrással le tudna fedni.
Hogyan működik valójában a protokoll
Ha elvonatkoztatunk a körítéstől, az MCP meglehetősen egyszerű kliens–szerver protokoll, szándékosan látványtalan. Három szerepet határoz meg. A Host az az alkalmazás, amelyet egy ember ténylegesen megnyit — Claude Desktop, egy IDE, mint a Cursor, a ChatGPT alkalmazás. A Host egy MCP Clientet ágyaz be, amely közvetlen, állapottartó kapcsolatot nyit egy MCP Serverrel — egy kis programmal, amely egy konkrét rendszert tesz elérhetővé: egy adatbázist, egy jegyrendszert, egy fájlrendszert, egy belső API-t. A kliens és a szerver JSON-RPC 2.0 formátumú üzeneteket cserél, egy könnyű távoli eljáráshívási formátumot, amely a meglévő infrastruktúrában már megszokott, két átviteli mód egyikén: stdio, ha a szerver ugyanazon a gépen helyben futó program, vagy Streamable HTTP, ha máshol futó üzemeltetett szolgáltatás.
Amit egy szerver elérhetővé tehet, három primitívre fut ki. A Tools olyan függvények, amelyeket a modell meghívhat egy művelet végrehajtásához — create_task, run_query, send_message —, és a modell a beszélgetés alapján dönti el, mikor hív meg egyet. A Resources csak olvasható kontextus, amelyet a Host beemelhet és átadhat a modellnek anélkül, hogy a modellnek kérnie kellene — egy fájl tartalma, egy adatbázisséma, egy támogatási jegy. A Prompts újrahasználható, a felhasználó által indított sablonok — egy kész „foglald össze ezt a szálat” vagy „írj állapotfrissítést”, amelyet egy ember kifejezetten meghív, nem pedig olyasmi, amiről a modell magától dönt. Egy jól megépített szerver egyértelmű abban, hogy a három közül melyiket kínálja egy adott képességhez, mert pontosan ez a különbség dönti el, hogy egy csatlakoztatott AI-eszköz ránézhet-e valamire, vagy meg is változtathatja.
Ki más vette át, és mikor
Az MCP első néhány hónapja kizárólag az Anthropic projektje volt. Ez gyorsan megváltozott, méghozzá az AI területén valóban szokatlan módon: a közvetlen versenytársak egyetlen cég protokollja köré rendeződtek, ahelyett hogy a sajátjukat adták volna ki. Az OpenAI 2025 márciusában MCP-támogatást adott az Agents SDK-jához, így a fejlesztők ügynöki munkafolyamatokat bármely MCP-szerverhez köthettek ahelyett, hogy egyedi, OpenAI-specifikus eszközintegrációkat építettek volna. A következő hónapban a Google DeepMind megerősítette, hogy a Gemini és a saját ügynökfejlesztő készlete is támogatni fogja az MCP-t — egy lépés, amelyet a Google a saját kiegészítő protokolljával, az Agent2Agenttel párosított, amelynek célja, hogy a független ügynökök egymással hangolják össze a munkát, nem pedig eszközökkel. 2025 májusára a Microsoft natív MCP-támogatást hozott a Windows 11-be azon keresztül, amit Windows AI Foundrynak nevez, és a támogatás a GitHub Copilotba és a Copilot Studióba is megérkezett.
E négy cég nem sokban ért egyet, ha modellarchitektúráról, árazásról vagy platformstratégiáról van szó. Mind a négy ma már olyan termékeket ad ki, amelyek ugyanazt a protokollt beszélik egy ügynök eszközhöz kötéséhez. Ez ebben az iparágban elég ritka ahhoz, hogy ez legyen a tényleges történet — jobban, mint bármely egyedi funkció, amelyet az MCP lehetővé tesz.
Miért bizalmi kérdés ez, nem csupán infrastruktúra
Ez a konvergencia valóban hasznos, és pontosan ezért érdemel az MCP vizsgálatot a vak bizalom helyett. Egy protokoll, amely gyerekjátékká teszi, hogy egy ügynök a cég rendszereihez csatlakozzon, olyan protokoll, amely gyerekjátékká teszi, hogy egy rosszul megépített vagy rosszul beállított kapcsolat ugyanazokat a rendszereket elérje. Maga az MCP ezt nem akadályozza meg. A specifikáció azt határozza meg, hogyan beszél egymással egy kliens és egy szerver — semmit nem mond arról, ki adhat engedélyt egy kapcsolatra, mihez nyúlhat az a kapcsolat, vagy észreveszi-e valaki, ha valami rosszul sül el. Ezek a választások teljes egészében azon múlnak, aki megépítette vagy beállította az ön előtt lévő konkrét szervert vagy klienst. Egyes szállítók mindezt gondosan megépítik. Mások egyáltalán nem, és a protokoll nem állítja meg őket.
Az MCP adatátviteli protokoll, nem hozzáférés-vezérlő rendszer. Azt szabványosítja, hogyan kér egy ügynök egy eszközt arra, hogy tegyen valamit. Az, hogy ez a kérés korlátozott hatókörű-e, naplózott-e és visszavonható-e, olyan döntés, amelyet valaki meghozott — vagy nem — rá építve.
Ellenőrzőlista, mielőtt egyet csatlakoztat
Mielőtt a csapat MCP-szervert csatlakoztat — legyen az egy szállító terméke, egy nyílt forráskódú eszköz, amelyet valaki a GitHubon talált, vagy házon belül fejlesztett megoldás — hat kérdés választja el a felügyelt kapcsolatot a nyitott ajtótól. Egyikhez sem kell elolvasni a specifikációt. Csak az kell, hogy valaki kérdezzen, mielőtt a jóváhagyásra kattint, és tényleg elolvassa a választ, amelyet a kapcsolódási képernyő visszaad.
| Ezt kérdezze | Így néz ki a jó | Erre figyeljen |
|---|---|---|
| Milyen hatóköröket vagy eszközöket kér? | Tételes Megnevezett, konkrét lista, amelyet jóváhagyás előtt elolvashat — „feladatok létrehozása, üzenetek olvasása ebben a csatornában.” | Általános „Teljes fiókhozzáférés” anélkül, hogy tételesen felsorolná, mit tud valójában. |
| Csak olvasási jogú, vagy írhat és műveleteket is végezhet? | Különválasztott Alapértelmezés szerint olvasási hozzáférés; minden adatot módosító műveletnek saját, látható engedélyre van szükség. | Összecsomagolt Az írási hozzáférés automatikusan benne van, és nem lehet megmondani, melyik képesség mit csinál. |
| Személyenkénti, vagy az egész csapatra közös? | Személyenkénti Mindenki a saját belépésével jelentkezik be; az ügynök csak azt látja, amit az a személy lát. | Közös Egyetlen API-kulcs vagy szolgáltatásfiók az egész csapatnak, amely megkerüli az egyéni jogosultságokat. |
| Van auditnapló arról, mit tett? | Naplózott Minden eszközhívás rögzítve — ki csatlakoztatta, mihez nyúlt, és mikor. | Naplózatlan Nincs feljegyzés azon túl, amit maga az AI-eszköz jónak lát elmondani arról, mi történt. |
| Azonnal visszavonható? | Azonnali Egy kapcsoló, azonnal érvényes, egy ön által kezelt beállítási oldalról. | Késleltetett A visszavonáshoz támogatási jegy vagy a szállító felhívása kell, vagy egyáltalán nem lehetséges. |
| A visszavonása más dolgot is elront? | Elszigetelt Arra az egy kapcsolatra korlátozott; a kikapcsolás csak azt érinti. | Összefonódott Hitelesítő adatot oszt más eszközökkel, így az egyik visszavonása észrevétlenül hármat elront. |
Hogyan néz ki valójában egy jól megépített kapcsolat
A FabricLoop saját MCP-beállítása egy konkrét válasz erre az ellenőrzőlistára — nem azért, mert szokatlan, hanem azért, mert minden darabja közvetlenül a fenti hat kérdés egyikére képezhető le, és érdemes a tényleges mechanikát megnevezni a marketingváltozat helyett. A FabricLoop egyszerre tölti be mindkét szerepet: MCP-szerver, amelyhez külső eszközök csatlakoznak, így a Cursor, a Claude vagy a ChatGPT feladatot hozhat létre, megjegyzést adhat hozzá vagy jegyzetet olvashat egy adott személy saját FabricLoop-jogosultságaival — és MCP-kliens, amely kifelé csatlakozik, így egy csatorna behúzhatja egy szállító MCP-alkalmazását, például a GitHubot vagy a Lineart, és @említheti, mint egy csapattagot.
Minden kapcsolat, mindkét irányban, egy személlyel kezdődik, nem egy munkaterülettel. Egy külső kliens, például a Cursor csatlakoztatása OAuth-hozzájárulási képernyőt nyit a app.fabricloop.com/oauth/consent címen, ahol az a személy kiválaszt egy munkaterületet, és jóváhagyja azokat az eszközöket, amelyeket a kliens kér — a kliens ezután csak az azon a képernyőn megadott hatókörökkel cselekedhet, annak az egy személynek a jogosultságai alatt, soha nem közös szolgáltatásfiókon keresztül. A fordított irány ugyanígy működik: egy adminisztrátor engedélyezheti egy szállító MCP-alkalmazását az egész csapatnak, de minden személynek így is be kell fejeznie a saját bejelentkezését, mielőtt nála működne, és egy adminisztrátor csak olvasható módba teheti az alkalmazást, vagy egy adott eszközökből álló engedélyezési listára korlátozhatja ahelyett, hogy mindent megkapna, amit a szállító elérhetővé tesz.
Minden csatlakoztatott kliens megjelenik egy beállítási képernyőn egy Visszavonás gomb mellett, amely azonnal leválasztja — a személy saját oldalán, nem egy támogatási jegyben. Az Enterprise csomagokban ez a tevékenység — beleértve az MCP-engedélyeket és azt, hogy egy csatlakoztatott ügynök valójában mit tett — egy auditnaplóba kerül, amelyet egy biztonsági csapat kérésre átnézhet, nem pedig egy csevegési szálból utólag összeszedett képernyőképekre hagyatkozva.
Ebből semmi sem egzotikus mérnöki munka. Apró, szándékosan látványtalan döntések halmaza, következetesen ismételve: határolja be, kösse egy személyhez, naplózza, tegye visszavonhatóvá járulékos kár nélkül. Ugyanezt az érvet képviseli ez az oldal tágabban a Legibility fogalma kapcsán — a hozzáférés, amelyet meg lehet nevezni, naplózni és visszavonni, legyőzi azt a hozzáférést, amelyen senkinek sem kell gondolkodnia —, és az MCP csak akkor adja ezt, ha valaki így építi meg. A protokoll az infrastruktúrát teszi szabványossá. Az irányítást nem teszi automatikussá.
A döntés, amelyen valójában múlik
Az MCP nem fog eltűnni, és ezen a ponton ellenezni egy kicsit olyan, mint az USB-t ellenezni. Minden nagy modellszolgáltató ma már támogatja, az elérhető szerverek listája tovább nő, és egy ügynök, amely nem éri el az eszközeit, a legtöbb valódi munkában olyan ügynök, amely nem sokat tud tenni. Az érdekes döntés nem az, hogy enged-e egy AI-eszközt a rendszereihez csatlakozni — egyre inkább ennek a döntésnek valamely változata már ön helyett születik meg, integrációról integrációra, ahogy a csapat által már használt eszközök csendben MCP-támogatást adnak egy olyan funkció mögé, amelyre anélkül kattintott, hogy elolvasta volna az apró betűt. A döntés, amely még mindig valóban az öné, az, hogy mit ellenőriz, mielőtt a jóváhagyásra kattint.
Az MCP szabványosította, hogyan kér egy AI-ügynök egy eszközt arra, hogy tegyen valamit. Semmit nem tett azért, hogy szabványosítsa, biztonságos-e ezt a kérést megadni — ez a rész továbbra is, és az is marad, annak a személynek a döntése, aki a „jóváhagyás” gombra kattint.