Mi az az MCP-szerver? Így működik az MCP és az MCP UI 2026-ban

Az Invariant Labs 2025. április 1-jén közzétett egy add nevű eszközt. Két számot kapott, és visszaadta az összegüket. A leírásában azonban volt egy IMPORTANT jelölésű blokk is, amely a kliens felületén nem látszott, és arra utasította a modellt, hogy olvassa be a ~/.cursor/mcp.json és a ~/.ssh/id_rsa fájlt, majd küldje ki mindkettőt egy fölösleges paraméteren keresztül. A modell engedelmeskedett. A felhasználó egy összeadást látott.

Ez a bemutató a leghasznosabb bevezetés az MCP-szerverekhez, amit ismerek, mert egyszerre mutatja meg mindkét felet. A protokoll pontosan úgy működött, ahogy tervezték: egy AI-kliens felfedezett egy eszközt, elolvasta a leírását, és meghívta. A bizalmi modell volt az a rész, amelyet még senki nem épített meg.

Mi az az MCP-szerver

Az MCP-szerver olyan program, amely eszközöket, adatokat és promptokat tesz elérhetővé AI-alkalmazások számára a Model Context Protocolon (MCP) keresztül. A hivatalos dokumentáció szerint az MCP „nyílt forráskódú szabvány AI-alkalmazások külső rendszerekhez való csatlakoztatására”. Egy AI-kliens, például a Claude, a ChatGPT, a Visual Studio Code vagy a Cursor, csatlakozik a szerverhez, megkérdezi, mit kínál, és a felhasználó nevében meghívja ezeket a képességeket.

Az Anthropic 2024. november 25-én jelentette be az MCP-t hat előre elkészített szerverrel: Google Drive, Slack, GitHub, Git, Postgres és Puppeteer. Az OpenAI 2025 márciusában vette át. A Google DeepMind áprilisban követte. 2025 decemberében az Anthropic az Agentic AI Foundationnek adományozta a protokollt, amely a Linux Foundation alá tartozó célalap, alapítói az Anthropic, a Block és az OpenAI.

A gond a kapcsolatok sokszorozódása. MCP előtt minden GitHubot elérni kívánó AI-alkalmazás saját összekötőt írt, és minden szolgáltató alkalmazásonként épített kapcsolatot. Tíz modell és tíz eszköz akár száz integrációt jelentett. Az MCP ezt húszra csökkenti: minden kliens egyszer valósítja meg a protokollt, minden rendszer egy szervert tesz elérhetővé.

Gondolj rá úgy, mint az AI-integrációk szállítókonténerére. A konténerek előtt minden kikötőben kézzel rakodtak be minden árut, saját darukkal és saját személyzettel. A konténer a dobozt szabványosította, így bármelyik hajó, daru és kamion bármilyen árut mozgathatott. Azt viszont nem szabványosította, mi kerül a dobozba, és a tartalmát soha nem ellenőrizte. Az MCP ugyanez az alku. Jegyezd meg a második felét, mert a biztonságról szóló részben visszatér.

Hogyan működik egy MCP-szerver

A jelenlegi specifikáció, a 2026-07-28-as verzió, JSON-RPC 2.0 üzeneteket használ három szerep között. A saját leírása három sor: a gazdák „kapcsolatot kezdeményező LLM-alkalmazások”, a kliensek „konnektorok a gazdaalkalmazáson belül”, a szerverek pedig „kontextust és képességeket nyújtó szolgáltatások”.

Gazda, kliens, szerver

A gazda (host) az az alkalmazás, amelybe gépelsz: a Claude Desktop, egy IDE, a saját ügynököd. Ezen belül szerverkapcsolatonként egy kliens fut. A szerver a túloldalon ül, és a valódi rendszerrel beszél, legyen az egy Postgres-adatbázis, a GitHub API vagy egy mappa a lemezeden. A gazda dönti el, mit lát a modell, és mit kell a felhasználónak jóváhagynia. A szerver dönti el, mit tesz a mögötte álló rendszer.

1. Gazda Claude Desktop · egy IDE · a saját ügynököd

   megmutatja a modellnek az eszközöket, hozzájárulást kér a felhasználótól

2. Kliens szerverkapcsolatonként egy

   JSON-RPC-n beszél stdio vagy Streamable HTTP felett

3. MCP-szerver eszközök · erőforrások · promptok

   leírja, mit kínál, és végrehajtja a hívásokat

4. Mögöttes rendszer adatbázis · SaaS API · helyi fájlok

   elvégzi a munkát

Eszközök, erőforrások és promptok

Egy szerver háromféle dolgot kínálhat:

• Az eszközök (tools) olyan függvények, amelyeket a modell végrehajthat: create_issue, query_orders, send_email. Mindegyiknek van neve, leírása és a bemeneteihez tartozó JSON Schemája.
• Az erőforrások (resources) kontextust és adatot jelentenek, amelyet a felhasználó vagy a modell elolvas: egy fájl, egy adatbázisséma, egy rekord.
• A promptok (prompts) sablonos üzenetek és munkafolyamatok, amelyek közül a felhasználó választhat, például „foglald össze ezt a pull requestet”.

Az eszközök kapják a legtöbb figyelmet, mert cselekszenek. Ugyanezért ők hordozzák a kockázat nagy részét is.

Egy eszközhívás lépésről lépésre

A 2026-07-28-as változat állapotmentessé tette az MCP-t. Már nincs initialize kézfogás; minden kérés a _meta mezőben viszi a protokollverziót és a kliens képességeit, a szervereknek pedig meg kell valósítaniuk a server/discover metódust, hogy a kliens előre megkérdezhesse, mit támogatnak. Egy eszközhívás ma így zajlik:

1. A felhasználó kéri: nyiss jegyet erre a hibára

2. 1. lépés

   Felfedezés

   • A kliens meghívhatja a server/discover metódust a verziókért és képességekért
3. 2. lépés

   Eszközlista

   • A tools/list visszaadja a neveket, leírásokat és bemeneti sémákat
4. 3. lépés

   A modell eszközt választ

   • A gazda átadja a modellnek az eszközdefiníciókat
5. 4. lépés

   Felhasználói hozzájárulás

   • A specifikáció szerint a gazdának kifejezett hozzájárulást kell kérnie bármely eszköz meghívása előtt
6. 5. lépés

   Hívás

   • tools/call argumentumokkal, a protokollverzió a _meta mezőben

7. Hiányzik egy bemenet? A szerver input_required eredményt ad, a kliens a válaszokkal újrapróbálja

   6. lépés

   Eredmény

8. Az eredmény kontextusként visszakerül a modellhez

A 6. lépés új ebben a változatban. Ha egy szervernek további információ kell, már nem küld saját kérést vissza a kliensnek. Egy input_required jelölésű eredményt ad vissza, a kliens összegyűjti a választ, és újrapróbálja az eredeti hívást. A specifikáció ezt Multi Round-Trip Request mintának nevezi.

Átviteli módok: stdio és Streamable HTTP

A specifikáció két szabványos átviteli módot határoz meg:

• stdio: a kliens alfolyamatként indítja el a szervert, és újsorral elválasztott JSON-RPC üzeneteket vált vele a szabványos bemeneten és kimeneten. A legtöbb helyi szerver így fut, ami azt jelenti, hogy a szerver a te gépeden, a te jogosultságaiddal fut.
• Streamable HTTP: minden üzenet egy HTTP POST egyetlen végpontra, a válaszok pedig JSON-objektumként vagy kérésszintű eseményfolyamként érkeznek vissza. A távoli, hosztolt szerverek így futnak.

A régebbi HTTP+SSE átvitel hivatalosan elavult. A 2026-07-28-as változat a protokollszintű munkameneteket és az Mcp-Session-Id fejlécet is eltávolította; az a szerver, amelynek hívások között állapotra van szüksége, ma saját azonosítót hoz létre, és azt egy szokásos eszközargumentumként kapja vissza.

Hitelesítés és jogosultságkezelés

Az MCP-ben a jogosultságkezelés opcionális, és csak a HTTP-re vonatkozik. Stdio esetén a specifikáció szerint a szervereknek a környezetből kell venniük a hitelesítő adatokat. HTTP esetén a védett MCP-szerver OAuth 2.1 erőforrás-szerverként működik. Közzé kell tennie az OAuth Protected Resource Metadata adatokat (RFC 9728), hogy a kliensek megtalálják az engedélyezési szerverét. A klienseknek pontosan meg kell nevezniük, melyik szervernek szól a token (RFC 8707 resource indicators). A szervereknek el kell utasítaniuk minden olyan tokent, amelyet nem nekik állítottak ki, a biztonsági útmutató pedig kifejezetten tiltja a „token passthrough” gyakorlatot, vagyis a kliens tokenjének változatlan továbbítását egy downstream API felé.

Ez az utolsó szabály fontosabb, mint amilyennek látszik. Az a szerver, amely bármilyen kapott tokent továbbít, proxyvá válik bárki számára, akinek van egy tokenje.

Mit ad hozzá az MCP UI: felületet visszaadó szerverek

A szöveges válaszok abban a pillanatban csődöt mondanak, amikor a felhasználónak negyven sort kell összehasonlítania, egy tizenkét mezős űrlapot kell módosítania, vagy egy csomag változtatást kell egyenként jóváhagynia. Az „MCP UI” az a név, amelyen az emberek a megoldást keresik: a szerver interaktív felületet ad vissza, amely az AI-kliensben, a beszélgetés mellett jelenik meg.

A státuszt pontosan kell leírni. Az ötlet a közösségi MCP-UI projektből indult. Az OpenAI hasonló megoldást készített az Apps SDK-ban. Az MCP-projekt 2025. november 21-én közös szabványt javasolt velük, majd 2026. január 26-án az MCP Apps lett az első hivatalos MCP-bővítmény. Az MCP-UI csomagjai már ezt valósítják meg, és továbbra is teret adnak új ötletek próbájának.

Az MCP UI tehát ma MCP Appset jelent. Hivatalos, és bővítmény, nem a protokoll magja. A bővítmények opcionálisak: a kliensnek és a szervernek is támogatnia kell őket, a dokumentáció pedig nyíltan kimondja, hogy „a gazdák támogatása kliensenként eltér”. Az MCP Apps dokumentációja támogató gazdaként a Claude, a Claude Desktop, a VS Code GitHub Copilot, a Microsoft 365 Copilot, a Goose, a Postman, az MCPJam és az Archestra.AI nevét sorolja fel. Az a szerver, amelynek eszközei felületet adnak vissza, továbbra is működnie kell olyan kliensben is, amely csak szöveget mutat.

Mechanikailag az MCP saját elemeit használja újra:

1. Az eszköz leírása tartalmaz egy _meta.ui.resourceUri mezőt, amely egy ui:// erőforrásra mutat.
2. A gazda lekéri ezt az erőforrást, egy HTML-oldalt a szkriptjeivel, és akár az eszköz meghívása előtt előre betöltheti.
3. A gazda egy elkülönített (sandboxolt) iframe-ben jeleníti meg, amely nem olvashatja a szülőoldalt, annak sütijeit vagy tárolóját.
4. Az alkalmazás és a gazda a postMessage csatornán, az MCP egy JSON-RPC dialektusában kommunikál. Az alkalmazás eszközhívásokat kérhet, a gazda pedig eldönti, melyeket engedi.

Az ára valós. Webes frontendet szállítasz valaki más alkalmazásán belül, olyan tartalombiztonsági szabályzattal (CSP), amelyet deklarálnod kell, olyan megjelenítési szabályokkal, amelyeket nem te irányítasz, és szöveges tartalékmegoldással minden gazdához, amely figyelmen kívül hagyja. A nyereség az, hogy a jóváhagyás többé nem csevegési átirat. A dokumentáció a jó felhasználási területek listáját így zárja: „költségjelentések jóváhagyása, kódváltozások áttekintése vagy hibajegyek osztályozása”, és ez a dolog őszinte közepe: az MCP UI a döntésekben a legjobb, nem a díszítésben.

Csak olvasható Tajo-példa

A Tajo Alto MCP-felületén a query_contacts a csatlakoztatott munkaterületen tárolt kontaktok között keres. Keress rá egy létező kontaktra e-mail-címmel, és vizsgáld meg az azonosítót, az e-mail-hozzájárulási állapotot és az utolsó észlelés idejét. A külön get_contact_topic_status eszköz a témakörökre vonatkozó feliratkozásokat olvassa.

Ezek munkaterületi olvasások. Nem kérnek friss pillanatképet a szolgáltatótól, nem indítanak szinkront és nem küldenek üzenetet. Azt sem bizonyítják, hogy minden összekötő él. A hiányzó vagy régi adatot a forrásánál vizsgáld. Üres találatból nem következik, hogy a személy nincs a Brevóban.

A Tajo MCP-dokumentációval csatlakoztass támogatott klienst, és nézd meg, mely eszközöket adja ténylegesen a jogosult munkaterület. Interaktív panel segíthet, ha a gazda támogatja az MCP Apps rendszert. A szöveges eredménynek akkor is el kell magyaráznia a kimenetet.

Egy eszközhívás nem tartós szinkron

Ismétlődő szinkronhoz ütemezés, stabil rekordazonosság, mentett előrehaladás, újrapróbálási döntés és a kész írások naplója is kell. Ezeket a végrehajtó alkalmazás adja. Az MCP az eszközök elérését szabványosítja; a listázás nem biztosítja az üzleti szabályokat.

Időtúllépés után az olvasás többnyire újrapróbálható. Küldés vagy fizetés viszont már megtörténhetett. Őrizd meg a végrehajtási rekordot és egyeztesd az eredményt az új próbálkozás előtt. A modell magabiztossága nem ad engedélyt és nem teszi biztonságossá az ismétlést.

Konkrét kontakt céloldali írásához olvasd a Brevo API útmutatót. A reverse ETL útmutató segít eldönteni, mikor kell a számított mezőkhöz külön fenntartott szinkron.

A biztonság számláját a protokollal együtt kapod

Az ellenvetést érdemes teljes egészében kimondani: „Az MCP egy valószínűségi modell kezébe ad egy listát olyan függvényekről, amelyek adatot törölhetnek és e-mailt küldhetnek, aztán idegenek által írt szövegre bízza, hogy leírja őket. Ez nem integrációs szabvány. Ez egy ellátásilánc-támadás specifikációval.” Ennek nagy része igaz. A specifikáció egyetért a kiindulóponttal. A biztonsági része szerint az eszközök „tetszőleges kódfuttatást jelentenek, és kellő óvatossággal kell kezelni őket”, az eszközleírásokat „megbízhatatlannak kell tekinteni, hacsak nem megbízható szervertől származnak”, és az MCP „protokollszinten nem tudja kikényszeríteni ezeket a biztonsági elveket”.

Íme az eddigi mérleg:

• Eszközmérgezés (tool poisoning). Az Invariant Labs 2025. áprilisi közzététele, a fenti add eszköz. Ugyanaz a bejegyzés leírta a rug pull támadást, amikor a szerver azután változtatja meg egy eszköz leírását, hogy jóváhagytad, valamint a shadowingot (árnyékolást), amikor egy rosszindulatú szerver átírja a modell viselkedését egy másik, megbízható szerverrel szemben.
• Helyi szerverek kompromittálása. 2025 júliusában a JFrog nyilvánosságra hozta a CVE-2025-6514 sérülékenységet az mcp-remote 0.0.5 és 0.1.15 közötti verzióiban, amely lehetővé tette, hogy egy rosszindulatú szerver parancsokat futtasson a felhasználó gépén. Ugyanazon a nyáron a CVE-2025-49596 az Anthropic saját MCP Inspectorát érintette, amely alapértelmezésben hitelesítés nélkül érkezett.
• Felfújt hatókörök. A hivatalos biztonsági ajánlások meg is nevezik a mintát: files:* vagy admin:* hatókörű tokenek, amelyeket már az elején megadnak, mert a szerver felsorolta az összes hatókört, a kliens pedig mindet kérte.
• Hivatalos aggodalom. 2026 májusában az amerikai Nemzetbiztonsági Ügynökség (NSA) kijelentette, hogy az MCP „gyors elterjedése megelőzte a biztonsági modelljének fejlődését”.

Az ellenvetés a következtetésnél téved. A megoldás soha nem az volt, hogy ne kössünk modelleket rendszerekhez; a csapatok ezt már addig is csinálták, nyers API-kulcsokkal, amelyeket promptokba és szkriptekbe másoltak, mindenféle naplózás nélkül. A megoldás az, hogy az MCP-szervert ugyanúgy kezeld, mint bármely más kiemelt jogosultságú függőséget:

• Csak olyan forrásból telepíts szervert, amelyre az MCP-n kívül is rábíznád ugyanazokat a hitelesítő adatokat.
• A hosszú életű kulcsokat tároló helyi binárisok helyett válaszd az OAuth-t és szűk hatóköröket használó távoli szervereket.
• Minden íráshoz kérj emberi jóváhagyást, és naplózd, ki mit hagyott jóvá.
• Rögzítsd a szerververziókat, és nézd át újra őket, ha megváltozik egy eszköz leírása.
• Feladatra szabott eszközöket tegyél elérhetővé, ne a teljes API-t; a modell nem élhet vissza egy törlő végponttal, amelyet soha nem tettek elérhetővé.

A protokoll a dobozt szabványosította. A rakomány ellenőrzése továbbra is a te dolgod.

Saját MCP-szerver vagy egy meglévő

Az olyan nyilvános katalógusok, mint az mcp.so, közösségi szervereket gyűjtenek, és sok SaaS-szolgáltató saját szervert is közzétesz. A Brevo például kínál egy MCP-szervert, amely különálló szerverekre is fel van bontva, így egy ügynök megkaphatja a kapcsolatokat a kampányok nélkül. A döntés kevésbé a ráfordításról szól, inkább arról, kié legyen az eszközök formája.

Melyik MCP-szervert használja az ügynököd?

1. A szolgáltató közzétesz egy szervert, amely lefedi a feladatot

   Használd a szolgáltató szerverét

   Lépést tart az API-val, és a szolgáltató tartja karban.

2. Egyetlen rendszer, de kevesebb vagy biztonságosabb műveletre van szükséged

   Használd szűkített hatókörrel

   Adj minimális hatókört, és csak azokat az eszközcsoportokat tedd elérhetővé, amelyekre az ügynöknek szüksége van.

3. Belső adatok vagy szerver nélküli rendszer

   Építs egy kis szervert

   Néhány feladatra szabott eszköz a saját API-d fölött, saját hitelesítéssel.

4. A feladat két vagy több rendszert érint

   Építs vagy vezess be egy szabályozott réteget

   Egyetlen eszközkészlet, hozzájárulási szabályok és auditnapló mindegyikhez.

Egy alap szerver megépítése a könnyű rész. Egy hivatalos SDK-val egy működő, egyeszközös stdio szerver egy délutáni munka. A költség később jön: OAuth a HTTP-változathoz, elavulások (a 2026-07-28-as változat elavultnak nyilvánította a Roots, a Sampling és a Logging funkciót, valamint a Dynamic Client Registrationt), és az a folyamatos munka, hogy olyan eszközleírásokat írj, amelyeket a modell helyesen értelmez. A leggyakoribb hiba egy API becsomagolása végpontonként egy eszközzel. Minden eszközleírás olyan szöveg, amelyet a modellnek el kell olvasnia és mérlegelnie kell, így néhány feladatra szabott eszköz többet ér a teljes API-felületnél.

MCP, API-k, integrációk és iPaaS

Az MCP nem váltja ki az API-kat. Szinte minden MCP-szerver egy API burkolója. A munka továbbra is az API-ban történik, a maga sebességkorlátaival, adatmodelljével és furcsaságaival. Az MCP azt változtatja meg, ki hívhatja: egy modell, futásidőben, amely leírás alapján választja ki a hívást, nem pedig egy fejlesztő, aki előre beégeti a kódba.

Ez a különbség tiszta határt húz azzal a két másik dologgal szemben, amellyel az MCP-t gyakran összekeverik:

• Az integrációk és az iPaaS (a fő platformokat itt hasonlítjuk össze) ütemezetten vagy eseményre mozgatnak adatot, determinisztikusan, akár ül valaki egy csevegésben, akár nem. Egy 40 000 rendelést CRM-be töltő éjszakai szinkronizálás ne azon múljon, hogy egy modell úgy dönt-e, hogy 40 000 eszközhívást indít.
• A reverse ETL modellezett adatokat juttat vissza egy adattárházból az operatív eszközökbe. Mi az a reverse ETL, és mikor illik a feladathoz, az külön téma, és az egy adatfolyam, nem beszélgetés.
• Az MCP azokra a pillanatokra való, amikor egy embernek vagy ügynöknek kérdeznie, vizsgálódnia vagy cselekednie kell ezekben a rendszerekben, igény szerint.

A hiba mindkét irányban előfordul. Egyes csapatok tömeges szinkronizálásra építenek MCP-szervert, és lassú, drága, nem megismételhető adatfolyamokat kapnak. Más csapatok gondos integrációkat építenek, aztán nyers API-kulcsot adnak az AI-asszisztensüknek, hogy lekérdezze őket, és ellenőrizetlen hátsó ajtót kapnak.

Támogatott integrációnál a tartós munka és az ellenőrző eszközök egyértelmű jogosultsági határt osszanak meg. Ellenőrizd az összekötőt, az engedélyezett műveleteket és a rögzített eredményeket az adott folyamathoz. Az integrációs dokumentáció megkülönbözteti a beállítási útmutatót az éles bizonyítékot még igénylő utaktól. Az MCP külön jóváhagyott eszközöket adhat; a lista nem bizonyít aktív ismétlődő szinkront vagy minden szükséges kontrollt.

Az MCP 22 hónap alatt hat referenciaszerverből a Linux Foundation projektjévé vált, amelyet a Claude, a ChatGPT, a VS Code és a Cursor is beszél. Egy modellt rendszerhez kötni ma már az olcsó rész. Eldönteni, mit tehet ott, az a valódi munka.