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

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” 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”. 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”, 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. A Mi az MCP-szerver? 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. 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, 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”. 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. 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 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, 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, é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. 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. 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. 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: 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 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 í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, 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.

Visszaolvasás

A logs.list 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.
• Kitisztított argumentumok és válaszok, egyenként legfeljebb 4 KB.
• logs.list és logs.get, 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, 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 használt.
• 30 nap után a sor törlődik. 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.

Az előadás azzal zárult, hogy a megfigyelhetőség az MCP-ben „nem egyenletesen oszlik el”. 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; 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.