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 az összefutás, jobban, mint bármely egyedi funkciókiadás, az oka annak, hogy az MCP lett az a dolog, amelyhez szinte minden AI-szállító az elmúlt évben támogatást épített.
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. A saját indulási anyagai egy megmaradt 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, az adott személy 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 adatokon kell cselekedniük — Claude, ChatGPT, GitHub Copilot, Cursor és egy belső támogatási bot —, és ezek az adatok nyolc helyen élnek: Slack, GitHub, egy Postgres-adatbázis, Salesforce, Notion, Google Drive, Jira és egy belső API. Közös protokoll nélkül minden eszköz minden forráshoz való hasznos kötése akár negyven külön integrációt igényel — ötször nyolc —, mindegyiknek saját hitelesítési sémája, saját hibakezelése és saját karbantartási adója van, valahányszor az egyik API alakot vált. 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 a mérnöki időre érdemesnek ítélt, é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 újrahasznál 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 létszámmal elbírt volna.
Hogyan működik valójában a protokoll
Ha lehántjuk a keretet, az MCP meglehetősen egyszerű kliens–szerver protokoll, szándékosan fényűzés nélkül. 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, állapotot tartó 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 szállítás 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 behúzhat és átadhat a modellnek anélkül, hogy annak 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 valami, amit a modell magától dönt el. 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-ban őszintén szokatlan módon: a közvetlen versenytársak egyetlen cég protokollján futottak össze, 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ök-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 koordináljanak, ne csak 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 közül egyik sem ért egyet sok mindenben, ha modellarchitektúráról, árazásról vagy platformstratégiáról van szó. Mind a négy olyan termékeket ad ki most, 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 csak csővezeték
Ez az összefutás őszintén hasznos, és pontosan ezért érdemel az MCP vizsgálatot a vak bizalom helyett. Egy protokoll, amely triviálissá teszi, hogy egy ügynök a cég rendszereihez csatlakozzon, olyan protokoll, amely triviálissá 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 annál vannak, 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 vezetékes 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 hatókörrel rendelkezik-e, naplózott-e és visszavonható-e, olyan döntés, amelyet valaki meghozott — vagy nem — fölötte.
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 épített dolog — 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 olvasható, vagy írhat és cselekedhet? | 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ély kell. | Ö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 úgy dönt, elmond 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ás támogatási jegyet, hívást a szállítóhoz igényel, vagy egyáltalán nem lehetséges. |
| A visszavonása eltör valamit mást is? | 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 csendben hármat tör el. |
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 vezérlő 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 kihúzott képernyőképekbe.
Ebből semmi sem egzotikus mérnöki munka. Apró, szándékosan fényűzés nélküli 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 viszi ez az oldal tágabban a Legibility fogalmáról — 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 a csővezetéket 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ó most kiadja, 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 funkció alá, 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.