MCP-szerver cégeknek: biztonságos AI-kapcsolat a céges rendszerekhez

Az MCP-szerver olyan szolgáltatás, amelyen keresztül egy AI-asszisztens kiválasztott céges adatokat olvashat, és pontosan körülhatárolt műveleteket indíthat az Ön rendszereiben, például a CRM-ben, az ERP-ben vagy a webáruházban. A hivatalos dokumentáció szerint a Model Context Protocol (MCP) nyílt szabvány az AI-alkalmazások külső rendszerekhez való csatlakoztatására; támogatja többek között a Claude, a ChatGPT, a Visual Studio Code és a Cursor (MCP-dokumentáció).

Egy cégnek akkor érdemes MCP-szervert használnia, ha azt szeretné, hogy a munkatársak közvetlenül az AI-asszisztensben dolgozzanak a céges adatokkal. Ha csak rendszeresen adatokat kell mozgatnia két rendszer között, nincs szüksége MCP-re. Egy dolog pedig már az elején fontos: a biztonságot nem maga a protokoll biztosítja, hanem az, hogy milyen eszközöket tesz elérhetővé, hogyan azonosítja a felhasználókat, és mely műveleteket kell egy embernek jóváhagynia.

Mi az MCP-szerver, és mit tehet elérhetővé

Az MCP-specifikáció három szerepet különböztet meg. A host az az AI-alkalmazás, amely a kapcsolatot kezdeményezi, a kliens az alkalmazáson belüli csatlakozó, a szerver pedig kontextust és képességeket biztosító szolgáltatás. Egymással JSON-RPC 2.0 formátumú üzeneteket váltanak (MCP-specifikáció).

A szerver háromféle funkciót kínálhat:

Erőforrások (resources) – kontextus és adatok a felhasználó vagy az AI-modell számára, például egy árlista vagy egy belső szabályzat.
Promptok (prompts) – előre elkészített üzenet- és munkafolyamat-sablonok a felhasználóknak, például „foglald össze az ügyfél helyzetét”.
Eszközök (tools) – az AI-modell által végrehajtott funkciók, például egy rendelés megkeresése vagy egy árajánlat-tervezet létrehozása.

A legtöbb figyelmet az eszközök igénylik. A specifikáció szerint a modell maga is felfedezheti és meghívhatja őket a kontextus és a felhasználó kérése alapján (MCP: eszközök). A specifikáció arra is figyelmeztet, hogy az eszközök tetszőleges kód futtatását jelentik, a hostnak a meghívásuk előtt kifejezett felhasználói hozzájárulást kell szereznie, és ezeket az elveket maga a protokoll nem tudja kikényszeríteni (MCP-specifikáció).

Mikor válasszon MCP-szervert, API-integrációt vagy saját alkalmazást

Az MCP-szerver nem vált ki minden integrációt. Abból induljon ki, ki indítja a folyamatot, és mennyire pontosan kell lezajlania.

Helyzet	Megfelelő megoldás	Miért
A munkatársak az AI-asszisztensben szeretnének keresni és dolgozni több rendszer adataival.	MCP-szerver	Egyetlen szabványos réteget több olyan kliens is használhat, amely támogatja az MCP-t.
Két rendszernek rendszeresen, emberi beavatkozás nélkül kell adatot cserélnie, például a webáruház rendeléseit az ERP-be.	API-integráció	Egy rögzített, megismételhető adatfolyamhoz nem kell önállóan döntő nyelvi modell.
A folyamatnak rögzített lépései, jóváhagyásai és egyértelmű felelőse van, például egy reklamáció kezelése.	Saját alkalmazás vagy irányított AI-munkafolyamat	Az állapotokat, a jogosultságokat és az auditnaplót a saját felületén tartja kézben.
Egyszeri elemzést kell készítenie egy adatexportból.	Export tartós kapcsolat nélkül	Egy egyszeri feladathoz nem éri meg olyan szervert üzemeltetni, amelyet védeni és karbantartani kell.

A specifikáció szerint az MCP-szerver eszközei például API-kat hívhatnak vagy adatbázisokat kérdezhetnek le (MCP: eszközök). Céges rendszereknél saját, korlátozott jogosultságú API-kapcsolatot javaslunk. Ha a rendszernek nincs használható API-ja, ott kezdje: egy jól megtervezett API-integráció az alap, amelyre később az MCP-réteg ráépíthető.

Biztonság: mit ír elő a specifikáció, és mit kell Önnek kiegészítenie

Helyi vagy távoli szerver

A specifikáció ajánlása szerint az a helyi szerver, amellyel a kliens a szabványos bemeneten és kimeneten (STDIO) kommunikál, a hozzáférési adatokat a környezetből veszi. A HTTP-n elérhető szerverekhez a specifikáció OAuth 2.1-re épülő jogosultságkezelést határoz meg (MCP: jogosultságkezelés).

Gyakorlati javaslat: egy munkatárs laptopján futó, API-kulccsal működő helyi szerver fejlesztéshez vagy személyes teszthez megfelel. Csapatnak alkalmasabb egy távoli szerver, ahol minden felhasználó a saját identitásával jelenik meg, és a hozzáférés központilag visszavonható.

Jogosultságkezelés és tokenek

Az MCP-ben a jogosultságkezelés formálisan opcionális, céges adatoknál azonban tekintse kötelezőnek. A védett MCP-szerver az OAuth 2.1 szerinti erőforrás-szerverként (resource server) működik. A tokeneket egy engedélyezési szerver adja ki, amely futhat az MCP-szerverrel együtt vagy külön is (MCP: jogosultságkezelés).

A projekt feladatleírásába elsősorban a specifikáció alábbi követelményei tartoznak:

a szervernek ellenőriznie kell, hogy a hozzáférési tokent kifejezetten neki állították-e ki, más tokeneket pedig nem fogadhat el és nem adhat tovább,
érvénytelen vagy lejárt tokenre HTTP 401 válasszal felel,
a tokent az Authorization fejlécben kell küldeni, soha nem az URL paramétereiben,
a kliens csak a valóban szükséges jogosultságokat (scopes) kérje; elégtelen jogosultság esetén a szerver HTTP 403 kódot és insufficient_scope hibát adjon vissza, a kliens pedig bővebb hozzáférést kérhet.

Hasznos az is, hogy a szerver a hívó jogosultságai szerint adhatja vissza az eszközök listáját. Így egy értékesítő más eszközöket láthat, mint az értékesítési vezető (MCP: eszközök).

Eszközök, bemenetek és kimenetek

A specifikáció szerint a szervereknek minden eszközbemenetet ellenőrizniük kell, hozzáférés-szabályozást kell alkalmazniuk, korlátozniuk kell a hívások gyakoriságát, és meg kell tisztítaniuk a kimeneteket. A klienseknek a specifikáció az érzékeny műveletek felhasználói jóváhagyását, a bemenetek megjelenítését a szerverre küldés előtt, időkorlátokat és a hívások auditcélú naplózását ajánlja (MCP: eszközök).

Emberi jóváhagyás

A specifikáció szerint az eszközöknél mindig legyen egy ember, aki elutasíthatja a hívást. A protokoll azonban nem ír elő konkrét felhasználói interakciós modellt, így a jóváhagyás formája a klienstől függ (MCP: eszközök). Az írási műveleteket ezért úgy tervezze meg, hogy egy elhamarkodott jóváhagyás után is biztonságosak maradjanak, például tervezetként, amelyet egy ember az eredeti rendszerben fejez be.

Példa: egy értékesítő felkészül egy megbeszélésre

Szemléltető példa, nem valódi ügyfélprojekt. Egy disztribúciós cég CRM-et és ERP-t használ. Egy értékesítő a megbeszélés előtt ezt szeretné írni az AI-asszisztensnek: „Készíts nekem anyagot a holnapi megbeszéléshez az ABC ügyféllel.”

A pilotban az MCP-szerver négy szűk eszközt tesz elérhetővé:

find_customer – megkeresi az ügyfelet, de csak a bejelentkezett értékesítőhöz rendelt ügyfelek között,
list_recent_orders – visszaadja az elmúlt 12 hónap rendeléseit a belső árrés-megjegyzések nélkül,
list_open_invoices – visszaadja a számlák összegét, esedékességét és állapotát banki adatok nélkül,
create_quote_draft – az ERP-ben csak árajánlat-tervezetet hoz létre, amelyet egy ember küld el az ügyfélnek.

Az első három eszköz csak olvasásra szolgál. A negyediket csak az ajánlatkészítési jogosultsággal rendelkező felhasználók látják; futtatása előtt az értékesítőnek a kliensben jóvá kell hagynia a megjelenített bemeneteket, a szerver pedig naplózza, ki, mikor és milyen paraméterekkel használta az eszközt. Ha az AI-asszisztens félreérti a kérést, a legrosszabb eredmény egy hibás tervezet, nem egy már elküldött ajánlat.

Bevezetés hét lépésben

A lépések feltételezik, hogy a rendszernek van API-ja vagy más felülete, amelyhez biztonságosan lehet csatlakozni.

Válasszon ki egyetlen feladatot. Például a megbeszélésre való felkészülést vagy egy rendelés állapotának lekérdezését. A „kössük össze az AI-t mindennel” típusú feladatot nem lehet tesztelni.
Írja össze az adatokat és a műveleteket. Minden adatnál döntse el, hogy az AI olvashatja-e, és minden műveletnél, hogy elindíthatja-e. Személyes és érzékeny adatokat csak akkor adjon vissza, ha a feladathoz nélkülözhetetlenek.
Tervezzen szűk eszközöket. Ne legyen univerzális eszköz, például „futtass SQL-t” vagy „hívj meg bármilyen API-t”. Minden eszköznek pontos bemeneti sémája és korlátai vannak, strukturált eredményeknél pedig kimeneti sémája is, amelynek a szerver válaszának meg kell felelnie (MCP: eszközök).
Állítsa be a jogosultságkezelést. Távoli szerver felhasználói identitással, szerepkör szerinti jogosultságokkal és annak ellenőrzésével, hogy a token éppen ehhez a szerverhez tartozik. A CRM vagy az ERP hívásához a szerver külön, korlátozott hozzáférési adatokat használjon.
Egészítse ki üzemeltetési biztosítékokkal. Bemenet-ellenőrzés, hívásgyakoriság-korlátok, időkorlátok, kimenettisztítás és auditnapló.
Állítsa be a jóváhagyást. Az írási eszközök jóváhagyást igényelnek, a pilotban pedig semmit sem törölhetnek, és semmit sem küldhetnek a cégen kívülre.
Indítson pilotot egy kis csoporttal. Előre határozza meg, meddig tart, és mi alapján értékeli. Kísérje figyelemmel a naplókat, a hibákat és azokat a kérdéseket, amelyekre az eszközök nem voltak elegendők, és csak ezután bővítse az eszközöket vagy a felhasználói kört.

Kompromisszumok, amelyeket tudatosan kell vállalni

Rugalmasság kisebb kiszámíthatóság árán. A modell maga dönti el, melyik eszközt hívja meg. Az előre nem ismert kérdéseknél ez előny. Azoknál a folyamatoknál, amelyeknek mindig ugyanúgy kell lezajlaniuk, hátrány, ott irányított munkafolyamatra van szükség.

Egy integráció, különböző kliensek. Az MCP-dokumentáció szerint a széles körű támogatásnak köszönhetően egy integrációt elég egyszer elkészíteni, és különböző alkalmazásokban lehet használni (MCP-dokumentáció). Azt viszont, hogy egy adott kliens hogyan jeleníti meg az eszközöket és a jóváhagyásokat, minden engedélyezni kívánt kliensnél ellenőrizni kell.

A protokoll fejlődik. Az MCP-verziókat az utolsó, visszafelé nem kompatibilis változtatás dátuma jelöli; a cikk írásakor az aktuális verzió a 2026-07-28. Az elavult funkciók legalább 12 hónapig, gyorsított eltávolítás esetén legalább 90 napig a specifikáció részei maradnak (MCP: verziókezelés). Számoljon ezért a szerver rendszeres karbantartásával.

Az adatok az AI-modellhez kerülnek. Az eszközök eredményeit a kliens által használt modell dolgozza fel. Indulás előtt ellenőrizze a kliens szolgáltatójának adatkezelési feltételeit, és csak azokat az adatokat adja vissza, amelyekre a feladathoz valóban szükség van.

Gyakori hibák

Univerzális eszköz rendszergazdai kulccsal, amely szinte bármit megenged a modellnek.
Egyetlen közös szolgáltatásfiók mindenkinek, így nincsenek személyes jogosultságok, és auditnapló sincs.
Bármilyen token elfogadása a céges bejelentkezésből anélkül, hogy ellenőriznék, ehhez a szerverhez állították-e ki.
Tokenek URL-ekben vagy naplókban.
Az írási eszközök automatikus jóváhagyása emberi ellenőrzés nélkül.
Teljes, személyes adatokat tartalmazó rekordok ott, ahol egy összefoglaló is elég.
Harmadik féltől származó MCP-szerver csatlakoztatása ellenőrzés nélkül. A nem megbízható szerverektől származó eszközviselkedés-leírásokat nem megbízhatónak kell tekinteni (MCP-specifikáció).

Ellenőrzőlista az indulás előtt

Mielőtt a szervert az első felhasználók elé engedi, minden pontra igennel kell tudnia válaszolni:

Van egy konkrét feladatunk, és tudjuk, hogyan értékeljük a pilotot.
Minden eszköznek van felelőse, leírása, bemeneti sémája és korlátai.
Az olvasás és az írás külön eszközökben van; a törlés és a cégen kívülre küldés nem része a pilotnak.
A szerver ellenőrzi a felhasználó identitását és azt is, hogy a tokent neki állították ki.
Az eszközök listája és a visszaadott adatok megfelelnek a felhasználó szerepkörének.
Az írási eszközök jóváhagyást igényelnek, és csak tervezeteket hoznak létre.
A hívások naplózva vannak, van időkorlátjuk, és korlátozott a gyakoriságuk.
A hozzáférést gyorsan vissza tudjuk vonni egy-egy felhasználótól és egy teljes klienstől is.
Ismerjük az AI-kliens szolgáltatójának adatkezelési feltételeit.
Tudjuk, ki frissíti a szervert, ha megjelenik a protokoll új verziója.

Gyakori kérdések

Szükségünk van MCP-szerverre, ha már van API-nk?

Csak akkor, ha az adatokkal AI-asszisztensből szeretnének dolgozni. Az API marad az alap, az MCP-szerver pedig erre épít egy olyan eszközréteget leírásokkal, sémákkal és jogosultságokkal, amellyel az AI-kliens dolgozni tud. Ha nincs szükségük AI-asszisztensre, maga az API is elég.

Törölhet vagy elküldhet valamit az AI egy MCP-szerveren keresztül a tudtunk nélkül?

Csak akkor, ha ilyen eszközt elérhetővé tesznek, és a kliens engedi a futtatását. A specifikáció azt ajánlja, hogy egy embernek mindig legyen lehetősége elutasítani az eszköz hívását. A legbiztosabb, ha a pilotban egyáltalán nem kínálnak törlő vagy küldő eszközöket.

Helyi vagy távoli MCP-szerver a jobb?

A helyi szerver fejlesztéshez és személyes használatra alkalmas, mert a hozzáférési adatokat a számítógép környezetéből veszi. Csapatnak alkalmasabb a távoli szerver OAuth 2.1 alapú jogosultságkezeléssel, személyes jogosultságokkal és a hozzáférés központi visszavonásának lehetőségével.

Bármelyik AI-asszisztenssel működni fog az MCP-szerver?

Csak az MCP-t támogató kliensekkel; a dokumentáció ezek között említi például a Claude-ot, a ChatGPT-t, a Visual Studio Code-ot és a Cursort. Az eszközök és a jóváhagyások megjelenítését a protokoll nem írja elő, ezért a kiválasztott klienst is be kell vonni a pilotba.

Következő lépés

Ha azt fontolgatja, hogy CRM-jét, ERP-jét vagy webáruházát elérhetővé teszi AI-asszisztensek számára, kezdje egyetlen feladattal és néhány csak olvasható eszközzel. Az eszközök, a jogosultságkezelés és a pilot megtervezésében egyedi AI-ügynökök szolgáltatásunk keretében segítünk. Keressen minket a kapcsolatfelvételi oldalon, és írja le a rendszert és a feladatot, amelyet egyszerűsíteni szeretne. További gyakorlati útmutatókat a Webiant blogján talál.

Források

What is the Model Context Protocol (MCP)? – bevezető az MCP hivatalos dokumentációjában
Specification (2026-07-28) – szerepek, szerverfunkciók és biztonsági elvek
Tools – eszközök, emberi felügyelet és biztonsági követelmények
Authorization – a HTTP-n elérhető MCP-szerverek jogosultságkezelése
Versioning – verziók jelölése és a funkciók életciklusa