MCP-szerver a cégadatokhoz: mit adj át az AI-ügynököknek

Scheo · 2026-09-28 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Egy AI-asszisztens kétféleképpen tudhat meg valamit a cégedről. Elolvashatja a weboldaladat, illetve azt, ami a keresőindexben vagy a tanítóadatban szerepel rólad. Vagy közvetlenül lekérdezheti a rendszeredet egy gépi felületen keresztül. Az MCP (Model Context Protocol) az utóbbihoz ad szabványos keretet. Ebben a cikkben végigmegyünk azon, mit érdemes egy ilyen felületen kiadni, mit kell lezárni, és hogyan döntheted el, hogy nálad megéri-e egyáltalán.

Háromféle állítást különítünk el a szövegben. A Hivatalosan igazolt rész a protokoll specifikációjából vagy a szolgáltatók dokumentációjából származik. A Saját tapasztalat az, amit weboldalak, webshopok és rendszerintegrációk üzemeltetése közben láttunk. A Szakmai feltételezés mérésekkel még alá nem támasztott következtetés, ezért fenntartással kezeld.

Mit jelent a gyakorlatban, ha a cégadataidat MCP-szerveren teszed elérhetővé?

Az MCP-szerver egy kis program, amely előre meghatározott kérdésekre ad strukturált választ az AI-ügynököknek, például arra, hogy mikor vagy nyitva szombaton, vagy van-e raktáron egy adott termék. Az ügynöknek nem kell a weboldal HTML-jét értelmeznie, mert kész adatot kap.

Hivatalosan igazolt. Az MCP nyílt protokoll, az Anthropic tette közzé 2024 végén. Azóta több nagy AI-szolgáltató eszközei is támogatják kliensként, így például az OpenAI és a Google fejlesztői eszközei. Egy szerver háromféle elemet kínálhat. Az eszközök (tools) meghívható függvények, az erőforrások (resources) olvasható adatok vagy dokumentumok, a promptok pedig előre megírt kérdéssablonok. A kapcsolat kétféleképpen jöhet létre, helyben futó folyamaton keresztül (stdio) vagy távoli HTTP-kapcsolaton (Streamable HTTP). Távoli szervereknél a specifikáció OAuth 2.1-re épülő engedélyezést ír le.

Saját tapasztalat. A leggyakoribb félreértés az, hogy az MCP-szerver a robots.txt-hez vagy a sitemaphez hasonlóan „kint van”, és az AI-ok maguktól megtalálják. A kliens azonban csak ahhoz a szerverhez csatlakozik, amelyet egy felhasználó vagy egy platform beállított neki. Egy átlagos ChatGPT-felhasználó asszisztense tehát nem kérdezi le a szerveredet csak azért, mert létezik. Léteznek nyilvános MCP-regiszterek és összekötő-katalógusok, de ezekben a megjelenés még nem jelent használatot.

Kinek éri meg ezzel foglalkozni, és kinek nem?

Annak éri meg, akinek az adatai sűrűn változnak, sok tételből állnak, és van valaki, aki ezeket géppel akarja elérni. Egy stabil nyitvatartású, néhány szolgáltatást kínáló helyi vállalkozásnak jó eséllyel többet hoz a rendben tartott weboldal és cégprofil.

Akiknek érdemes megvizsgálni

• Webshopok, ahol a készlet naponta többször változik, és a vevő az elérhetőséget kérdezi.
• Több telephelyes szolgáltatók, ahol telephelyenként eltér a nyitvatartás és a szolgáltatáskör.
• Foglalási rendszerrel dolgozó cégek, ahol a szabad időpont a legfontosabb információ.
• B2B forgalmazók nagy termékkatalógussal, műszaki adatlapokkal, ahol a partnerek már most is feedet vagy API-t kérnek.
• Szoftvercégek, ahol a dokumentációt a fejlesztők AI-eszközei olvassák.

Akiknek most még nem érdemes

• Akinek nincs adatbázisa, és az adatai egy Word-fájlban vagy egy munkatárs fejében élnek.
• Akinek senki nincs a cégben, aki a szervert üzemeltetni tudná, és nincs erre külsős partnere sem.
• Akinek a weboldalán még a nyitvatartás sem egyezik a Google-cégprofillal. Ott előbb azt kell rendbe tenni.

Szakmai feltételezés. Ahol már működik nyilvános API vagy termékfeed, ott az MCP-szerver egy vékony réteg a meglévő rendszer fölött, így a ráfordítás és a kockázat is kisebb. Ahol mindent nulláról kellene felépíteni, ott az adatrendezés önmagában is nagyobb haszonnal jár, mint maga a gépi felület.

Milyen adatokat szabad kiadni, és mit tarts vissza?

Csak olyan adatot adj ki, ami a weboldaladon ma is nyilvános, vagy amit bármelyik ügyfélnek elmondanál telefonon. Minden más maradjon a szerveren kívül, akkor is, ha technikailag egyszerű lenne kiadni.

Jellemzően kiadható

• Nyitvatartás telephelyenként, a rendkívüli zárvatartással és az ünnepnapi eltérésekkel együtt.
• Szolgáltatáslista rövid leírással, a kiszolgált területtel és a foglalás vagy ajánlatkérés linkjével.
• Elérhetőség, vagyis a cég hivatalos, nyilvános csatornái (központi e-mail, telefonszám, cím).
• Készlet sávosan (raktáron, kevés van, nincs), a pontos darabszám helyett.
• Nyilvános dokumentumok, például ÁSZF, termékadatlap, használati útmutató, garanciális feltételek.

Tartsd vissza

• Személyes adatot, köztük a munkatársak közvetlen elérhetőségét és bármilyen ügyféladatot. Erre a GDPR szigorú szabályai vonatkoznak.
• Beszerzési feltételeket, árrést, beszállítói adatot, belső folyamatleírást.
• Pontos készletszámot, ha az üzleti információ, és egy versenytárs visszafejthetné belőle a forgalmadat.
• Minden írási műveletet (foglalás, rendelés, módosítás) mindaddig, amíg az olvasási oldal hónapok óta hiba nélkül működik.

Szakmai feltételezés. Érdemes minden válasz mellé visszaadni a frissítés időpontját és a forrásoldal URL-jét. Így az ügynök jó eséllyel hivatkozni tud rá, a felhasználó pedig ellenőrizheti az adatot a weboldaladon.

Hogyan korlátozod a hozzáférést csak olvasásra?

A csak olvasható működést az adatbázis és a szerver szintjén kell kikényszeríteni. A protokoll jelzései ehhez önmagukban kevesek, mert csak tájékoztatnak, semmit nem tiltanak.

Hivatalosan igazolt. Az MCP-specifikáció lehetővé teszi, hogy egy eszközt annotációkkal láss el, például readOnlyHint vagy destructiveHint jelzéssel. A specifikáció ugyanakkor kimondja, hogy ezek csak jelzések, és a kliens nem építhet rájuk biztonsági döntést, ha a szerver nem megbízható. A tényleges korlát tehát nálad van.

1. Hozz létre külön adatbázis-felhasználót, amelynek csak olvasási (SELECT) joga van, és csak a nyilvános nézetekhez fér hozzá.
2. Készíts nézetet vagy külön exporttáblát, amely eleve csak a kiadható mezőket tartalmazza. Így egy programhiba sem tud belső adatot kiszivárogtatni.
3. Minden eszköz egy szűk, paraméterezett lekérdezést futtasson. Szabad szöveges lekérdezést az ügynök soha ne küldhessen.
4. Állíts be kéréskorlátot és válaszméret-korlátot, hogy egy rosszul működő ügynök ne terhelje túl a rendszert.
5. Ha az adat csak partnereknek szól, használd a specifikáció szerinti OAuth-alapú engedélyezést, és partnerenként külön hozzáférést adj.

Egy egyszerűsített Python-vázlat a hivatalos MCP Python SDK-val, amely csak olvasható módban nyitja meg az adatbázist:

from mcp.server.fastmcp import FastMCP import sqlite3 mcp = FastMCP('ceg-adatok') DB = 'file:nyilvanos.db?mode=ro' def lekerdez(sql, param=()): with sqlite3.connect(DB, uri=True) as kapcs: return kapcs.execute(sql, param).fetchall() @mcp.tool() def nyitvatartas(telephely: str) -> dict: '''Egy telephely heti és rendkívüli nyitvatartása.''' sorok = lekerdez('SELECT nap, nyit, zar FROM nyitvatartas_nyilvanos WHERE telephely = ?', (telephely,)) return {'telephely': telephely, 'nyitvatartas': sorok, 'forras': 'https://pelda.hu/kapcsolat'} @mcp.tool() def keszlet(cikkszam: str) -> dict: '''Készletsáv (raktáron, kevés, nincs) és a frissítés ideje.''' sor = lekerdez('SELECT sav, frissitve FROM keszlet_nyilvanos WHERE cikkszam = ?', (cikkszam,)) if not sor: return {'cikkszam': cikkszam, 'keszlet': 'ismeretlen'} return {'cikkszam': cikkszam, 'keszlet': sor[0][0], 'frissitve': sor[0][1]} if __name__ == '__main__': mcp.run()

Figyeld meg, hogy nem létező cikkszámnál a válasz „ismeretlen”. Az ügynöknek jobb egy őszinte „nem tudom”, mint egy kitalált alapérték, mert a hibás választ a felhasználó a te cégednek fogja tulajdonítani.

Ki tartja karban, és mi történik hibás adatnál?

Két felelős kell hozzá. Az adatgazda a tartalomért felel, a technikai gazda a szerver működéséért. A legbiztosabb megoldás az, ha a szerver ugyanabból a forrásból olvas, mint a weboldal, mert így egy javítás mindkét helyen egyszerre jelenik meg.

Saját tapasztalat. Ha a nyitvatartás három helyen él (weboldal, cégprofil, egy belső táblázat), akkor előbb-utóbb eltér egymástól, és általában épp akkor, amikor rendkívüli zárva tartás van. Egy újabb, külön karbantartott adatforrás ezt a kockázatot növeli. Ezért ne indíts MCP-szervert saját, kézzel frissített adatbázissal.

A hibás adat kezelésének menete legyen előre leírva:

1. Észlelés. Ügyfélbejelentés, a napló rendellenes mintázata vagy egy napi automatikus összevetés a weboldal és a szerver válasza között.
2. Javítás a forrásban. Soha ne közvetlenül a szerveren, mert a következő szinkron felülírja.
3. Gyorsítótár ürítése, ha a szerver vagy előtte egy proxy tárolja a válaszokat.
4. Rögzítés. Mi volt hibás, mettől meddig, és hány hívás kapta meg a hibás választ.
5. Kommunikáció, ha a hibás adatra valaki ténylegesen épített, például zárt napon érkezett.

Szakmai feltételezés. Az ügynök által már kiadott válaszokat nem tudod visszavonni, és azt sem tudod, hogy egy kliens mennyi ideig tárolja őket. Ezért érdemes a gyorsan változó adatot (készlet, szabad időpont) mindig a frissítés időpontjával együtt kiadni.

Milyen döntési listán menj végig, mielőtt belevágsz?

Ha az alábbi kérdések bármelyikére nincs egyértelmű válaszod, az MCP-szerver még korai. Előbb azt a hiányzó elemet kell rendbe tenni.

1. Van már API vagy adatbázis? Ha van, az MCP egy réteg fölötte. Ha nincs, előbb az adatot kell rendezni.
2. Egyetlen forrásból olvas mindenki? A weboldal, a cégprofil és az MCP-szerver ugyanabból az adatból dolgozzon.
3. Ki a felelős, név szerint? Egy adatgazda és egy technikai gazda, helyettessel.
4. Mezőszinten tudod, mit adsz ki? Írd le táblázatban, mezőnként indoklással.
5. Hogyan kényszeríted az olvasási korlátot? Külön adatbázis-felhasználóval, nézettel, paraméterezett lekérdezéssel.
6. Hogyan naplózol? Időpont, kliens, meghívott eszköz, paraméter, válaszidő, hibakód. IP-címet csak indokolt esetben tárolj, meghatározott megőrzési idővel.
7. Mi történik hibás adatnál? Legyen leírt, kipróbált menet.
8. Ki fogja ténylegesen használni? Egy partner, egy saját asszisztens, egy platform-integráció? Ha erre nincs válasz, a szerver jó eséllyel üresen fut.
9. Mi a kiinduló mérés? Rögzítsd a jelenlegi értékeket, mielőtt élesíted.

Hivatalosan igazolt. Kapcsolódáskor a kliens elküldi a nevét és verzióját (clientInfo), így a naplóban látszik, melyik alkalmazás kérdezett. Ezt a kliens maga adja meg, ezért tájékoztató adatként kezeld, hitelesítésre ne használd.

Kiváltja az MCP-szerver a klasszikus SEO-t?

Nem váltja ki. Az MCP külön csatorna, amely a keresőoptimalizálás mellett fut, és egészen más forgalmat szolgál ki.

Hivatalosan igazolt. A Google Search Central útmutatója szerint a keresés AI-funkcióiban való megjelenéshez ugyanazok az alapok kellenek, mint a hagyományos találatokhoz. Az oldal legyen feltérképezhető, indexelhető, és hasznos tartalmat adjon. Ehhez nincs szükség külön gépi felületre. A strukturált adat (Schema.org, például LocalBusiness és OpeningHoursSpecification) továbbra is a weboldalon él, és a keresők onnan olvassák.

Szakmai feltételezés. A két csatorna akkor erősíti egymást, ha ugyanabból a forrásból táplálkozik. Ha a weboldal strukturált adata, a cégprofil és az MCP-szerver mind ugyanazt mondja, az ügynök bármelyik úton ugyanahhoz a válaszhoz jut. Ha eltérnek, a felhasználó egymásnak ellentmondó információt kap, és ez a bizalmat rontja.

Hogyan mérhető egyáltalán a haszna?

Közvetlenül a szerver naplójából mérhető, hány hívás érkezett, melyik eszközre és melyik kliensből. Az üzleti haszon csak közvetve látszik, a visszaadott linkek követésén és a konverziókon keresztül.

• Hívásszám eszközönként. Melyik adatot kérdezik, és melyiket soha.
• Kliensmegoszlás. Mely alkalmazásokból jönnek a hívások.
• Hibaarány és „ismeretlen” válaszok. Ahol sok az ismeretlen, ott hiányos az adat.
• Követőparaméteres linkek. A visszaadott foglalási vagy termékoldali linkekhez tegyél utm_source=mcp paramétert, így az analitikában külön látszik ez a forgalom.
• Konverzió. Foglalás, ajánlatkérés vagy rendelés ebből a forrásból.
• Ügyfélszolgálati terhelés. Csökkent-e a nyitvatartásra vagy a készletre vonatkozó telefonos kérdések száma.

Saját tapasztalat. A géppel elérhető adatforrások értéke szinte mindig azon múlik, van-e konkrét fogyasztójuk. Egy partner integrációja vagy egy saját ügyfélszolgálati asszisztens mérhető hívásokat hoz, a „hátha valaki használja” alapon indított felület jellemzően csendes marad.

Szakmai feltételezés. Azt, hogy az MCP-szerver javítja-e a céged megjelenését az AI-keresők válaszaiban, jelenleg nem lehet megbízhatóan kimutatni. Az AI-láthatóság mérését ezért külön kezeld, rendszeres promptkészlettel és a válaszok összevetésével, és ne tulajdonítsd a változást automatikusan a szervernek.

Források és további olvasnivalók

• Model Context Protocol, hivatalos specifikáció és dokumentáció
• Anthropic, Model Context Protocol dokumentáció
• OpenAI dokumentáció, MCP-kapcsolatok és összekötők
• Google Search Central, AI-funkciók és a weboldalad
• Schema.org, LocalBusiness és OpeningHoursSpecification
• IETF, OAuth 2.1 tervezet
• OWASP API Security Top 10
• Az Európai Parlament és a Tanács (EU) 2016/679 rendelete (GDPR)