Paper2Agent: tudományos cikkből MCP-eszköz. Ugyanez a te dokumentumaiddal

A Stanford Egyetem kutatóinak Paper2Agent nevű rendszeréről szóló tanulmány 2026. szeptember 16-án jelent meg a Nature folyóiratban, a benne szereplő szám pedig elsőre is megállítja az embert: a rendszer 100 számítógépes biológiai cikkből 74-et alakított át emberi beavatkozás nélkül működő, automatikusan tesztelt MCP-szerverré. A gyakorlatban ez azt jelenti, hogy egy kutatási cikkből nem újabb összefoglaló vagy csevegőrobot lett, hanem meghívható eszközök sora, amelyeket egy AI-ügynök úgy használhat, mint egy könyvelő a számológépét: beadja az adatokat és pontos, ellenőrzött eredményt kap vissza.

Elsőre ez távolinak tűnhet egy magyar kis- vagy középvállalattól, hiszen kevés cégvezető olvas genomikai szakcikkeket a reggeli kávé mellé. A módszer lényege viszont pontosan arról a gondról szól, amellyel a legtöbb KKV nap mint nap küszködik: a céges tudás árlistákban, ÁSZF-ekben, Excel-táblákban és belső útmutatókban hever, amelyeket egy AI-asszisztens legfeljebb elolvasni tud, használni viszont nem. Hogy ebből mi hasznosítható egy magyar cégnél, azt a legfrissebb, 2026. szeptember 22-i állapot szerint vesszük végig: mit csinált pontosan a Paper2Agent, mi a különbség a RAG és az eszköz között, mikor melyiket érdemes választani, végül hogyan rakható össze ugyanez n8n-nel és egy MCP-szerverrel.

Röviden

• A Paper2Agent a Stanford Egyetem kutatóinak nyílt forráskódú rendszere, amely a Nature-ben 2026. szeptember 16-án megjelent tanulmány szerint 100 számítógépes biológiai cikkből 74-et emberi beavatkozás nélkül alakított tesztelt MCP-szerverré, összesen 593 ellenőrzött eszközzel.
• Az így elkészült „cikk-ügynök” 300 tesztkérdésen 91,2%-os pontosságot ért el, szemben a kódtárat közvetlenül böngésző Claude Code 80,3%-ával, miközben kérdésenként 0,20 dollárba került 0,38 helyett és átlagosan 1,6 perc alatt válaszolt 4,3 perc helyett.
• A RAG (visszakereséssel kiegészített generálás) a kérdéshez kikeresett szövegrészletekből fogalmaz választ, az eszköz viszont egy leírt, paraméterezhető és tesztelhető funkció, amelyet az AI-ügynök meghív és amelynek eredményét nem a nyelvi modell találja ki, hanem a mögötte futó kód állítja elő.
• Céges környezetben ott éri meg RAG helyett eszközt építeni, ahol a válasz számítás, szabálykövetés vagy friss adat eredménye, például árajánlatnál, szállítási díjnál, jótállási időnél vagy rendelési státusznál, a hosszú, értelmezést igénylő szövegekre viszont a RAG marad a jobb választás.
• Egy KKV a Paper2Agent módszerét n8n-nel és az n8n MCP Server Trigger node-jával is lemásolhatja: a dokumentumokból szabálytáblát, abból eszközt, az eszközhöz teszteseteket készít, végül csak a teszten átment eszközöket teszi elérhetővé az ügynök számára.
• Saját becslésünk szerint egy árlistára és ÁSZF-re épülő, háromeszközös MCP-szerver 28 és 32 fejlesztői óra közötti munka, a futtatás tokenköltsége pedig kérdésenként nagyjából 1,5 és 13 Ft között mozog a választott modelltől függően.

Mi az a Paper2Agent és mi történt pontosan?

A Paper2Agent a Stanford Egyetem kutatóinak nyílt forráskódú, több AI-ügynökből álló rendszere, amely egy tudományos cikkhez tartozó kódtárból automatikusan MCP-szervert épít, vagyis olyan eszközcsomagot, amelyet egy AI-ügynök közvetlenül meghívhat. A Nature-ben közölt eredmény szerint 100 számítógépes biológiai cikkből 74-nél ez teljesen emberi beavatkozás nélkül sikerült.

A tanulmány címe „Reimagining research papers as interactive and reliable AI agents”, magyarul nagyjából annyit tesz, hogy a kutatási cikkeket interaktív és megbízható AI-ügynökökként gondolják újra. Az első szerző Jiacheng Miao, a vezető szerző James Zou, mindketten a Stanford Egyetemhez kötődnek. A kiinduló probléma minden kutató számára ismerős: egy cikkben leírt elemzési módszert reprodukálni vagy saját adatokon lefuttatni gyakran napokig tart, mert telepíteni kell a kódot, ki kell bogozni a függőségeket, meg kell érteni a példákat, miközben a leírás hol hiányos, hol elavult. A Paper2Agent célja, hogy a passzív dokumentumként kezelt cikkből futtatható, kérdezhető rendszer legyen.

A rendszer nem csak a cikk szövegével dolgozik. A tanulmány szerint a teljes kutatási kimenetet „agentifikálja”, vagyis a kéziratot, a kiegészítő anyagokat, a kódot, az adatkészleteket, a futtatható példákat és az elemzési munkafolyamatokat együtt dolgozza fel. A szerzők egy mondatban külön is kitérnek arra, amiről ez a cikk szól: saját fordításunkban a módszer „túlmutat a cikk szövegén végzett visszakereséssel kiegészített generáláson”. Vagyis nem egy okosabb keresőről van szó, amely kikeresi és felolvassa a releváns bekezdést, hanem olyan eszközökről, amelyek ténylegesen elvégzik a cikkben leírt számítást.

Ahhoz, hogy ez világos legyen, két fogalmat kell tisztázni. Az AI-ügynök olyan program, amely egy nyelvi modellt eszközökkel köt össze és egy kitűzött cél felé több lépésben, részben önállóan halad. A Model Context Protocol (MCP) az Anthropic által 2024 novemberében bemutatott nyílt szabvány, amely egységes módot ad arra, hogy az AI-alkalmazások külső eszközöket és adatforrásokat érjenek el. Az MCP-szerver az a program, amely ezeket az eszközöket szabványos formában kínálja, a kliens pedig az az AI-alkalmazás, amely használja őket. A Paper2Agent esetében a kliens a Claude Code volt, de a szerzők hangsúlyozzák, hogy bármely kompatibilis nyelvi modell vagy ügynök csatlakozhat ezekhez a szerverekhez.

A 74 sikeres cikkből a rendszer összesen 599 eszközt javasolt, ebből 593 ment át az automatikus ellenőrzésen. A hat kiesett eszköz legalább annyira tanulságos, mint a sok sikeres, erre a tesztelésről szóló részben még visszatérünk.

Hogyan alakít a Paper2Agent egy tudományos cikket tesztelt eszközzé?

A Paper2Agent hat lépésben dolgozik: megkeresi a cikkhez tartozó kódtárat, elszigetelt futtatókörnyezetet épít, feltárja az oktatóanyagokat, lefuttatja és ellenőrzi őket, a bennük lévő elemzési lépéseket önálló, tesztelt eszközökké alakítja, végül a teszten átment eszközökből egyetlen MCP-szervert állít össze.

A Nature-tanulmány leírása alapján a folyamat így néz ki:

• Kódtár kinyerése. A rendszer a kézirat szövegéből, a hivatkozásokból vagy a kiegészítő anyagokból azonosítja és letölti a cikkhez tartozó kódtárat, jellemzően egy GitHub-repót.
• Környezet felépítése. Elszigetelt virtuális környezetet hoz létre a szükséges függőségekkel, így a kísérletezés nem zavarja a gép többi részét.
• Oktatóanyagok felkutatása. Átfésüli a kódtárat, majd megkeresi azokat a kidolgozott példákat, úgynevezett tutorialokat, amelyekben a szerzők bemutatják, hogyan kell használni a módszerüket.
• Futtatás és ellenőrzés. Az oktatóanyagokat elejétől a végéig lefuttatja, közben rögzíti a bemeneteket, a kimeneteket, az ábrákat és a futási korlátokat.
• Eszközök kinyerése és tesztelése. A tutorialok lépéseit önálló Python-modulokká, vagyis MCP-eszközökké alakítja, majd automatikus tesztekkel ellenőrzi, hogy az eredmény egyezik-e a referenciával.
• MCP-szerver összeállítása. Az ellenőrzött eszközöket egyetlen MCP-szerverbe szervezi, amelyet akár távoli platformon, például a Hugging Face Spaces szolgáltatásán is üzemeltetni lehet.

A folyamat legérdekesebb pontja a harmadik és a negyedik lépés. A Paper2Agent nem a cikk szövegéből próbálja kitalálni, mit kellene programoznia, hanem a már működő, kidolgozott példákból indul ki. Ez azért lényeges, mert a kidolgozott példa magában hordozza mindazt, ami a szövegből gyakran hiányzik: a pontos paramétereket, az adatformátumot, a lépések sorrendjét és az elvárt eredményt. Egy céges környezetben ennek a megfelelője nem a szabályzat szövege, hanem az az Excel-tábla, amellyel az értékesítő ténylegesen kiszámolja az ajánlatot, vagy az a három régi árajánlat, amelyen mindenki látja, hogyan jön ki a végösszeg.

A szerzők GitHubon közzétett kódja MIT-licencű, vagyis üzleti célra is szabadon felhasználható. A futtatáshoz legalább 3.10-es Python, telepített Claude Code és Node.js kell, a szerverek elkészítéséhez a rendszer a FastMCP nevű Python-könyvtárat használja. A kimenet egy projektmappa, amelyben ott van maga az MCP-szerver, az eszközönkénti Python-fájlok, a tesztek a hozzájuk tartozó adatokkal és eredményekkel, a lefuttatott oktatóanyagok, valamint lefedettségi és kódminőségi jelentések. A kódtár leírása szerint a feldolgozás a kódtár bonyolultságától függően 30 perctől több mint három óráig tart, egy összetett kódtárnál, például a Google DeepMind AlphaGenome nevű genomikai modelljénél, Claude Sonnet 4 modellel a repó becslése szerint nagyjából 15 dollárba kerül.

Mit bizonyítanak a számok és hol vannak a korlátok?

A Paper2Agent számai azt mutatják, hogy a kész, tesztelt eszközökkel dolgozó ügynök pontosabb, olcsóbb és gyorsabb, mint az, amelyiknek minden kérdésnél a nyers anyagból kell kitalálnia a teendőt. A 26 sikertelen cikk viszont arra figyelmeztet, hogy hiányos kód, elérhetetlen adat vagy rendezetlen dokumentáció mellett a módszer nem működik.

A tanulmány fő összehasonlításában a kutatók 300, a cikkek oktatóanyagaiból származtatott kérdést tettek fel két rendszernek. Az egyik a Paper2Agent által épített MCP-szervert használta, a másik ugyanazzal a Claude Sonnet 4 modellel, de közvetlenül a kódtárhoz hozzáférve dolgozott, vagyis minden kérdésnél magának kellett kiderítenie, melyik függvényt hogyan kell futtatni.

Az összehasonlításban fontos egy pontosítás: a kontrollcsoport nem egy klasszikus RAG-rendszer volt, hanem egy olyan ügynök, amely a kódtárban szabadon keresgélhetett és futtathatott. A tanulság ettől még átvihető a céges világra. Ha az ügynöknek minden alkalommal a nyers anyagból kell összeraknia a választ, akkor többet téved, többe kerül és lassabb, mintha egy előre elkészített, ellenőrzött eszközt hívna meg. A költségkülönbség forintban kicsinek tűnik, hiszen kerekített 320 Ft-os dollárárfolyammal számolva 64 Ft áll szemben nagyjából 122 Ft-tal, de ezer kérdésnél ez már nagyjából 58 000 Ft különbség, amelyben még nincs benne a hibás válaszok ára.

Az esettanulmányok közül az AlphaGenome-ügynök a legbeszédesebb. A Paper2Agent nagyjából 45 perc alatt, 14 dollárért, ami kerekítve 4 480 Ft, 22 eszközt készített a Google DeepMind genomikai modelljéhez. Egy egysejtes elemzésekhez használt Scanpy-ügynök hét eszközzel szintén körülbelül 45 perc alatt, 13 dollárért készült el, majd négy nyilvános adatkészleten reprodukálta a kutatók eredményeit. A tanulmány egy együttműködési kísérletet is bemutat, amelyben három külön cikkből készült ügynök közösen elemzett egy pikkelysömörrel összefüggő genetikai variánst, majd önállóan a GPR137 gént jelölte meg valószínű oki génként.

A korlátokról a szerzők meglepően nyíltan írnak. A sikertelen esetek fő okai a hiányzó futtatható kód, az elérhetetlen adatok vagy modellfájlok, a telepítési és függőségi hibák, valamint az olyan szkriptek voltak, amelyek csak egyetlen konkrét esetre működtek és nem lehetett őket általánosítani. Saját fordításunkban a tanulmány kimondja, hogy „nem minden cikkből lehet zökkenőmentesen robusztus ügynököt készíteni”, a nyitott tudományos gondolkodás, például a hipotézisalkotás pedig továbbra is emberi közreműködést igényel. Egy harmadik figyelmeztetés a céges alkalmazásnál is aranyat ér: a referenciaeredményhez mért pontosság elsősorban azt mutatja meg, hogy az eszköz hűen hajtja-e végre a módszert, azt viszont nem, hogy maga az elemzés helyes-e. Egy árkalkulátor tehát lehet tökéletesen pontos akkor is, ha maga az árazási logika rossz.

Ha a 74%-ot a céges dokumentumokra vetítjük, érdemes józannak maradni. A Paper2Agent olyan kódtárakkal dolgozott, amelyekben volt futtatható kód és kidolgozott példa. Egy átlagos KKV-nál a tudás jó része Word-fájlokban, e-mailekben és a tapasztalt kollégák fejében van, ahol a „hiányzó futtatható kód” megfelelője a le nem írt szabály. Ott tehát az első lépés nem az eszközépítés, hanem a szabályok táblázatba rendezése.

Mi a különbség a RAG és az eszköz (tool) között?

A RAG (retrieval-augmented generation, magyarul visszakereséssel kiegészített generálás) a kérdéshez kikeresi a dokumentumokból a leginkább odaillő szövegrészleteket, majd ezekből fogalmaztat választ a nyelvi modellel. Az eszköz ezzel szemben egy előre megírt, paraméterezett funkció, amelyet a modell csak meghív, a számítást vagy a lekérdezést pedig maga a kód végzi el.

A különbség elsőre technikai részletnek tűnik, pedig ezen múlik, hogy egy AI-asszisztensre rá lehet-e bízni az árajánlatot vagy csak a „mit mond az ÁSZF” típusú kérdéseket. Érdemes ezért lassan, lépésenként végigmenni mindkettőn.

Így működik a RAG

A RAG-rendszer először feldarabolja a dokumentumokat néhány száz szavas részletekre, ezt a szakma chunkolásnak hívja. Minden részletből beágyazás (embedding) készül, vagyis egy hosszú számsorozat, amely a szöveg jelentését kódolja, a számsorozatok pedig egy vektoradatbázisba kerülnek. Amikor kérdés érkezik, a rendszer a kérdést is számsorozattá alakítja, megkeresi a jelentésben hozzá legközelebb álló néhány részletet, jellemzően három és tíz közötti darabot, ezeket a kérdéssel együtt odaadja a nyelvi modellnek, a modell pedig ezekből írja meg a választ.

Úgy képzeld el, mint egy szorgalmas gyakornokot, aki a kérdésedre előveszi a céges dossziéból a leginkább odaillő lapokat, gyorsan átolvassa őket és a saját szavaival elmondja, mit talált. Ez nagyszerűen működik, ha a válasz egy bekezdésben benne van és csak értelmezni kell. Akkor kezdődnek a gondok, amikor a válasz három különböző lapon szétszórva található, amikor számolni kell belőle, vagy amikor a dossziéban a tavalyi és az idei árlista is benne van, mert a gyakornok ilyenkor jó eséllyel azt a lapot veszi elő, amelyik szövegében jobban hasonlít a kérdésre, nem pedig azt, amelyik érvényes.

Vegyünk egy képzeletbeli balatoni panziót, ahová ez a kérdés érkezik: mennyibe kerül két felnőtt és egy nyolcéves gyerek három éjszakára július második hetében, félpanzióval? Egy RAG-alapú asszisztensnek ehhez elő kell keresnie a szezonális szobaárat, a gyerekkedvezmény szabályát, a félpanzió felárát és az idegenforgalmi adóra vonatkozó részt, majd fejben össze kell szoroznia és össze kell adnia mindezt. Minden egyes lépés hibalehetőség: rossz szezonsáv, kimaradt kedvezmény, elrontott szorzás. A nyelvi modellek számolni is tudnak, de nem determinisztikusan, vagyis ugyanarra a kérdésre két futtatásnál sem garantáltan ugyanazt a végösszeget adják.

Így működik az eszköz

Az eszköz (angolul tool) az AI-ügynök szemszögéből egy megnevezett, leírással ellátott funkció, pontosan meghatározott bemeneti paraméterekkel és kimenettel. A nyelvi modell feladata csak annyi, hogy felismerje, mikor van rá szükség, a beszélgetésből kitöltse a paramétereket, meghívja az eszközt, végül a kapott eredményből emberi választ fogalmazzon. A számítást a kód végzi, amely az érvényes árlistából dolgozik, így ugyanarra a bemenetre mindig ugyanazt az eredményt adja, éppen ettől lesz tesztelhető.

A panziós példánál maradva az eszköz leírása ilyen egyszerű is lehet:

név: szallas_arajanlat
leírás: Kiszámolja egy foglalás bruttó árát az érvényes árlista alapján.
  Akkor használd, ha a vendég konkrét dátumokra és létszámra kér árat.
paraméterek:
  erkezes: dátum (ÉÉÉÉ-HH-NN)
  tavozas: dátum (ÉÉÉÉ-HH-NN)
  felnottek: egész szám
  gyerekek_eletkora: egész számok listája
  ellatas: reggeli | félpanzió
visszaad: éjszakák száma, szobatípusonkénti bruttó ár, idegenforgalmi adó,
  az árlista verziója és érvényessége, hiba esetén a hiba oka

A gyakornokos hasonlatban ez olyan, mintha a gyakornok egy olyan kalkulátorprogramot kapna, amelybe a tulajdonos már betáplálta és leellenőrizte az idei árakat. Neki csak a dátumokat és a létszámot kell beírnia, a végösszeget pedig a program adja. Ha a gyakornok rossz dátumot ír be, a hiba látszik és visszakövethető, ha viszont a dossziéból rossz lapot vesz elő, azt senki sem veszi észre, amíg a vendég nem reklamál.

Hol jön képbe az MCP?

Az MCP azt szabványosítja, hogyan írja le egy szerver az eszközeit és hogyan hívja meg őket egy AI-kliens. Egy MCP-szerver háromféle dolgot kínálhat: eszközöket (tools), amelyek műveletet végeznek, erőforrásokat (resources), amelyek olvasható adatot vagy dokumentumot adnak, valamint promptsablonokat. Az eszközt tehát egyszer kell megírni, utána bármely MCP-képes kliens használhatja, legyen az a Claude Code, a Claude asztali alkalmazása vagy az n8n saját AI-ügynöke.

Az irány szeptemberben több fronton is látszott. Az Adobe szeptember 2-án több mint 70 eszközét tette elérhetővé a Slackben egy MCP-alapú boton keresztül, a WordPress Core AI csapata szerint pedig az MCP Adapter beküldésre kész a bővítménytárba. A Google által javasolt WebMCP ugyanezt a gondolatot hozza el a weboldalakra: a honlap strukturált eszközöket deklarál az AI-ügynököknek, hogy ne az oldal HTML-kódjából kelljen kibogozniuk, mit hol lehet kitölteni vagy megnyomni. Az MCP legújabb, július 28-i specifikációja közben állapotmentessé tette a protokollt, ami egyszerűbb üzemeltetést hoz, ennek részletei azonban már egy külön témát érdemelnek.

Egy fontos árnyalat: a RAG és az eszköz nem ellenségei egymásnak. A visszakeresés maga is lehet egy eszköz, például egy „kereses_az_aszf_ben” nevű funkció, amelyet az ügynök akkor hív meg, ha értelmezést igénylő kérdést kap, míg az árkérdésnél a kalkulátort választja. A jól megtervezett céges rendszerek szinte mindig ilyen hibridek.

Belső tudásbázisból ügynök-eszköz: árlista, ÁSZF, útmutatók

A Paper2Agent legfontosabb tanulsága egy KKV számára az, hogy nem a dokumentum szövegéből kell kiindulni, hanem abból a kidolgozott példából, amelyen a szabály működés közben látszik. A cégeknél a legjobb eszközjelöltek ott vannak, ahol valaki rendszeresen ugyanazt a számítást vagy ellenőrzést végzi el egy dokumentum alapján.

Árlista: a legjobb első jelölt

Az árlista szinte mindig szabályokból és számokból áll, a tévedésnek pedig azonnali forintosított ára van. Vegyünk egy képzeletbeli, 12 fős kecskeméti asztalosüzemet, amely konyhabútort gyárt. Az értékesítő egy Excel-táblából dolgozik: a folyóméterenkénti alapárat a frontanyag határozza meg (laminált, festett MDF vagy tömörfa), erre jön a munkalap felára, a beépítés díja és a távolságfüggő szállítás. Ez a tábla a Paper2Agent-féle tutorial megfelelője, hiszen benne van minden szabály, paraméter és kidolgozott példa.

Ha ugyanezt az árlistát PDF-ben feltöltjük egy RAG-alapú chatbotba, a legjobb esetben is csak felolvassa a sorokat, a rosszabb esetben a tavalyi árlista részletét veszi elő. Tegyük fel, hogy egy 480 000 Ft-os konyhaajánlatnál a modell a tavalyi, minden tételben 8%-kal alacsonyabb árlistából számol: ez egyetlen ajánlaton 38 400 Ft bevételkiesés vagy egy kínos telefon, amelyben el kell magyarázni az ügyfélnek, miért drágább a konyha, mint amit a chatbot mondott. Egy „konyha_arajanlat” eszköz ezzel szemben a hatályos táblából számol, a válaszban pedig visszaadja az árlista verzióját is, így az értékesítő egy pillantással ellenőrizheti.

ÁSZF: itt a RAG és az eszköz együtt dolgozik

Az általános szerződési feltételek nagy része értelmezést igénylő szöveg, ahol a RAG jól teljesít. Ha egy vásárló azt kérdezi, mi a teendő sérült csomag esetén, a releváns bekezdés kikeresése és közérthető összefoglalása pontosan az, amire a RAG való. Az ÁSZF-ben azonban mindig vannak dátumhoz és összeghez kötött szabályok is, ezek pedig eszközért kiáltanak.

Vegyünk egy képzeletbeli debreceni webshopot, amely háztartási gépeket árul. A távollévők között kötött szerződéseknél a fogyasztót főszabályként 14 napos elállási jog illeti meg, termékvásárlásnál az átvételtől számítva. A kötelező jótállás ideje a 151/2003-as kormányrendelet szerint a rendelet mellékletében felsorolt tartós fogyasztási cikkeknél a vételártól függ: 10 000 Ft és 100 000 Ft között egy év, 100 000 Ft felett és 250 000 Ft-ig két év, 250 000 Ft felett három év. Ha a vásárló azt kérdezi, jár-e még neki a jótállás a tavaly márciusban 189 000 Ft-ért vett mosogatógépre, akkor a RAG-nak dátumot kellene számolnia és sávot kellene választania, egy „jotallas_ellenorzes” eszköz viszont a vásárlás dátumából és a vételárból egyértelmű választ ad, a határidő pontos napjával együtt. A jogszabályi sávokat persze a bevezetés előtt jogásszal is érdemes ellenőriztetni, az eszköz ugyanis csak olyan pontos, mint a bele táplált szabály.

Útmutatók és belső folyamatleírások

A belső útmutatók kétfélék. Az egyik fajta magyaráz, például leírja, hogyan kell udvariasan válaszolni egy panaszra, ez maradhat RAG. A másik fajta végrehajtható lépéssort ír le, ebből pedig kiváló eszköz lesz. Tegyük fel, hogy egy budapesti könyvelőiroda új ügyfél felvételekor más dokumentumokat kér egy egyéni vállalkozótól, egy Kft.-től és egy áfakörös betéti társaságtól. Egy „hianyzo_dokumentumok” eszköz a cégforma és az adózási mód alapján összeveti az ellenőrzőlistát a már beérkezett fájlokkal, majd pontos listát ad arról, mi hiányzik még.

A Paper2Agent kudarcainak céges megfelelője itt jön elő a legélesebben. Ha a folyamat csak a tapasztalt kolléga fejében létezik, akkor nincs miből eszközt készíteni, ahogyan a rendszer sem tudott mit kezdeni azokkal a kódtárakkal, amelyekből hiányzott a futtatható kód. Az első lépés ilyenkor egy egyórás beszélgetés a kollégával, amelynek végén a szabály egy táblázat soraiban áll.

Mikor éri meg RAG helyett eszközt építeni?

Akkor éri meg eszközt építeni, ha a kérdésre egyetlen helyes, számítással vagy szabállyal előállítható válasz létezik, ha a tévedés pénzbe vagy jogi kockázatba kerül, továbbá ha ugyanaz a kérdés havonta sokszor ismétlődik. Nyitott, értelmezést igénylő kérdéseknél a RAG olcsóbb, gyorsabban elkészül és rugalmasabb.

A döntéshez az alábbi ellenőrzőlistát javasoljuk. Ez saját ökölszabály, nem tudományos mérce, de a gyakorlatban jól elválasztja a két esetet.

Ha a hét kérdésből legalább háromra igen a válasz, az eszköz szinte biztosan jobb befektetés. Ha egyre sem vagy csak egyre, a RAG olcsóbb és elegendő. A kettő között hibrid megoldást érdemes tervezni: a szöveges részekhez RAG, a számításhoz egy-két eszköz.

Sokan azt gondolják, hogy az eszköz a futtatásnál drágább, mert több lépésből áll. Egy saját becslés megmutatja, hogy ez nem így van. Tegyük fel, hogy a RAG-os válasz egy kérdésnél körülbelül 3 200 bemeneti tokent használ (rendszerutasítás, öt kikeresett részlet, kérdés) és 300 kimeneti tokent ad. Az eszközös változat két kört fut: az elsőben körülbelül 1 200 bemeneti token (rendszerutasítás, eszközleírások, kérdés) után 80 tokenes eszközhívást ad, a másodikban az eszköz eredményével együtt körülbelül 1 500 bemeneti tokenből 200 tokenes választ ír, ez összesen 2 700 bemeneti és 280 kimeneti token.

A GPT-6 Astra listaárával (10 dollár millió bemeneti és 50 dollár millió kimeneti tokenenként) számolva a RAG-os válasz 0,047 dollár, vagyis kerekített 320 Ft-os árfolyammal nagyjából 15 Ft, az eszközös válasz 0,041 dollár, azaz körülbelül 13 Ft. A Meta Muse Spark 1.3 árával (1,25 és 4,25 dollár millió tokenenként) ugyanez 1,7 Ft és 1,5 Ft. A tokenköltség tehát nagyjából azonos, a valódi különbség a megbízhatóságban és a fejlesztési munkában van. Ez egybevág a Paper2Agent eredményével is, ahol az előre elkészített eszközök kérdésenként majdnem feleannyiba kerültek, mint a kódtárban keresgélő ügynök.

Egy dologra azért figyelni kell: minden eszköz leírása tokent fogyaszt, mert a modell minden kérésnél megkapja a teljes eszközlistát. Húsz-harminc eszköznél ez már érezhető többletköltség és a modell is könnyebben téved a választásban. Az OpenAI szeptember 10-én bétába küldött Agents API-jának eszközkeresése, vagyis az eszközök igény szerinti betöltése is erre a gondra ad választ. Egy KKV-nál a józan megoldás egyszerűbb: egy MCP-szerveren öt és tizenöt közötti, jól elkülönülő eszköz legyen, a többit bontsd külön szerverekre.

Egy jó ügynök-eszköz ismérvei: név, leírás, paraméter, őszinte hibaüzenet

Az eszköz minőségén múlik, hogy a nyelvi modell jól használja-e. A modell ugyanis nem látja a kódot, csak a nevet, a leírást és a paraméterek listáját, ezekből kell kitalálnia, mikor és hogyan hívja meg. Tapasztalatunk szerint a legtöbb rosszul működő ügynök mögött nem gyenge modell, hanem homályosan leírt eszköz áll.

A jó eszköz egyetlen üzleti kérdésre felel. A „mindent_tudo_arazas” helyett legyen külön „konyha_arajanlat” és „szallitasi_dij”, mert a modell a szűk, egyértelmű eszközök között biztosabban választ. A leírás mondja ki, mikor kell használni és mikor nem, például hogy az eszköz csak konkrét méretek megadása után hívható, általános árkérdésnél nem. A paraméterek legyenek szigorúak: dátumformátum, megengedett értékek listája, mértékegység, hogy a modell ne írhasson „kb. három méter” jellegű szöveget oda, ahol számot vár a kód.

A visszaadott eredményben legyen benne a forrás és a verzió is. Ha az árkalkulátor azt is visszaadja, hogy a 2026. szeptember 1-jétől érvényes árlistából számolt, a modell ezt meg tudja említeni, az értékesítő pedig ellenőrizni tudja. Legalább ilyen fontos az őszinte hibaüzenet. A Moveworks szeptember 14-i frissítése éppen azt vezette be, hogy sikertelen eszközhívásnál az ügynök egyértelmű hibaállapotot kapjon, ne látszólagos sikert. A Meta szeptember 3-án kiadott Muse Spark 1.3 modellje pedig a következményekkel járó lépések előtt megerősítést kér. Mindkettő ugyanazt az elvet követi: az eszköz inkább mondja meg, hogy nem tudja, mint hogy csendben rossz számot adjon.

Végül válaszd szét az olvasó és az író eszközöket. Az árlekérdezés, a jótállás-ellenőrzés vagy a rendelési státusz csak olvas, ezeket bátrabban lehet automatizálni. A foglalás rögzítése, a számla kiállítása vagy az ügyféladat módosítása ír, ezeknél az első hónapokban mindig legyen emberi jóváhagyás.

Implementáció n8n-nel és egy MCP-szerverrel lépésről lépésre

Az n8n fair-code licencű (Sustainable Use License) automatizációs platform, amely saját szerveren és felhőszolgáltatásként is fut, 1 500-nál több integrációval. Az n8n dokumentációja szerint az MCP Server Trigger node segítségével egy n8n-munkafolyamat MCP-szerverként működhet, az MCP Client Tool node-dal pedig az n8n saját AI-ügynöke külső MCP-szervereket érhet el. Ez azt jelenti, hogy a Paper2Agent logikáját programozói csapat nélkül is le lehet képezni: az eszközöket al-munkafolyamatok adják, a tesztelést egy külön munkafolyamat végzi, a szervert pedig egy trigger node publikálja.

• Gyűjtsd össze a kérdéseket. Nézd át az elmúlt két-négy hét ügyfélszolgálati e-mailjeit, majd válaszd ki azt a három kérdéstípust, amely a leggyakoribb és számolást vagy szabályellenőrzést igényel.
• Rendezd táblázatba a szabályokat. Az árlistát, a kedvezményeket és a határidőket tedd Google Sheetsbe, Odoo-ba vagy egy adatbázistáblába úgy, hogy egy sor egy szabály legyen, érvényességi dátummal és verziószámmal.
• Építs minden eszközhöz egy al-munkafolyamatot. A munkafolyamat fogadja a paramétereket, kiolvassa a táblából a szükséges sorokat, egy Code node-ban elvégzi a számítást és strukturált eredményt ad vissza, hibás bemenetnél pedig egyértelmű hibaüzenetet.
• Írd meg az eszközleírásokat. Minden eszköznek legyen beszédes neve, két-három mondatos leírása arról, mikor használható, valamint pontos paraméterlistája.
• Készíts teszteseteket. Eszközönként gyűjts 20 és 30 közötti valós, múltbeli esetet az elvárt eredménnyel, majd egy külön munkafolyamattal futtasd le őket automatikusan. Csak az az eszköz mehet élesbe, amelyik minden teszten átment.
• Hozd létre az MCP-szervert. Egy új munkafolyamatba tedd be az MCP Server Trigger node-ot, majd kösd rá eszközként az al-munkafolyamatokat, például a Custom n8n Workflow Tool node-dal. Hitelesítésnek állíts be Bearer tokent vagy fejléc alapú azonosítást, a végleges (production) URL a munkafolyamat publikálása után jön létre.
• Kösd be a klienst. Ha a céges chatbot vagy e-mail-asszisztens is n8n-ben fut, az AI Agent node az MCP Client Tool segítségével éri el a szervert, a Claude asztali alkalmazása pedig a dokumentáció szerint az mcp-remote átjárón keresztül csatlakozhat.
• Futtasd árnyékmódban. Két-négy hétig az ügynök csak javaslatot tegyen, amelyet egy kolléga jóváhagy vagy javít, az eltéréseket pedig az n8n Executions naplójából gyűjtsd ki.
• Tartsd karban. Minden árlista- vagy ÁSZF-módosításkor futtasd újra a teszteket, a verziószámot pedig emeld meg, hogy az ügynök válaszaiból később is visszakövethető legyen, melyik szabály szerint számolt.

Két technikai megjegyzés azoknak, akik maguk üzemeltetik az n8n-t. Az MCP Server Trigger a dokumentáció szerint SSE és streamable HTTP kapcsolatot támogat, a helyi, stdio alapú kapcsolatot nem. Ha pedig az n8n queue módban, több webhookpéldánnyal fut, az összes „/mcp” kezdetű kérést egyetlen dedikált példányra kell irányítani, különben a kapcsolatok megszakadnak. Érdemes a legfrissebb verzióra is frissíteni, mert az n8n 2.39.0 az ügynök-munkafolyamatok eszközeinek hibakezelését, a szeptember 15-i 2.40.0 pedig az MCP-hibakezelést javította.

Ha a cégnek van fejlesztője, az n8n helyett közvetlenül is megírhatja a szervert, például a Paper2Agent által is használt FastMCP könyvtárral Pythonban. Ez rugalmasabb és egy Odoo- vagy CRM-integrációnál gyakran tisztább megoldás, cserébe a naplózást, a hitelesítést és az újraindítást is magának kell megoldania.

Hogyan teszteld az eszközöket a Paper2Agent módszerével?

A Paper2Agent minden eszközt referenciaeredményekhez mér: a számoknak 3%-os tűréshatáron belül kell egyezniük, az ábráknak vizuálisan hasonlítaniuk kell a referenciára, egy hibás funkció pedig legfeljebb hat próbálkozást kap. Ami ezután sem megy át, az kimarad a szerverből. Céges eszközöknél ugyanez a logika működik, csak szigorúbb tűréssel.

A Nature-tanulmány módszertani része szerint egy eszköz akkor megy át, ha létrejönnek az elvárt fájlok, a számszerű eredmények a tűréshatáron belül vannak, az ábrák pedig egy észlelési hash-összevetés alapján megegyeznek a referenciával. Innen ered az a hat eszköz is, amely az 599-ből kiesett: ezeket a rendszer az ismételt próbálkozások után sem tudta átvinni a teszten, ezért inkább kihagyta őket, mint hogy hibásan tegye elérhetővé. Ez a hozzáállás többet ér bármilyen pontossági százaléknál.

Egy árkalkulátornál a 3% persze túl engedékeny, hiszen egy 480 000 Ft-os ajánlatnál ez 14 400 Ft eltérést jelentene. Céges eszközöknél az összegeknél forintra pontos egyezést érdemes elvárni, a kerekítési szabályt pedig előre rögzíteni. A tesztelést két szinten érdemes elvégezni, ahogyan a Paper2Agent is külön ellenőrizte az egyes eszközöket, majd a 300 kérdéses teszten az egész ügynököt.

Az ügynökszintű tesztnél a Paper2Agent egyik figyelmeztetése is ide tartozik: a referenciához mért egyezés a hű végrehajtást méri, nem az üzleti döntés helyességét. Ha a kedvezményrendszered rossz, az eszköz hibátlanul fogja kiszámolni a rossz árat.

Mennyibe kerül egy dokumentumokból épített MCP-szerver?

Saját becslésünk szerint egy kis cég első, háromeszközös MCP-szervere 28 és 32 fejlesztői óra közötti munka, ami egy feltételezett 10 000 Ft-os óradíjjal számolva nagyjából 280 000 és 320 000 Ft. A havi futtatás ennél jóval olcsóbb, mert csak az automatizációs platform díjából és a kérdésenként néhány forintos tokenköltségből áll.

A becslés menete a következő. A szabálytáblák kialakítása és az adatok rendbetétele körülbelül 8 óra, a három eszköz al-munkafolyamatként eszközönként nagyjából 4 óra, vagyis 12 óra, a tesztkészlet és a tesztelő munkafolyamat 6 óra, az MCP-szerver, a hitelesítés és a kliens bekötése további 4 óra. Ez összesen 30 óra, amely a dokumentumok rendezettségétől függően néhány órával el is térhet. A futtatásnál az AgentStack elemzése szerint az n8n Starter csomagja havi 20 dollár, ami kerekített árfolyammal 6 400 Ft, a tokenköltség pedig havi 400 kérdésnél a GPT-6 Astrával körülbelül 5 200 Ft, a Muse Spark 1.3-mal nagyjából 600 Ft.

Hogy megéri-e, azt egy képzeletbeli példa mutatja meg. Tegyük fel, hogy a balatoni panzió havonta 400 árajánlatkérést kap, amelyek egyenként 6 perc munkát jelentenek a recepción, ez havi 40 óra. Ha az ügynök elkészíti az ajánlat tervezetét és a recepciós egy-egy perc alatt jóváhagyja, a ráfordítás nagyjából 6,7 órára csökken, a megtakarítás így havi 33,3 óra. Egy feltételezett 4 000 Ft-os óránkénti bérköltséggel ez körülbelül 133 200 Ft havonta, amiből a futtatás költsége (Astrával és n8n-nel együtt nagyjából 11 600 Ft) levonása után körülbelül 121 600 Ft marad. A 300 000 Ft-os fejlesztés így nagyjából két és fél hónap alatt térül meg.

Ugyanez a számítás azt is megmutatja, mikor nem éri meg. Ha havonta csak 60 ilyen kérdés érkezik, a megtakarítás 5 óra körül van, ami havi 20 000 Ft, a platformdíj és a tokenek levonása után pedig nagyjából 12 800 Ft marad, így a megtérülés közel két évre nyúlik. Ilyenkor jobb egy egyszerű RAG-alapú asszisztens vagy akár csak egy jól megírt Excel-kalkulátor a kolléga gépén.

Felmerülhet a kérdés, miért kerül egy céges eszköz ennyivel többe, mint a Paper2Agent 14 dolláros, vagyis 4 480 Ft-os AlphaGenome-szervere. A válasz a kiindulópontban rejlik: a Paper2Agent futtatható kódból és kidolgozott példákból indult, egy KKV viszont jellemzően PDF-ekből, e-mailekből és szóbeli szabályokból. A drága rész itt nem a gépi munka, hanem a tudás táblázatba rendezése. Ha viszont a cégnek már van például egy Git-tárban tárolt, példákkal ellátott árazó szkriptje, a Paper2Agent MIT-licencű kódja közvetlenül is kipróbálható rajta, feltéve, hogy a fejlesztő tisztában van vele, hogy a kód a feldolgozás során a modellszolgáltatóhoz kerül.

Biztonság és adatvédelem: mit engedj meg az ügynöknek?

Az árlista és az ÁSZF azért ideális első projekt, mert jellemzően nem tartalmaz személyes adatot. Amint egy eszköz ügyféladatot olvas, például rendelési státuszt vagy számlatörténetet, a GDPR teljes súlyával érvényes rá: frissíteni kell az adatkezelési tájékoztatót, adatfeldolgozói szerződés kell a modellszolgáltatóval, a hozzáférést pedig a lehető legszűkebbre kell szabni.

Az MCP-végpontot soha ne hagyd hitelesítés nélkül. Szeptember elején egy aktívan kihasznált hiba került nyilvánosságra a LiteLLM nevű, széles körben használt nyílt forráskódú modellátjáróban, amellyel meg lehetett kerülni az MCP-hitelesítést és így elérhetővé váltak a csatolt eszközök. A tanulság egyszerű: az MCP-szerver ugyanolyan belépési pont a céges rendszereidbe, mint egy admin felület, ezért erős tokent, rendszeres frissítést és naplózást érdemel. Az n8n-ben az eszközök mögötti hitelesítő adatok is legyenek csak olvasási jogúak, ahol ez megoldható.

A promptinjekció a dokumentumalapú rendszerek sajátos kockázata. Egy dokumentumba vagy ügyfélüzenetbe rejtett szöveg megpróbálhatja rávenni az ügynököt, hogy olyasmit tegyen, amit nem kellene. A szigorú paraméterekkel dolgozó eszközök itt is segítenek, mert egy „konyha_arajanlat” eszközön keresztül legfeljebb egy rossz árat lehet kérni, adatot kiküldeni nem. A spanyol adatvédelmi hatóság szeptember 17-én egy lehetséges, ügynök által végrehajtott adatszivárgásról számolt be, amelynek kiváltó okát még vizsgálják. Az eset jól mutatja, miért érdemes minden eszközhívást naplózni.

Végül egy szabályozási szempont: az Európai Unió mesterségesintelligencia-rendeletének (EU AI Act) 50. cikke 2026 augusztusa óta előírja, hogy jelezni kell, ha a felhasználó AI-rendszerrel lép kapcsolatba. Ha tehát az árlistát kezelő ügynök a honlapon vagy e-mailben közvetlenül az ügyfelekkel beszélget, ezt egyértelműen közölni kell velük.

Miben segít a Convergo?

Ha a céged árlistája, ÁSZF-je vagy belső útmutatói ma még csak PDF-ben és a kollégák fejében élnek, a Convergo segít ezekből megbízható AI-eszközt építeni. A dokumentumfeldolgozás és OCR szolgáltatásunkkal rendbe tesszük és táblázatba rendezzük a szabályokat, a tudásbázis-alapú chatbotunk a szöveges kérdésekre RAG-gel válaszol, a számítást igénylő feladatokhoz pedig workflow automatizáció keretében n8n-alapú, tesztelt MCP-eszközöket készítünk. Ha a meglévő Odoo-, CRM- vagy webshoprendszeredhez kell kapcsolódni, egyedi AI-integrációval kötjük be az ügynököt, átgondolt jogosultságokkal és naplózással. Az első lépés egy ingyenes egyeztetés, ahol közösen kiválasztjuk azt a három kérdéstípust, amelynél egy eszköz a legtöbbet hozhatja.