---
title: "Mit naplózz minden MCP-eszközhívásnál"
description: "A kliens egy távoli MCP-szervert egyetlen átláthatatlan spanként lát, a címtár irányítópultja pedig összesítéseket lát. A hívást csak a szerver látta. A sor, amelyet a Tajo MCP-szerverei minden hívásról írnak, mezőről mezőre: mit tisztítanak ki belőle, és mi nincs még megépítve."
url: https://tajo.io/hu/blog/what-to-log-for-every-mcp-tool-call/
markdown: https://tajo.io/hu/blog/what-to-log-for-every-mcp-tool-call.md
lang: hu-HU
author: "Set Noa"
author_url: https://tajo.io/hu/set-noa/
published: 2026-11-06
updated: 2026-11-06
alternates: {en-US: /blog/what-to-log-for-every-mcp-tool-call.md, bg-BG: /bg/blog/what-to-log-for-every-mcp-tool-call.md, cs-CZ: /cz/blog/what-to-log-for-every-mcp-tool-call.md, de-DE: /de/blog/what-to-log-for-every-mcp-tool-call.md, da-DK: /dk/blog/what-to-log-for-every-mcp-tool-call.md, es-ES: /es/blog/what-to-log-for-every-mcp-tool-call.md, fr-FR: /fr/blog/what-to-log-for-every-mcp-tool-call.md, el-GR: /gr/blog/what-to-log-for-every-mcp-tool-call.md, hi-IN: /hi/blog/what-to-log-for-every-mcp-tool-call.md, id-ID: /in/blog/what-to-log-for-every-mcp-tool-call.md, hr-HR: /hr/blog/what-to-log-for-every-mcp-tool-call.md, it-IT: /it/blog/what-to-log-for-every-mcp-tool-call.md, ja-JP: /jp/blog/what-to-log-for-every-mcp-tool-call.md, ko-KR: /kr/blog/what-to-log-for-every-mcp-tool-call.md, ar-SA: /ar/blog/what-to-log-for-every-mcp-tool-call.md, nl-NL: /nl/blog/what-to-log-for-every-mcp-tool-call.md, no-NO: /no/blog/what-to-log-for-every-mcp-tool-call.md, pl-PL: /pl/blog/what-to-log-for-every-mcp-tool-call.md, pt-BR: /pt/blog/what-to-log-for-every-mcp-tool-call.md, ro-RO: /ro/blog/what-to-log-for-every-mcp-tool-call.md, ru-RU: /ru/blog/what-to-log-for-every-mcp-tool-call.md, sv-SE: /se/blog/what-to-log-for-every-mcp-tool-call.md, zh-CN: /zh-cn/blog/what-to-log-for-every-mcp-tool-call.md, sl-SI: /sl/blog/what-to-log-for-every-mcp-tool-call.md, sr-Latn-RS: /sr/blog/what-to-log-for-every-mcp-tool-call.md, th-TH: /th/blog/what-to-log-for-every-mcp-tool-call.md, tr-TR: /tr/blog/what-to-log-for-every-mcp-tool-call.md, ur-PK: /ur/blog/what-to-log-for-every-mcp-tool-call.md, vi-VN: /vi/blog/what-to-log-for-every-mcp-tool-call.md, sk-SK: /sk/blog/what-to-log-for-every-mcp-tool-call.md}
---

[AI-ügynökök](https://tajo.io/hu/blog/?category=ai-agents)

# Mit naplózz minden MCP-eszközhívásnál

A kliens egy távoli MCP-szervert egyetlen átláthatatlan spanként lát, a címtár irányítópultja pedig összesítéseket lát. A hívást csak a szerver látta. A sor, amelyet a Tajo MCP-szerverei minden hívásról írnak, mezőről mezőre: mit tisztítanak ki belőle, és mi nincs még megépítve.

MCP szerver naplózás

Mit kell egy MCP-szervernek feljegyeznie minden eszközhívásról?

Hívásonként egy sort naplózz, a szerveren, mert a szerver az egyetlen hely, amely látta a hívást. A Tajo MCP-szerverei rögzítik, ki hívott (a kulcs azonosítóját, soha a titkát), melyik szerver és konnektor, az eszközt, ha létezik, a hatásosztályát, az ok értéket vagy egy rövid hibakódot, az időtartamot, az eredmény méretét, a trace-azonosítót, a hívás által érintett rekordokat, valamint a titkoktól és személyes adatoktól megtisztított argumentumokat és választ. A sorokat a logs.list és a logs.get olvassa, és 30 nap után törlődnek. A hash-láncolt auditnaplótól elkülönítve tárolódnak, amelyben a jóváhagyások és a bemeneteik hash-értékei vannak. Nincs megépítve: állapotpontszám, hibaarány-riasztás, keresés eszköz vagy trace-azonosító szerint, és exportálás a saját nyomkövetésedbe.

[Tudjon meg többet](https://tajo.io/hu/blog/what-to-log-for-every-mcp-tool-call/#h%C3%ADv%C3%A1sonk%C3%A9nt-egy-sor)

2026. június 8-án az Anthropic irányítópultot adott a Claude címtárában szereplő konnektorok tulajdonosainak. Megmutatja az aktív felhasználókat, az összes eszközhívást és a címtárbeli helyezést. Megmutat egy „[állapotpontszámot, hibaarányokat és késleltetést egy pillantással, eszközönkénti hibabontással, hogy pontosan lásd, mi hibázik](https://claude.com/resources/articles/observability-for-developers-building-connectors)” nézetet is.

Egy évvel korábban Alex Volkov, a Weights & Biases munkatársa a másik oldalról írta le ugyanezt a problémát. Amikor az ügynöke MCP-n keresztül kezdett eszközöket hívni, „[az a megfigyelhetőség, amelyhez hozzászoktam, amikor a saját kódom elejétől a végéig fut, kicsit elsötétült](https://www.youtube.com/watch?v=Lcqat4iP_lE&t=61s)”. Előadótársa, Benjamin Eckel a Dylibsótól megmutatta, miért. Egy távoli MCP-szerver „[egyetlen szolgáltatás-spanként jelenik meg számunkra a trace-ben](https://www.youtube.com/watch?v=Lcqat4iP_lE&t=447s)”, mert a hívó irányításán kívül fut.

Mindkét nézőpont a szerveren kívül áll. A kliens egyetlen átláthatatlan spant lát. A címtár összesítéseket lát. Egyik sem látta, mit kérdeztek a szervertől, mit utasított el, és mihez nyúlt. Ezt csak a szerver látta, így csak a szerver tudja leírni.

Ezt írják le a Tajo MCP-szerverei, az őket futtató kódból kiolvasva és [a dokumentációban rögzítve](https://tajo.io/hu/docs/mcp/#mcp-request-log). A [Mi az MCP-szerver?](https://tajo.io/hu/blog/what-is-an-mcp-server/) cikk a protokollról szól. Ez a cikk a sorról.

## Hívásonként egy sor

Az irányítópult a kikötőkapitány nézete: hajók be, hajók ki, melyik késett. A kérésnapló a hajó saját hajónaplója, amelyet a fedélzeten írnak, abban a pillanatban.

Minden `tools/call` a Tajo munkaterület-szerverén és minden konnektorszerveren [egy sorral zárul](https://tajo.io/hu/docs/mcp/#mcp-request-log). A sor azután íródik, hogy a válasz elkészült, bármi legyen is a válasz. Az a hívás, amelyet azért utasítottak el, mert a kulcs nem írhat, vagy mert a végpont csak olvasható, ugyanúgy kap egy sort, mint bármely másik. Ugyanígy egy nem létező eszköz hívása is.

Íme, mit tartalmaz a sor, és mit nem hajlandó tartalmazni.

| Mező | Megőrzi | Nem őrzi meg |
| --- | --- | --- |
| Ki | A hívó API-kulcs azonosítóját. Egy OAuth-bejelentkezésből származó token is kulcs. | A kulcs titkát vagy előtagját. |
| Hol | A munkaterület-szervert vagy egy konnektorszervert, a konnektorral és a profillal. |  |
| Eszköz | A nevet, ha a szervernek van ilyen nevű eszköze. | Minden más nevet, amelyet a kliens küld: ezt `(unknown)` formában tárolja. |
| Hatás | `read`, `write`, `send` vagy `destructive`: a legsúlyosabb hatás, amellyel a hívás járhat. |  |
| Eredmény | `ok`, vagy egy rövid snake\_case hibakód, például `unknown_tool`. | Hibaüzenet szöveges leírását: ami nem kód, az `tool_error` formában tárolódik. |
| Időtartam és méret | Ezredmásodpercek a beérkezéstől a válaszig, és a hívó által kapott bájtok. |  |
| Trace-azonosító | A kérés azonosítója egy `x-request-id`, `x-trace-id` vagy W3C `traceparent` fejlécből, különben egy új. | Olyan fejlécértéket, amely nem hexadecimális és nem UUID. |
| Rekordok | Legfeljebb 20 olyan rekord azonosítóját, amelyet a hívás megnevezett vagy létrehozott: egy kapcsolat, egy üzenet, egy jóváhagyás. | Magukat a rekordokat. |
| Tartalmak | Az argumentumokat és a választ, [kitisztítva](https://tajo.io/hu/docs/mcp/#mcp-request-log), egyenként legfeljebb 4 KB-ot. | Titkokat, szabad szöveget és az alább felsorolt személyes adatokat. |

Ezek közül három elutasítás a kliensről szól, nem az adatokról. Az eszköznév, a hibakód és a trace-azonosító kívülről érkezik. Mindegyiket csak olyan alakban őrzi meg, amelyért a szerver kezeskedni tud. Egy napló, amely bármit eltárol, amit a hívó küldött, bármivel megtölthető, akár egy vásárló e-mail-címével is az eszköznév oszlopában.

Benjamin Eckel nyitott kérdése az előadás végén az volt, honnan tudja egy gyűjtő, „[hogy ez egy MCP-eszközhívás, amelyben hiba van](https://www.youtube.com/watch?v=Lcqat4iP_lE&t=906s)”. Egy szerveren a válasz egy oszlop. Az `ok` értéke false, a kód pedig megmondja, melyik hiba.

## Az argumentumok: egy szabály, amelyet megfordítottunk

Az ellenvetés jogos, és a miénk. Ha naplózod az argumentumokat, létrehoztál egy második másolatot a vásárlóid adatairól, minden törlési kérésen kívül. 2026. október 18-ig ez volt [a saját szabályunk](https://tajo.io/hu/docs/mcp/#mcp-request-log). A napló sem az argumentumokat, sem az eredmény tartalmát nem őrizte meg, mert mindkettő hordozhat személyes adatot.

Rossz alku volt. Az a kérésnapló, amely nem tudja megmutatni, mi ment el és mi jött vissza, nem tud felelni az egyetlen kérdésre, amiért létezik: miért hiúsult meg az ügynököm hívása?

Ezért a tartalmak megmaradnak, azt az okot pedig, amiért korábban nem maradtak meg, más módon kezeljük. Minden tartalom [egyetlen determinisztikus menetet](https://tajo.io/hu/docs/mcp/#mcp-request-log) jár be, mielőtt sorba kerül.

- **Egyetlen titok sem éli túl.** Az a mező, amelynek neve tokenre, jelszóra, titokra, aláírásra, sütire, munkamenetre vagy körülbelül húsz hasonló szóra utal, csak `[secret]` értéket őriz meg. Ugyanígy egy ismert hitelesítőadat-alakú érték is, bárhol jelenik meg. Ez lefedi a bearer tokeneket, a JWT-ket, a privát kulcsokat, a jelszót tartalmazó URL-eket és minden legalább 40 kulcskarakterből álló átláthatatlan sorozatot.
- **A szabad szöveg egyáltalán nem marad meg.** A `html`, `text`, `body`, `markdown` vagy `content` nevű mező csak `[redacted]` értéket őriz meg. A szabad szöveg olyan neveket és utcaneveket tartalmaz, amelyeket semmilyen minta nem talál meg.
- **A személyes adatok végleg maszkolva vannak.** Az a mező, amelynek neve személyes adatot jelöl, például e-mailt, telefont, nevet, címet vagy megjegyzést, csak `[redacted]` értéket őriz meg. Bármely más karakterláncban lévő e-mail-cím, telefonszám, kártya vagy IBAN maszkolva lesz.
- **A tartalmak kicsik maradnak.** [A karakterláncokat 512 karakternél vágja le](https://tajo.io/hu/docs/mcp/#mcp-request-log), a listákat 20 elemnél, az objektumokat 50 kulcsnál, a beágyazást 6 szintnél. A teljes tartalmat [4 KB-nál vágja le](https://tajo.io/hu/docs/mcp/#mcp-request-log), és csonkoltként jelöli.

Kétféle hívás még kevesebbet őriz meg. Azokat a kapcsolatokat, amelyeket valakinek a csevegése egy másik alkalmazásból hozott be, egy jelölő és egy darabszám formájában naplózza, soha tartalomként. Az a hívás, amely a naplót olvassa, nem őriz meg választ, mert a válasz csak más naplósorokból állna.

Most az ár. A maszkolás végleges, nem pedig titkosítás egy kulccsal, amely valakinél van. A napló nem tudja megmutatni, melyik e-mail-címről pattant vissza az üzenet. A kapcsolat azonosítóját mutatja, a kapcsolat pedig, a saját szabályai szerint, egy hívásnyira van. A napló kívül esik a munkaterület időszakos adattörlésén, ezért a maszkolás nem várhat rá.

## Miért nem az auditnapló a napló

A Tajónak már van [csak hozzáfűzhető auditnaplója](https://tajo.io/hu/docs/mcp/#mcp-request-log). Minden sor az előző sor hash-értékét hordozza, így bárhol történő módosítás megszakítja a láncot. Miért ne oda írnánk az eszközhívásokat?

Mert a láncnak ára van. Minden hozzáfűzés munkaterületenkénti zárolást vesz fel, és kiolvassa az előző sort a lánc meghosszabbításához. Ha minden olvasást ezen keresztül írnánk, a munkaterület hívásai egyetlen zárolás mögött állnának sorba. Ráadásul azokat az állapotváltozásokat, amelyek megmutatására az auditnapló létezik, olvasások ezrei temetnék maguk alá.

Ezért a két nyilvántartás kérdés szerint oszlik meg. A kérésnapló megmondja, mit kért egy ügynök és mi történt, [30 napig](https://tajo.io/hu/docs/mcp/#mcp-request-log). Az auditnapló megmondja, mi változott, ki engedélyezte, és módosította-e azóta bárki a nyilvántartást.

A jóváhagyások az audit oldalán vannak. A Tajo konnektorprofiljain [egy javaslateszköz előkészít egy deklarált műveletet, egy alkalmazóeszköz pedig lefuttatja, amint jóváhagyták](https://tajo.io/hu/docs/mcp/). Semmi sem jut el a szolgáltatóhoz, amíg a javaslatot jóvá nem hagyják, akár egy személy, akár egy szabály, amelyet a munkaterület bekapcsolt. A javaslathívás sora a rekordjai között megnevezi az általa létrehozott jóváhagyást. Maga a jóváhagyás a pontos bemenet SHA-256 hash-értékéhez kötődik. [Egy jóváhagyás pontosan azt a bemenetet fedi le, amelyet láttál](https://tajo.io/hu/docs/mcp/agent-specification/): ha egy mezőt megváltoztatsz, már nem egyezik. Amikor az írás megtörténik, az auditsora megőrzi a bemenet hash-értékét és a szolgáltató válaszának hash-értékét, soha nem a válasz értékeit.

## Mennyibe kerül a sor

Egy sor egy adatbázisírás, egy írásnak pedig van commitja. [2026. október 8-ig](https://tajo.io/hu/docs/mcp/#mcp-request-log) minden hívás a saját commitjára várt a válasz előtt, ez a mi hosztunkon körülbelül 2,6 ms volt. Egy kliens számára ez egy kis eszközhívás negyede volt.

Most a sor a hívás végén készül el, és sorba kerül. Egy ürítés [legfeljebb 100 ms-mal később](https://tajo.io/hu/docs/mcp/#mcp-request-log) írja ki a várakozó sorokat, munkaterületenként egy tranzakcióban, így sok hívás osztozik egy commiton. A sorban semmi sem változik, az időbélyege sem. Ha [5000 sor várakozik](https://tajo.io/hu/docs/mcp/#mcp-request-log), a következő hívás megvárja az ürítést, ahelyett hogy egy sor elveszne.

A rögzítés soha nem buktat el hívást. A sikertelen írást soronként újrapróbálja, aztán naplózza és eldobja. Amit a folyamat kemény leállítása elveszít, az a sorban várakozó tartalom: [legfeljebb az utolsó 100 ms hívásai](https://tajo.io/hu/docs/mcp/#mcp-request-log).

## Visszaolvasás

A [`logs.list`](https://tajo.io/hu/docs/mcp/#mcp-request-log) a munkaterület hívásait adja vissza, a legújabbal kezdve, tartalmak nélkül. Szűr időre, eredményre vagy HTTP-állapotra, forrásra (MCP vagy a REST API, amely ugyanazt a táblát használja) és API-kulcsra. Alapértelmezés szerint 50-esével lapoz, legfeljebb 100-asával. A `logs.get` egyetlen hívást ad vissza a kulcs jelenlegi nevével, az állapotával, az időtartamával, a kitisztított kéréssel és válasszal, valamint az érintett rekordokkal.

Mindkettő csak a hívó munkaterületét olvassa. Egy másik munkaterület sorazonosítója nem található.

Egy eszközhiba magában hordozza a kérés azonosítóját. Ha ezt az azonosítót a szerver hozta létre, vagy hexadecimális értékként vagy UUID-ként érkezett, akkor ez a sor trace-azonosítója. Egy ügynök, amely hibát kapott, átadhatja egy embernek azt az egyetlen értéket, amely megnevezi a hívást.

## Mi van megépítve, és mi nincs

Megépítve, e sorok írásakor:

- Egy sor minden `tools/call` után a munkaterület-szerveren és minden konnektorszerveren, az elutasított és az ismeretlen hívásokat is beleértve.
- [Kulcsazonosító, szerver, konnektor, profil, eszköz, hatás, eredmény, időtartam, eredményméret, trace-azonosító és legfeljebb 20 érintett rekord](https://tajo.io/hu/docs/mcp/#mcp-request-log).
- [Kitisztított argumentumok és válaszok](https://tajo.io/hu/docs/mcp/#mcp-request-log), egyenként legfeljebb 4 KB.
- [`logs.list` és `logs.get`](https://tajo.io/hu/docs/mcp/#mcp-request-log), a munkaterületre korlátozva, 30 napos megőrzéssel.
- Bemeneti hash-értékhez kötött jóváhagyások, és a végrehajtott írások bemeneti és kimeneti hash-értékekkel rögzítve a hash-láncolt auditnaplóban.

Nincs megépítve, és érdemes tudni, mielőtt támaszkodsz rá:

- Nincs állapotpontszám, nincs eszközönkénti diagram, és nincs riasztás emelkedő hibaarányra. Eszközönkénti összesítés a hívásokról, hibákról és a leglassabb időtartamokról [a Tajo üzemeltetői számára létezik](https://tajo.io/hu/docs/mcp/#mcp-request-log), de egyetlen olyan felületen sem, amelyet te megnyithatsz.
- A `logs.list` nem tud eszköznévre vagy trace-azonosítóra szűrni. Ha egy kérésazonosító mögötti sort keresed, szűkíts időre és kulcsra.
- A sorok nem exportálódnak egy általad üzemeltetett nyomkövető rendszerbe. A trace-azonosítót csak HTTP-fejlécekből olvassa, nem abból az MCP `_meta` mezőből, amelyet az előadás a [trace-kontextus továbbítására](https://www.youtube.com/watch?v=Lcqat4iP_lE&t=535s) használt.
- [30 nap után a sor törlődik](https://tajo.io/hu/docs/mcp/#mcp-request-log). Nincs archívum vagy exportálás.
- Ami maszkolva lett, az a naplóból nem állítható helyre.
- [Egy kemény leállítás elveszítheti az utolsó 100 ms sorait](https://tajo.io/hu/docs/mcp/#mcp-request-log).

Az előadás azzal zárult, hogy a megfigyelhetőség az MCP-ben „[nem egyenletesen oszlik el](https://www.youtube.com/watch?v=Lcqat4iP_lE&t=841s)”. Ezt egy lánc végén lévő irányítópult nem tudja helyrehozni, és az a trace sem, amely a szerver ajtajában megáll. [Egy meghiúsult szinkronizálásnak saját nyilvántartás kell](https://tajo.io/hu/blog/worker-died-sync-didnt/); ugyanígy minden hívásnak, amely ilyet kért.

A szerver látta a hívást. Senki más nem. Ott írd le.

## Gyakran Ismételt Kérdések

**Mit naplózzon egy MCP-szerver minden eszközhívásról?**

Hívásonként egy sort, amelyet a szerver ír: melyik API-kulcs hívott, melyik szerver és konnektor, az eszköz neve, ha az eszköz létezik, a hatásosztálya, ok vagy egy rövid hibakód, az időtartam, az eredmény mérete, a kérés trace-azonosítója, azoknak a rekordoknak az azonosítói, amelyeket a hívás megnevezett vagy létrehozott, valamint az argumentumok és a válasz, a titkokat és a személyes adatokat kitisztítva. A Tajo MCP-szerverei minden tools/call után megírják ezt a sort, az elutasított hívásokat is beleértve, és 30 napig megőrzik.

**Megőrizze egy MCP-kérésnapló az eszközök argumentumait?**

Igen, kitisztítva. Argumentumok nélkül egy napló nem tudja megmondani, miért hiúsult meg egy hívás. A Tajo 2026. október 18-ig nem őrzött meg tartalmat, most viszont mindkettőt megőrzi, egyetlen determinisztikus menet után: a titkokból \[secret\] lesz, a szabad szövegből és a személyes mezőkből \[redacted\], az e-mail-címeket, telefonszámokat, kártyákat és IBAN-okat maszkolja, és minden tartalmat 4 KB-nál levág. A maszkolás végleges, ezért a napló azonosítóval mutat a rekordra, ahelyett hogy lemásolná.

**Miért különül el az MCP-eszközhívások naplója az auditnaplótól?**

Mert más kérdésekre felelnek, más áron. A Tajo auditnaplója az állapotváltozások hash-lánca, és minden hozzáfűzés munkaterületenkénti zárolást vesz fel a lánc meghosszabbításához. Ha minden olvasást ezen keresztül írnánk, a munkaterület hívásai sorba állnának a zárolás mögött, a változások pedig elvesznének az olvasások között. Az eszközhívások egy külön, lánc nélküli táblába kerülnek, amelyet 30 napig őrzünk meg; a hívás által előkészített írások továbbra is saját auditsorokat hagynak.

## Kapcsolódó cikkek

### [Mi az az MCP-szerver? Így működik az MCP és az MCP UI 2026-ban](https://tajo.io/hu/blog/what-is-an-mcp-server/)

2026\. okt. 3. · 14 perc olvasás

1\. lépés → 6. lépés

### [Grok Bot és Brevo: zárd le a termékvisszajelzés körét](https://tajo.io/hu/blog/grok-bot-brevo-product-feedback/)

2026\. okt. 7. · 4 perc olvasás

3 szakasz

### [Az MCP vagy CLI rossz kérdés. Azt kérdezd, hol él az állapot.](https://tajo.io/hu/blog/mcp-or-cli-is-the-wrong-question/)

2026\. nov. 4. · 7 perc olvasás

5 szakasz