Mi az MCP, és mit old meg valójában?
Az MCP (Model Context Protocol) egy nyílt protokoll, amely egységes formában írja le, milyen eszközöket és adatforrásokat érhet el egy AI-ügynök. A haszna szervezési: az integrációt egyszer kell megírni, és utána bármelyik modell vagy ügynök-keretrendszer használni tudja. Amit viszont nem old meg: a jogosultságkezelést, az adatminőséget és azt a kérdést, hogy egyáltalán szabad-e írnia az ügynöknek.
A kiindulási probléma egyszerű. Ha négy modellt akarsz összekötni öt belső rendszerrel, akkor húsz integrációt tartasz karban. Ha a rendszerek elé egy-egy MCP-szervert teszel, akkor kilencet: öt szervert és négy klienskonfigurációt. Ez a teljes ígéret. Nem több, de nem is kevés, mert a húsz integráció mindegyike külön hitelesítést, külön hibakezelést és külön naplózást jelentene.
−98,7%
tokenfogyasztás egy Drive-ból Salesforce-ba másoló feladaton, ha az ügynök kódot futtat MCP felett: 150 000 helyett 2 000 token
Anthropic, 2025-11-04
41%
a szoftvercégek ekkora hányada használ MCP-t korlátozott vagy széles produkciós körben
Stacklok, 2026-01 (másodlagos forrásból idézve)
2026-07-28
az aktuális MCP-specifikáció dátuma: stateless mag, protokollszintű emberi jóváhagyás, header-alapú routing
modelcontextprotocol.io
Az MCP-t az Anthropic adta ki 2024 novemberében, 2025 decemberében pedig a Linux Foundation alatt működő Agentic AI Foundation kapta meg, vagyis a governance vendor-semleges lett. Ezt fontosnak tartom, de nem tekinteném lezártnak: egy protokoll egy év vendor-semleges működés után még nem szabvány abban az értelemben, ahogy az SQL vagy a HTTP az. Ha ma MCP-re építesz, azt úgy tedd, hogy a szerver mögötti üzleti logika önmagában is használható maradjon.
Miért nehéz hagyományosan összekötni az AI-t a vállalati rendszerekkel?
Három visszatérő ok van. Minden integráció egyedi darab, mert minden modell és minden keretrendszer másképp írja le az eszközöket. A bejelentkezett felhasználó jogosultsága nem terjed át az ügynökre, mert az ügynök jellemzően saját technikai fiókkal fut. És nincs egységes audit-nyomvonal arról, hogy melyik ember melyik műveletét indította el a gépi közvetítő.
Minden integráció egyedi darab
Egy tool-definíció önmagában nem bonyolult. A baj ott kezdődik, hogy a hitelesítés, a rate limit kezelése, az újrapróbálkozás, a hibaüzenetek fordítása és a séma-verziózás minden integrációban újra megíródik, kissé másképp. Egy év múlva senki nem tudja megmondani, hogy a hat helyen megírt partnerkeresés közül melyik szűr üzletágra és melyik nem.
A jogosultság nem terjed át
Ezt szokták a leginkább alábecsülni. A vállalati rendszerekben évek alatt felépült egy jogosultsági modell, amit az ügynök egyetlen technikai fiókkal megkerül. Onnantól a hozzáférést a chat-felület védi, ami nem hozzáférés-védelem. Az OWASP LLM-listája ezt pontosan fogalmazza meg: a system prompt nem titok és nem biztonsági kontroll, az authorizáció determinisztikus rendszerbe való.
Nincs audit-nyomvonal
Ha a naplóban annyi szerepel, hogy az integrációs felhasználó módosított egy rekordot, akkor egy vitás esetben nincs mit előadni. Kell a valódi felhasználó azonosítója, a hívott eszköz neve, a paraméterek, a válasz és a modellverzió. A megfelelőségen túl a hibakeresés is ezen áll vagy bukik, mert máshonnan nem fejthető vissza, mi történt.
| Kérdés | Egyedi integráció modellenként | MCP-réteg |
|---|---|---|
| Új modell bevezetése | minden eszközt újra kell kötni | klienskonfiguráció, a szerver marad |
| Hitelesítés | integrációnként külön megoldás | egy helyen, a szerver előtt |
| Naplózás | szétszórva, eltérő formátumban | egy belépési pont, egységes formátum |
| Eszközök leltára | kódban elszórva | listázható, verziózható eszközkatalógus |
| Jogosultság | nem oldja meg | nem oldja meg, csak egy helyre koncentrálja |
Hogyan működik egy MCP-szerver a gyakorlatban?
Az ügynök a kliens, a vállalati rendszer elé tett folyamat a szerver. A szerver háromféle dolgot tesz közzé: eszközöket (végrehajtható műveletek JSON-sémával), erőforrásokat (olvasható tartalom URI-val címezve) és promptokat (szerveroldali sablonok). A modell az eszközleírásokat olvassa, és ezek alapján dönti el, mit hív meg. Az eszköz leírása tehát a prompt része, nem dokumentáció.
Egy eszköz gyakorlatilag egy függvény, aminek van neve, bemeneti sémája és emberi nyelvű leírása. A séma az, ami miatt a modell nem szabad szöveget generál, hanem parse-olható hívást. Így néz ki egy valós, szűkre szabott olvasó eszköz egy ERP előtt:
{
"name": "keszlet_lekerdezes",
"description": "Egy cikkszám aktuális szabad készletét adja vissza egy raktárban. Csak olyan raktárt ad vissza, amelyre a hívó felhasználónak jogosultsága van. Nem ad árat és nem ad partneradatot.",
"inputSchema": {
"type": "object",
"properties": {
"cikkszam": { "type": "string", "pattern": "^[A-Z0-9-]{3,24}$" },
"raktar_kod": { "type": "string", "enum": ["KP01", "KP02", "VID"] }
},
"required": ["cikkszam"],
"additionalProperties": false
}
}Négy dolog van benne szándékosan. A név üzleti műveletet takar, nem tábla-hozzáférést. A leírás kimondja, mit nem ad vissza. A séma regexszel és enummal szűkít, tehát a modell nem tud tetszőleges bemenetet küldeni. Az additionalProperties: false pedig megakadályozza, hogy egy kreatív hívás extra mezőket csempésszen be.
Eszköz, erőforrás vagy prompt: melyik mikor
A három primitív keverése a leggyakoribb tervezési hiba. Az eszköz csinál valamit, az erőforrás olvasható tartalom, a prompt pedig szerveroldalon tárolt sablon. Ha mindent eszközzé teszel, a modellnek minden apró adatért hívást kell indítania, és a hívások száma viszi el a költséget meg a latenciát.
| Primitív | Mit jelent | Vállalati példa | Mikor válaszd |
|---|---|---|---|
| Tool (eszköz) | paraméterezett művelet JSON-sémával, a modell hívja | keszlet_lekerdezes, arajanlat_piszkozat_letrehozasa | ha a válasz a paraméterektől függ, vagy ha történik valami |
| Resource (erőforrás) | URI-val címzett, olvasható tartalom, a kliens tölti be | aktuális árlista, ÁSZF, a NAV-ból lehúzott számlaadat | ha lassan változó referenciaanyag, amit nem kell keresni |
| Prompt | szerveroldali sablon rögzített szerkezettel | ajánlatkészítés lépéssora, reklamáció-kivizsgálás menete | ha a folyamat menetét te akarod diktálni, nem a modell |
Mit hozott a 2026-07-28-i specifikáció
| Változás | Miért számít vállalati környezetben |
|---|---|
| Stateless protokoll-mag | minden kérés önleíró, tehát sima load balancer mögé tehető, megosztott állapot nélkül skálázható |
| Multi Round-Trip Requests (MRTR) | a szerver visszaadhat input_required választ, a kliens pedig folytatja: az emberi jóváhagyás protokollszintre került |
| Header-alapú routing (Mcp-Method, Mcp-Name) | a meglévő API-gateway és WAF a headerből tud dönteni, nem kell JSON-törzset elemeznie |
| Authorization hardening | kötelező RFC 9207 issuer-validáció, dinamikus kliensregisztráció helyett Client ID Metadata Documents |
| Enterprise Managed Authorization (EMA) | extensionként az SSO-hoz kötött, központilag menedzselt hozzáférés irányába visz |
| Tier 1 SDK-k | TypeScript, Python, Go és C# azonnal, Rust bétában: a legtöbb magyar vállalati stack lefedve |
A 2026-os roadmap az audit trailt, az SSO-integrált hitelesítést és a gateway-viselkedést kifejezetten extensionként kezeli, nem a protokoll-magban. Ez őszinte megközelítés a fejlesztők részéről, de neked azt jelenti, hogy a vállalati elvárásaid egy részét továbbra is neked kell megépítened.
Milyen eszközöket adj ki egy ERP előtt álló MCP-szerverben?
Keveset, nevesítve, és az olvasást élesen elválasztva az írástól. Praktikusan két szervert érdemes futtatni: egy olvasót, amit széles kör elér, és egy írót, ami kevés műveletet tud, külön hitelesítéssel és jóváhagyási lépéssel. Az eszköz mindig üzleti művelet legyen, soha ne nyers adatbázis-hozzáférés. Ez a cikk legfontosabb szabálya.
| Eszköz | Típus | Ki hívhatja | Kontroll |
|---|---|---|---|
| keszlet_lekerdezes | olvasás | minden bejelentkezett felhasználó | a hívó saját raktár-jogosultsága |
| partner_kereses | olvasás | értékesítés, pénzügy | maszkolt bankszámlaszám, nincs tömeges export |
| nyitott_szamlak | olvasás | pénzügy | csak a hívó üzletágához tartozó partnerek |
| arajanlat_piszkozat_letrehozasa | írás, visszavonható | értékesítés | piszkozat állapot, kiküldeni ember küldi ki |
| szallitolevel_rogzites | írás, nehezen visszavonható | raktárvezető | jóváhagyás, idempotencia-kulcs, napi darabszám-limit |
| sql_lekerdezes | ne add ki | senki | nincs olyan üzleti kérdés, ami ezt indokolná |
| partner_torles | ne add ki | senki | a törlés maradjon emberi művelet a saját felületén |
Négy szabály, ami hosszú távon számít
- Az eszköz üzleti műveletet takarjon. Ha a neve tábla vagy technikai fogalom, akkor rossz a szint, és a modellnek üzleti tudást kell pótolnia, amivel nem rendelkezik.
- A visszatérési érték legyen szűk. Ne a teljes rekordot add vissza, csak a szükséges mezőket. Ez token-költség és adatvédelmi kérdés egyszerre.
- Ne legyen univerzális menekülőút. Egyetlen
executevagyrun_queryeszköz visszacsinálja az összes többi korlátozást. - Tartsd alacsonyan az eszközök számát. Minden eszközleírás minden hívásnál bekerül a promptba. Ha hatvan eszközöd van, azok leírásaiért minden egyes kérdésnél fizetsz.
Ha a feladat sok köztes adatot mozgat, érdemes megnézni a kódvégrehajtásos mintát: az ügynök nem külön eszközhívásokat sorol, hanem kódot ír, ami az MCP-szervereket API-ként használja, és a szűrés a sandboxban történik. Az Anthropic mérésében egy Drive-ból Salesforce-ba másoló feladat így 150 000 tokenről 2 000-re esett. Ez nem minden feladatra jó, de adatmozgatásnál nagyságrendi különbség.
Hogyan öröklődik a felhasználó jogosultsága az ügynökre?
Úgy, hogy az eszközhívás a végfelhasználó identitásával fut, nem egy közös technikai fiókkal. A gyakorlatban ez a bejelentkezett felhasználó tokenjének továbbadását jelenti a háttérrendszer felé, on-behalf-of módon. Ha ez nem valósul meg, a jogosultsági rendszered kikerül a képből, és az ügynök lesz a legmagasabb jogosultságú felhasználó a cégben.
Nézzük meg, mi történik pontosan a szolgáltatásfiók-csapdában. Az ügynök egyetlen technikai fiókkal olvas, aminek mindenhez van joga, mert így volt a legegyszerűbb elindulni. Ettől kezdve a pénzügyi adatokat az védi, hogy a marketinges nem tudja, mit kérdezzen. Ez nem kontroll. Az audit-logban pedig az szerepel, hogy az integrációs felhasználó lekérdezte a partnertörzset, ami egy adatvédelmi incidensvizsgálatban használhatatlan.
| Modell | Hogyan hitelesít | Mit mutat az audit-log | Mikor fogadható el |
|---|---|---|---|
| Szolgáltatásfiók | egy technikai user, minden hívás ezzel fut | a technikai fiók nevét, a valódi felhasználót nem | belső prototípus, éles adat nélkül |
| Felhasználói token továbbadása | a bejelentkezett user tokenjével, on-behalf-of | a valódi felhasználót és a hívott eszközt | ez legyen az alapértelmezés éles rendszerben |
| Vegyes | olvasás user-tokennel, írás szűk jogú technikai fiókkal | a kezdeményezőt és a jóváhagyót is | ha a háttérrendszer nem tud on-behalf-of hitelesítést |
A biztonsági rész, amit ügyfélbeszélgetésen elő fognak hozni
Jogosan. Az eszközleírásokat maga a modell olvassa, tehát rejtett utasítás is kerülhet beléjük: ez a tool poisoning. Az MCPTox benchmarkot bemutató 2026-os tanulmány szerint hét vizsgált MCP-kliens nagy része elégtelen statikus validációt végez. Emellett a nem hitelesített MCP Inspector példányok tetszőleges parancsvégrehajtást engedtek (CVE-2025-49596, CVSS 9.4).
A védekezés architekturális, nem tartalomszűrés. Simon Willison megfogalmazása szerint az ügynök akkor válik kihasználhatóvá, ha három képesség egyszerre van meg benne: hozzáfér privát adathoz, találkozik nem megbízható tartalommal, és tud kifelé kommunikálni. Ha bármelyik lábat kiveszed, a támadás nem záródik be. Ezért érdemes az írási és kifelé kommunikáló eszközöket olyan ügynökbe tenni, amelyik nem olvas bejövő e-mailt vagy webes tartalmat.
Mikor szabad írási jogot adni AI-ügynöknek éles rendszerbe?
Akkor, ha a művelet szűken definiált, a hatása mérhető, és öt kontroll együtt teljesül: emberi jóváhagyás a visszafordíthatatlan lépéseknél, kódba égetett összeg- és darabszám-korlát, visszavonható köztes állapot, idempotencia-kulcs minden hívásra, és teljes audit-log. Ha ezek közül bármelyik hiányzik, maradjon olvasó az ügynök.
| Művelet | Visszafordítható? | Kötelező kontroll |
|---|---|---|
| Ajánlat piszkozat létrehozása | igen | elég a felhasználói jogosultság |
| Készletmozgás rögzítése | korlátozottan, a sztornó nyomot hagy | idempotencia-kulcs, napi darabszám-limit |
| Számla kiállítása | nem, az adatszolgáltatás megtörtént | emberi jóváhagyás, összeghatár |
| Utalás indítása | nem | emberi jóváhagyás, kétszemélyes elv |
| Ügyfélnek küldött üzenet | nem | jóváhagyás vagy szigorú sablon, és az AI-jelleg közlése |
| Törzsadat törlése | nem | ne legyen rá eszköz, maradjon a saját felületén |
Idempotencia: a legolcsóbb kontroll, amit a legtöbben kihagynak
Az ügynök hurkot futtat, a hurok pedig újrapróbálkozik. Ha a hálózat eldobja a választ egy sikeres írás után, a következő kör ugyanazt a műveletet még egyszer elindítja. Ezért minden írási eszköz kapjon kliens által generált kulcsot, a szerver pedig ugyanarra a kulcsra adja vissza az első eredményt új rekord létrehozása nélkül. Enélkül előbb-utóbb lesz két azonos szállítólevél, és nem lesz világos, melyik futásból.
Jóváhagyás: hol valósul meg
Protokollszinten a 2026-07-28-i MCP-spec MRTR mechanizmusa adja: a szerver input_required választ küld, a kliens pedig a jóváhagyással folytatja, nyitott kapcsolat nélkül. Keretrendszer szinten a LangGraph interrupt() és Command(resume=...) párosa ugyanezt tudja durable checkpointtal, tehát a jóváhagyás akár másnap is megérkezhet. A lényeg, hogy a jóváhagyás ne a promptban legyen kérve, hanem a kódban kikényszerítve.
Az audit-log tartalma legyen fix: ki kezdeményezte, melyik eszköz futott, milyen paraméterekkel, mi jött vissza, melyik modell és melyik promptverzió döntött. A tracing-eszközök ezt megadják futásonként; a választásról a Langfuse és LangSmith összehasonlításunkban írtunk részletesen. Az ügyfél felé menő csatornáknál pedig ne feledd, hogy az EU AI Act 50. cikke szerinti átláthatósági kötelezettségek 2026. augusztus 2. óta élnek, tehát közölni kell, ha AI válaszol.
Mit tegyél, ha a rendszernek nincs használható API-ja?
Olvasáshoz építs read-replicát, és a szerver nézeteket olvasson, ne táblákat. Íráshoz használd a gyártó saját import-funkcióját fájl-alapú cserén keresztül, mert így az ERP validációja a helyén marad. Az RPA az utolsó lehetőség, nem az első ötlet. A magyar legacy vonalon ez nem elméleti kérdés: az exPanda például Windows desktop kliens Firebird adatbázissal, ahol az integráció belépési pontja az adatbázis.
| Út | Mire jó | Mi a kockázata | Mikor válaszd |
|---|---|---|---|
| Olvasó replika és nézetek | gyors, terheléstől független olvasás | a séma csendben változik, és a nézet némán elromlik | ha csak olvasásra van szükség |
| Fájl-alapú csere | írás a gyártó saját importján keresztül | késleltetés, és nehéz visszajelzést kapni a hibáról | ha az ERP-nek van import és export funkciója |
| RPA, képernyő-automatizálás | írás akkor is, ha semmi más nincs | minden UI-változás megtöri, idempotencia nincs | ha nincs se API, se import, és a folyamat így is megéri |
A nézet itt szerződés. Ha az MCP-szerver közvetlenül táblákat olvas, az első ERP-frissítés után te leszel az, aki magyarázkodik. Ha nézeteken keresztül olvas, akkor a nézet definíciója az a felület, amit verziózol, teszteled és dokumentálsz. Ugyanez igaz a fájl-alapú írásra: a fájlformátum a szerződés, és a feldolgozás eredményét vissza kell tudni olvasni, különben az ügynök vakon dolgozik.
Az RPA-ról a véleményem határozott: működik, de éjjel kettőkor ez törik el elsőként, és nincs benne semmi, ami újrapróbálkozásnál megvédene a duplikációtól. Ha mégis ez marad, tedd külön ügynökbe, adj neki napi műveleti limitet, és minden futásról készíts képernyőmentést a naplóba. A részletesebb migrációs és párhuzamos üzemi kérdéseket a rendszerintegrációs oldalunkon írtuk le.
Mennyibe kerül egy MCP-réteg, és mit kell rajta üzemeltetni?
A bevezetés nálunk a folyamatautomatizálási sávban mozog: egy többrendszeres, hibakezelt integráció 500 000 és 2 500 000 forint között, az összetett, jóváhagyási folyamattal ellátott AI-vezérelt automatizálás 2 500 000 és 10 000 000 forint között. Az üzemeltetés havi 30 000 és 150 000 forint között van. A modellköltség ehhez képest általában kicsi, amíg az eszközök száma kordában marad.
| Tétel | Nagyságrend | Megjegyzés |
|---|---|---|
| Olvasó MCP-szerver 5–10 eszközzel | 500 000 – 2 500 000 Ft | többrendszeres integráció hibakezeléssel, AppForge árlista |
| Írási eszközök jóváhagyással és audit-loggal | 2 500 000 – 10 000 000 Ft | az összetett, AI-vezérelt automatizálás sávja |
| Üzemeltetés | 30 000 – 150 000 Ft/hó | monitorozás, séma-frissítés, hibajavítás |
| Megfigyelés (tracing) | 0 Ft licenc self-hosted Langfuse-zal | felhőben 29 USD/hó a Langfuse Core, 39 USD/fő/hó a LangSmith Plus, 14 napos alap-retencióval |
| Modellköltség | Claude Sonnet 5: 2 USD / 1M input token | minden eszközleírás minden hívásban input token |
Az üzemeltetésnél két tétel szokott meglepetést okozni. Az egyik a háttérrendszer sémájának változása, ami nem szól előre. A másik a költségkontroll: a havi büdzsé-plafon nem védelem, mert utólag lép, a túlköltő futás pedig már lefutott. Futásonkénti, valós idejű token- vagy dollárplafon kell, lépésszám-korláttal és időtúllépéssel. A TechCrunch 2026 júniusi anyagában szerepel, hogy az Uber áprilisra elhasználta a teljes évre szánt AI-kódolási keretét: ez nem MCP-probléma, de jól mutatja, milyen gyorsan tud elszaladni egy hurokban futó rendszer.
Mikor ne használj MCP-t?
Ha egyetlen rendszert kötsz egyetlen ügynökhöz, és a folyamat elágazásai előre lerajzolhatók, akkor az MCP felesleges réteg. Egy közvetlen API-kliens kevesebb mozgó alkatrész: nincs plusz processz, plusz hitelesítés, plusz verziófüggőség. Az MCP akkor kezd megtérülni, amikor több fogyasztó használja ugyanazt az adatot, vagy amikor a modellfüggetlenség és a központi naplózás követelmény.
| Helyzet | Mit használj | Miért |
|---|---|---|
| Egy rendszer, egy ügynök, fix folyamat | közvetlen API-kliens vagy SDK | az MCP itt plusz processz és plusz hibaforrás |
| Előre lerajzolható elágazások | workflow LLM-hívásokkal | az Anthropic saját ajánlása is ez, a workflow legtöbbször jobb |
| Nincs eval, nincs mérés | előbb mérés, aztán integráció | e nélkül nem derül ki, mikor romlik el a rendszer |
| Kettő vagy több fogyasztó ugyanarra az adatra | MCP-réteg | itt térül meg az M+N logika |
| Modellfüggetlenség vagy audit követelmény | MCP-réteg | a hozzáférés egy helyen naplózható és cserélhető |
Érdemes a számokat is odatenni. A Gartner 2025. június 25-i előrejelzése szerint 2027 végéig az agentic AI projektek több mint 40 százalékát leállítják, jellemzően költség, tisztázatlan üzleti érték vagy elégtelen kockázatkezelés miatt. A MIT Project NANDA 2025 nyári felmérése szerint a vállalati generatív AI pilotok 95 százaléka nem hozott mérhető P&L-hatást. Ugyanez a kutatás azt is mérte, hogy belső szakértő és külső partner együtt 67 százalékos sikerrátát hozott, míg a csak belső IT-vel épített projektek 22 százalékot.
Ezekből számomra az következik, hogy az integrációs réteg kérdését nem önmagában kell eldönteni. Ha nincs mérhető cél és nincs mérés, akkor a protokollválasztás a legkevesebb gondod lesz. Az ügynök, a chatbot és a workflow közti választásról külön írtunk az ügynök, chatbot, RPA és n8n összehasonlításban, a bevezetés lépéseiről pedig az AI integráció meglévő rendszerekbe cikkben.
Összegzés és gyakori kérdések
Mi az MCP (Model Context Protocol)?
Nyílt protokoll arra, hogy egy AI-ügynök egységes formában érje el a külső eszközöket és adatforrásokat. Kliens-szerver modell: az ügynök a kliens, a vállalati rendszer elé tett MCP-szerver pedig eszközöket, erőforrásokat és promptokat tesz közzé. A célja az, hogy az M modell × N rendszer integrációs mátrixból M+N legyen.
Mit NEM old meg az MCP?
A jogosultságkezelést, az adatminőséget és az üzleti logikát. Az MCP leírja, hogy egy eszköz létezik és milyen paramétereket vár, de nem mondja meg, hogy az adott felhasználó hívhatja-e. Ha a törzsadat rossz, MCP felett is rossz marad. A biztonsági kontroll a szerver mögött van, nem a protokollban.
Kaphat-e AI-ügynök írási jogot az éles ERP-be?
Igen, de csak szűk, nevesített műveletekre, öt kontroll mellett: emberi jóváhagyás a visszafordíthatatlan lépéseknél, kódba égetett összeghatár, visszavonható köztes állapot (piszkozat), idempotencia-kulcs minden írási hívásra, és teljes audit-log. Általános SQL-eszközt vagy törlést soha ne adj ki. A jóváhagyás a 2026-07-28-i MCP-specifikációban már protokollszinten is megvan.
Mi a szolgáltatásfiók-csapda?
Az, amikor minden ügynök-hívás egyetlen technikai fiókkal fut. Ekkor bárki, aki eléri az ügynököt, gyakorlatilag azt látja, amit a technikai fiók lát, a jogosultsági rendszer megkerülhető lesz, az audit-logban pedig nem a valódi felhasználó szerepel. Éles rendszerben a felhasználói token továbbadása (on-behalf-of) az alapértelmezés.
Mit tegyek, ha a rendszernek nincs API-ja?
Három út van, ebben a sorrendben. Olvasásra adatbázis read-replica, és a szerver nézeteket olvas, nem táblákat. Írásra a gyártó saját import-funkciója fájl-alapú cserén keresztül, így az ERP validációja megmarad. Az RPA az utolsó lehetőség: minden UI-változás megtöri, és nincs benne idempotencia.
Mennyibe kerül egy MCP-integrációs réteg?
Nálunk egy többrendszeres, hibakezelt integráció 500 000 és 2 500 000 forint között van, az összetett, AI-vezérelt automatizálás jóváhagyási folyamattal 2 500 000 és 10 000 000 forint között, az üzemeltetés pedig havi 30 000 és 150 000 forint között. A modellköltség ehhez képest általában kicsi, ha az eszközök száma kordában marad.
Mikor felesleges az MCP?
Ha egyetlen rendszert köt egyetlen ügynökhöz, és a folyamat elágazásai előre lerajzolhatók. Ilyenkor a közvetlen API-kliens kevesebb mozgó alkatrész: nincs plusz processz, plusz hitelesítés és plusz hibaforrás. Az MCP akkor térül meg, ha két vagy több fogyasztó használja ugyanazt az adatot, vagy ha modellfüggetlenség és központi naplózás a követelmény.
Biztonságos-e MCP-szervert használni?
Csak akkor, ha tudod, mi fut rajta. Az eszközleírásokat maga a modell olvassa, így azok támadási felületet jelentenek: a tool poisoning ellen az MCPTox mérés szerint a legtöbb kliens gyenge statikus validációt végez. Idegen, publikus MCP-szervert vállalati adat mellé ne engedj, saját szervert futtass, allowlisttel és naplózással.
Ha van egy ERP-d vagy CRM-ed, és azon gondolkodsz, mit engedj meg egy ügynöknek rajta, a folyamatautomatizálás oldalunk mutatja, hogyan szoktuk ezt felépíteni, a RAG tudásbázis cikk pedig a keresési oldalt fedi le, ami az MCP-eszközök mellett szokott futni. Árakért nézd meg az árlistánkat, vagy kérj egy 30 perces egyeztetést, és átnézzük a konkrét rendszereidet.
Források
- Model Context Protocol: a 2026-07-28-i specifikációs kiadás (stateless mag, MRTR, header-routing, EMA)
- Model Context Protocol: 2026-os roadmap és governance (Agentic AI Foundation, Linux Foundation)
- Anthropic: Code execution with MCP, 150 000 tokenről 2 000-re (2025-11-04)
- Anthropic: Building Effective Agents, a workflow és az ügynök közti választás (2024-12-19)
- MCPTox: tool poisoning benchmark MCP-kliensekre (arXiv 2603.22489)
- MCP security áttekintés, CVE-2025-49596 (CVSS 9.4)
- Simon Willison: the lethal trifecta (2025-06-16)
- OWASP LLM01:2025 Prompt Injection: a system prompt nem biztonsági kontroll
- NAV Online Számla 3.0 interfész: queryInvoiceDigest és queryInvoiceData
- exPanda: Windows desktop kliens és Firebird SQL szerver (rendszerkövetelmények, 2026-08-14)
- Langfuse árlista: self-hosted MIT licenc, Core 29 USD/hó
- LangSmith árlista: Plus 39 USD/fő/hó, 14 napos alap-trace-retenció
- Anthropic hivatalos árlista: Claude Sonnet 5 input 2 USD / 1M token
- Gartner: az agentic AI projektek több mint 40 százalékát leállítják 2027 végéig (2025-06-25)
- MIT Project NANDA: The GenAI Divide, State of AI in Business (2025-07)
- TechCrunch: a token-számla megérkezett, Uber és Priceline példával (2026-06-05)
- MCP adopciós számok összefoglalója, benne a Stacklok 41 százalékos adata (másodlagos forrás)
- EUR-Lex: (EU) 2026/1744 rendelet, a Digital Omnibus on AI
