AI MCP szerver fejlesztés a rendszereidhez

Az AI-t már bevezettétek a cégnél, a demó jól nézett ki, a napi munka viszont ugyanúgy zajlik, mint korábban. A kolléga megkérdezi az AI asszisztenst, kap egy szép választ, aztán kézzel viszi át oda, ahol a munka ténylegesen zajlik: a rendelést az ügyviteli rendszerbe, a partneradatot a CRM-be, a készletmozgást a raktárrendszerbe.

Az ok magában az eszközben van. Egy általános AI asszisztens okos ugyan, de a te rendszereidet nem látja. Beolvassa, amit bemásolsz neki, megfogalmaz egy emailt, összefoglal egy dokumentumot, a céges rendszereidbe viszont nem tud belenyúlni. Nem kér le belőlük élő adatot, és az eredményt sem tudja visszaírni. Így minden „cselekvés” végül kézi másolással és beillesztéssel ér véget.

Közben sok rejtett költség keletkezik. A kolléga kimásol egy adatot, beilleszti az AI-ba, megvárja a választ, aztán kézzel visszamásolja. Az átmásolásnál hiba is becsúszhat. Ráadásul úgy érzitek, hogy az AI mégsem vett le annyi munkát, amennyit vártatok tőle. Ezek külön-külön apróságok, együtt viszont folyamatos súrlódást okoznak, ami addig fel sem tűnik, amíg valaki konkrétan rá nem mutat.

Gyakori eset az is, hogy valaki kézzel bekötötte az agentet egy rendszerbe: írt egy scriptet, ami az egyik API-t hívja, összerakott egy webhookot, ami néha lefut. Mindez egyetlen rendszerre és egyetlen feladatra készült, gyorsan. Aztán jött a második rendszer, a harmadik, és mindegyikhez külön bekötés kellett. A jogosultságkezelés, a naplózás és a hibakezelés vagy elmaradt, vagy minden integrációnál újraíródott, kicsit másképp. A végén a vezetők megint nem tudják pontosan megmondani, mihez fér hozzá az agent és mit csinál.

Ezekben a helyzetekben szokott felmerülni az igény egyedi MCP szerverre:

• Kézi átvitel. Az asszisztens válaszol, az eredményt a kollégád viszi át kézzel a rendszerbe.
• Nincs kész konnektor. Az agentnek a saját, egyedi rendszereitekhez kellene hozzáférnie.
• Összedrótozott bekötések. Valaki már megírt egy-egy scriptet, de a jogosultság, a naplózás és a hibakezelés hiányzik belőlük.
• Kritikus műveletek. Az agentnek rendelést kellene rögzítenie vagy státuszt frissítenie, és egy tévedésnek valódi következménye lenne.
• Visszakereshetőség. Auditnál vagy partneri vitánál vissza kell nézni, mit tett az automatizmus és mikor.

Mielőtt bárki egyedi fejlesztésről beszélne, mi mindig azt nézzük meg először, hogy létezik-e a célra készült, dobozos megoldás.

A népszerű, dobozos rendszerekhez egyre több hivatalos, kész MCP szerver érhető el, a nagy SaaS-eszközöktől a bevett adatbázisokon át a fejlesztői platformokig. A felmérés elején megnézzük, van-e már kész szerver a te rendszeredhez. Ha a te agentednek pont egy ilyen rendszerhez kell hozzáférnie, akkor azt kösd be. Alacsonyabb a belépő, gyorsabban indulsz, és a szervert a gyártó tartja karban. Ha ez megfelel a céljaidnak, mi ezt javasoljuk. 

Az egyedi MCP fejlesztés akkor jön szóba, amikor nincs kész konnektor. A cégek legnagyobb értéke jellemzően a saját rendszereikben van: a több éve testre szabott ERP, a házon belül fejlesztett ügyviteli rendszer, a szektorspecifikus háttérrendszer, a régi, dokumentálatlan alkalmazás, amihez a csapatod már nem szívesen nyúl hozzá. Ezekhez dobozos MCP szerver nem is létezhet, hiszen pont attól egyediek, hogy a te folyamataidra épültek.

Ugyanez igaz akkor is, ha egyedi AI agent épül a saját folyamataidra. Az agent önmagában okos, a te rendszereidet viszont csak egy rá szabott átjárón keresztül éri el. Az egyedi MCP szerver ezt a rést hidalja át: a meglévő rendszert érintetlenül hagyja, és mellé épül be az a kontrollált felület, amin keresztül az agent biztonságosan dolgozhat vele.

Az MCP szerver fejlesztés kérdésekkel indul. Először megértjük, mit akarsz elérni, aztán tervezünk, fejlesztünk és élesítünk. 

1. Feltárás és tervezés. Először azt tisztázzuk, melyik rendszerhez és milyen feladathoz kell hozzáférnie az agentnek. Megnézzük, van-e API, van-e dokumentáció, van-e tesztkörnyezet. Azt is végigvesszük, mit elég az agentnek olvasnia, mibe avatkozhat be, és a beavatkozó műveletek közül melyik visszafordíthatatlan. Egy modern, jól dokumentált rendszernél más a megközelítés, mint egy húszéves, dokumentálatlan alkalmazásnál. A végén funkcionális és integrációs specifikációt készítünk, és csak annak lezárása után indul a fejlesztés.

2. Lépésenkénti fejlesztés. Minden szintet külön építünk és élesítünk. Először a csak olvasható hozzáférés jön, tehát az agent lát, de nem nyúl bele semmibe. Utána a biztonságos, visszafordítható műveletek. Végül a kritikus, beavatkozó lépések, eleve emberi jóváhagyással. Az agent mozgásterét csak akkor tágítjuk, ha az előző szint megbízhatóan működik.

3. Valódi tesztelés. Egy cselekvő agentnél a tesztelés a hibás eseteket keresi. Mi történik, ha az agent félreérti a feladatot? Ha egy beérkező dokumentumba rejtett utasítás próbálja félrevezetni? Ha a célrendszer a művelet közepén elérhetetlenné válik? Ha egyszerre sokkal több kérés érkezik, mint általában? Ezek élesben is előfordulnak, ezért az éles adatokhoz legközelebb álló környezetben tesztelünk.

4. Fokozatos élesítés. Amíg lehet, az agent megfigyelt módban dolgozik: előkészíti a műveleteket, ember hagyja jóvá, majd összevetjük, azt tette-e, amit vártunk. Ahogy nő a bizalom, úgy engedjük el az emberi jóváhagyás alól azokat a lépéseket, amelyek biztonságosan automatizálhatók. Ez a lépcsőzetes átállás jóval kisebb kockázatú, mint egy egynapos átkapcsolás.

5. Dokumentáció, monitoring, AI Ops. Az MCP szerver nem lehet fekete doboz. Dokumentáljuk, mihez fér hozzá az agent, hol lehet beavatkozni, és mit kell figyelni. Az élesítéssel együtt beáll a monitoring és a riasztás, és elindul az AI Ops: figyeljük az agent viselkedését, a műveletek minőségét, a fogyasztást és a biztonsági határokat. A support maradhat nálunk, vagy a dokumentáció átadásával a saját csapatod is átveheti.

Ha egy feladatot egy egyszerű szabály vagy egy meglévő automatizmus jobban megold, azt javasoljuk. A visszatérő, jól szabályozható feladatokra gyakran egy ütemezett folyamat is elég.

Az agent a kollégáid munkáját gyorsítja, és a repetitív, hibalehetőséget rejtő lépéseket veszi le a vállukról. Az üzleti döntés, az architektúra és a végső felelősség emberi feladat marad. Ezért kérünk emberi jóváhagyást a kritikus lépéseknél: az agent a te szabályaid szerint dolgozik, a döntést viszont te hozod meg.

A specifikációban csak olyat rögzítünk, amit mérni is tudunk. Olyan kontrollált és naplózott MCP szervert építünk, amelyen keresztül az agent biztonságosan dolgozhat a rendszereiddel.

Ha az alábbiak közül többet felismersz a saját helyzetedben, akkor érdemes egyedi MCP szerverről beszélnünk:

• Már használtok AI agentet vagy asszisztenst, a kolléga viszont még mindig kézzel viszi át az eredményt a rendszereitekbe.
• Az agentnek a saját, egyedi rendszereitekhez kellene hozzáférnie (testre szabott ERP, szektorspecifikus háttérrendszer), és ezekhez nincs kész konnektor.
• Az agentnek olvasnia és cselekednie is kellene a rendszereitekben: rendelést rögzíteni, státuszt frissíteni, piszkozatot előkészíteni.
• Valaki már kézzel bekötött egy-egy agentet egy-egy rendszerbe, a jogosultságkezelés, a naplózás és a hibakezelés viszont hiányzik vagy minden rendszernél újraíródik.
• Kritikus, visszafordíthatatlan műveletekről van szó, ahol fontos, hogy az agent pontosan mihez férhet hozzá, és hol kell emberi jóváhagyás.
• Auditnál, megfelelésnél vagy partneri elszámolásnál vissza kell nézni, mit tett az automatizmus, mikor és milyen jogosultsággal.
• Nyílt szabványra épülő, hordozható megoldást szeretnél, hogy később szabadon válthass AI szállítót.

Ha még ott tartasz, hogy nem tudod, hol érné meg egyáltalán agentet bevezetni, akkor előbb az AI tanácsadás és az AI Discovery a lépés. Felmérjük az operatív működésedet, és megnevezzük, mit érdemes agenttel és mit hagyományos automatizálással megoldani. Ha pedig már tudod, hova kell az agent, és a meglévő rendszereidbe kell bevinni, akkor az AI integráció és az MCP szerver a következő lépés.

Beszéljünk a projektedről. Egy rövid egyeztetésen kiderül, elég-e egy kész konnektor, vagy tényleg egyedi MCP fejlesztés a helyes út, és mit érdemes előbb tisztáznunk.

❓ Mit jelent a Model Context Protocol?
A Model Context Protocol (MCP) nyílt szabvány, amely egységes módot ad az AI agentnek arra, hogy eszközöket használjon és adatot kérjen le a meglévő rendszerekből. Az Anthropic tette közzé 2024 novemberében, azóta az OpenAI, a Google és a Microsoft is támogatja, 2025 végén pedig a Linux Foundation gondozásába került. Az MCP szerver az a komponens, ami a te rendszeredet elérhetővé teszi ezen a szabványon keresztül.

⚙️ Miben más egy MCP szerver, mint egy egyszerű API bekötés?
Az API bekötés egyetlen agentet köt egyetlen rendszerhez. Az MCP szerver szabványos átjárót ad, amit utána bármelyik MCP-kompatibilis agent használni tud. Emellett a jogosultságkezelés, a naplózás, a hibakezelés és az emberi jóváhagyás egy helyen, a szerverben van megoldva.

✔️ Kell egyedi MCP fejlesztés, ha van kész konnektor a rendszeremhez?
Ha kész MCP szerver érhető el a rendszeredhez, kösd be azt. Alacsonyabb a belépő, gyorsabban indulsz, és a szervert a gyártó tartja karban. Az egyedi MCP fejlesztés akkor jön szóba, amikor nincs kész konnektor: a testre szabott ERP-nél, a házon belül fejlesztett ügyviteli rendszernél vagy a régi, dokumentálatlan alkalmazásnál.

⚠️ Mennyire biztonságos, ha az AI agent hozzáfér a rendszereinkhez?
Az agent annyit lát és annyit tehet, amennyit az MCP szerveren kifejezetten megengedsz neki. A hozzáférést a meglévő jogosultsági szabályaidhoz és a bevett belépési megoldásokhoz kötjük, a visszafordíthatatlan lépéseknél emberi jóváhagyást kérünk, és minden művelet naplózva van. A prompt injection ellen a bemenetre és a kimenetre védelmi réteg kerül, a szerver pedig eleve csak a szűken engedélyezett műveleteket teszi elérhetővé.

⚖️ Mi történik, ha az agent félreérti a feladatot?
A generatív AI nem determinisztikus, ezért kétszer ugyanazt kérve nem feltétlenül ugyanazt teszi. Az MCP szerver ezzel számol. Validálja a paramétereket a művelet előtt, ellenőrzi, hogy a kérés értelmes-e, a nem elérhető célrendszernél pedig újrapróbál vagy félreteszi a feladatot. A kritikus lépéseknél ember hagyja jóvá a műveletet, tehát egy félreértésből nem lesz kár.

⚡ Mennyi idő alatt lesz belőle működő megoldás?
A felméréssel és a specifikációval kezdünk, és onnan lépésenként haladunk: először a csak olvasható hozzáférés, utána a visszafordítható műveletek, végül a kritikus lépések. Az időtáv attól függ, hány rendszerhez kell hozzáférni, milyen állapotban vannak az interfészek, és mennyire összetettek az üzleti szabályok. Egy jól dokumentált, modern API-val rendelkező rendszer gyorsabban megy, mint egy húszéves, dokumentálatlan alkalmazás.

€ Mennyibe kerül egy egyedi MCP szerver?
A keret a kapcsolódó rendszerek számától, az interfészek állapotától, az üzleti logika összetettségétől és a biztonsági elvárásoktól függ. Ezért kezdünk felméréssel és specifikációval, mert annak alapján tudunk fix költségvetéssel ajánlatot adni. Ha nincs még specifikációd, elkészítjük.

♾️ Hozzá leszünk kötve egy AI szállítóhoz?
Az MCP nyílt szabvány, ezért a rendszeredhez egyszer megírt MCP szervert bármelyik MCP-kompatibilis agent használni tudja. Ha később más modellre vagy más agent-platformra váltanál, a szerver marad. Ez az egyik fő oka annak, hogy érdemes szabványra építeni.

➕ Mi a különbség az AI integráció és az MCP szerver között?
Az AI integráció a tágabb fogalom: arról szól, hogyan kerül AI képesség a meglévő rendszereidbe, akár API bekötéssel, akár RAG-gal, akár saját modellel. Az MCP szerver ennek egy konkrét esete, és akkor jön szóba, amikor egy cselekvő AI agentnek kell kontrollált hozzáférést adni a rendszereidhez. A legtöbb projekt az AI tanácsadással indul, és onnan lép tovább.

Írd le, milyen rendszerekhez szeretnéd hozzáférést adni az AI agenteknek, és milyen műveleteket végeznének bennük. Segítünk megtervezni a biztonságos MCP integrációt, a szükséges jogosultságokat és jóváhagyási folyamatokat.