Saját MCP szerver: minek, mikor és hogyan érdemes megírni

Amióta az MCP (Model Context Protocol) tényleg elterjedt, minden második fejlesztői beszélgetés eljut oda, hogy „na, erre kéne írni egy MCP szervert”. A saját MCP szerver viszont nem ingyen van: kód, ami karbantartást, verziózást és biztonsági figyelmet igényel. Ebben a cikkben azt szedem szét, mikor éri meg tényleg megírni, mikor jobb neki se kezdeni, és ha belevágsz, mi az a minimum, amit nem szabad elrontani.

Mi az MCP dióhéjban – fejlesztői szemmel

Az MCP egy nyílt protokoll, amit az Anthropic tett közzé, és amit azóta több AI-kliens is támogat. A lényeg egy mondatban: szabványosított módon adsz eszközöket és adatot egy LLM-kliens kezébe, JSON-RPC alapon. A szerver oldalon három fő primitív van:

• Tools – függvények, amiket a modell meghívhat. Ez a leggyakrabban használt primitív.
• Resources – olvasható adatforrások (fájl, rekord, dokumentum), amiket a kliens kontextusba tölthet.
• Prompts – előre megírt, paraméterezhető promptsablonok, amiket a felhasználó explicit előhívhat.

Transport szinten két alapeset van: lokálisan stdio-n futó folyamat, illetve HTTP-n elérhető távoli szerver. Ha csak a saját gépeden akarod használni, a stdio a legkevesebb szenvedés. Ha csapatnak adnád, HTTP kell, és onnantól ez már egy rendes szolgáltatás, hitelesítéssel és üzemeltetéssel együtt. A pontos, aktuális részletek a hivatalos MCP specifikációban vannak – a protokoll még mozog, szóval ne emlékezetből dolgozz.

Mikor NE írj saját MCP szervert

Kezdjük ezzel, mert ez a gyakoribb eset. Sok ötlet a „de menő lenne” kategóriából jön, és két hét múlva ott áll egy senki által nem használt repó.

• Ha már van rá hivatalos szerver. A nagy szolgáltatók (GitHub, Slack, Sentry és társaik) jó része kiadta a sajátját. A tiéd legfeljebb ugyanolyan lesz, de karbantartás nélkül.
• Ha egyszeri feladatról van szó. Egy jól megírt shell script vagy CLI-parancs, amit a modell meghív, sokszor pont elég. Nem minden automatizmusnak kell protokoll.
• Ha csak read-only adatot akarsz beadni. Egy jól strukturált markdown fájl a repóban, vagy egy dokumentált API-endpoint gyakran verseny nélkül nyer.
• Ha nem tudod megmondani, ki fogja használni. Ha a válasz „hát, majd valaki”, akkor még nincs meg a use case.

Van egy egyszerű szűrőm: ha nem tudom három mondatban leírni, hogy melyik konkrét, hetente többször előforduló munkafolyamatot rövidíti le, akkor nem írom meg.

Mikor éri meg tényleg

És akkor a másik oldal. Négy helyzet van, amiben szerintem egyértelműen megtérül:

• Belső rendszer, amihez nincs integráció. A saját admin felületed, a céges wiki, a házon belüli ticketrendszer. Itt nem fog helyetted senki szervert írni.
• Ismétlődő, többlépéses munkafolyamat. Amikor ugyanaz a hat lépés fut le minden alkalommal, csak más paraméterekkel. Ilyenkor a szerver nem az API-t csomagolja be, hanem a folyamatot.
• Amikor a modellnek szabályokat is át kell adnod. Egy jó tool-leírás nem csak azt mondja meg, mit lehet, hanem azt is, milyen sorrendben és mit tilos. Ez a tudás máshol elveszik.
• Amikor a kontroll számít. Saját szerverben te döntöd el, mi írható és mi csak olvasható. Egy generikus adatbázis-szerver ennél sokkal veszélyesebb.

A jó MCP szerver nem API-wrapper. Az API-wrappert a modell úgyis megoldja curl-lel. A jó MCP szerver egy munkafolyamatot kódol le, a hozzá tartozó szabályokkal együtt.

Hogyan: a minimum életképes szerver

1. Előbb a tool-design, aztán a kód

Ez a rész számít a legtöbbet, és ezt hagyják ki a legtöbben. A tool neve, leírása és paraméterei gyakorlatilag a prompt, amit a modell lát. Ha a leírás homályos, a modell rosszul fogja hívni – és nem a modell lesz a hibás.

• Kevés tool, tiszta felelősséggel. Öt jól elnevezett jobb, mint húsz átfedő.
• A leírásban legyen benne, mikor ne hívja meg a modell.
• A visszatérési érték legyen strukturált és rövid. Ha 5000 tokent adsz vissza, elégeted a kontextust.
• A hibaüzenet legyen actionable: ne „error 500″, hanem „hiányzik a term_id, kérd le a list_categories toollal”.

2. Technikai váz

Hivatalos SDK van többek között TypeScripthez és Pythonhoz, ezekkel egy működő stdio szerver tényleg pár tucat sor. Nagyjából így néz ki a csontváz:

server.tool(
  "list_categories",
  "Kilistázza a blog kategóriáit cikkszám szerint. " +
  "Mindig ezt hívd meg, mielőtt briefet kérnél.",
  { hide_empty: z.boolean().optional() },
  async ({ hide_empty }) => {
    const cats = await api.getCategories({ hide_empty });
    return { content: [{ type: "text", text: format(cats) }] };
  }
);

Amit érdemes az elejétől jól csinálni: séma-validáció minden inputra, tesztelhető üzleti logika a tool-handleren kívül, és normális logolás – de stderr-re, mert stdio transportnál a stdout maga a protokollcsatorna. Ez a klasszikus első hiba, amitől „érthetetlenül” szétesik a kapcsolat.

3. Biztonság: itt ne spórolj

Az MCP szerver kódfuttatási és adathozzáférési felület. Két dolog, amit nem szabad kihagyni:

• Legkevesebb jogosultság elve. Külön technikai user, csak a szükséges scope-okkal. Ne az admin tokenedet add oda.
• Írási műveletek explicit korlátozása. Nálam ezért készít a blogíró szerverem draftot és nem publikál. Ha félremegy valami, az nem kerül ki élesbe.

És egy külön téma, amit érdemes komolyan venni: minden adat, ami a szerveren keresztül a modellhez kerül, potenciális prompt injection vektor. Egy tool által visszaadott szöveg nem utasítás. Ha idegen tartalmat szolgálsz ki, számolj vele, hogy valaki próbál majd instrukciót csempészni bele. A modellek megbízhatóságáról egyébként érdemes reálisan gondolkodni – erről írtam a Claude Code kódminőségi problémáiról szóló cikkben is.

4. Iterálj a valós használaton

Az első verzió szinte biztosan rossz lesz – nem a kód, hanem a tool-felület. Nézd meg, hogyan hívja a modell, hol téveszt, hol kérdez vissza feleslegesen. A javítás sokszor egyetlen mondat a tool leírásában. Ez inkább UX-munka, mint backend-fejlesztés, és ehhez hozzá kell szokni.

GYIK

Mennyi idő megírni egy egyszerű MCP szervert?

Egy stdio-s, 2-3 toolos szerver egy délután. A használható verzió, jó tool-leírásokkal és hibakezeléssel, inkább néhány nap – iterációval együtt.

Milyen nyelven érdemes?

Amiben amúgy is dolgozol. Hivatalos SDK van TypeScripthez és Pythonhoz, több más nyelvhez pedig szintén elérhető implementáció. A nyelvválasztás itt nem a szűk keresztmetszet.

Csak Claude-dal használható?

Nem. Az MCP nyílt protokoll, és több kliens is támogatja. Ez pont az egyik érv mellette: nem egy konkrét eszközhöz kötöd magad. A Claude Code ökoszisztémájáról egyébként a Channels funkcióról szóló cikkben is írtam.

Elég egy tool is?

Bőven. Ha az az egy tool naponta megspórol tíz percet, már megérte. A méret nem érdem.

Következő lépés

Ne a protokollal kezdd, hanem egy papírral. Írd le azt az egy munkafolyamatot, amit hetente többször csinálsz kézzel, és bontsd fel 2-3 lépésre. Ha ezek a lépések tisztán elnevezhetők és paraméterezhetők, megvan az első három toolod – és onnantól a kód a könnyebbik rész. Ha nem nevezhetők el tisztán, akkor a folyamat a rossz, nem az eszköz hiányzik.