Co logovat u každého volání nástroje MCP

Dne 8. června 2026 dal Anthropic vlastníkům konektorů v katalogu Claude dashboard. Ukazuje aktivní uživatele, celkový počet volání nástrojů a pořadí v katalogu. Ukazuje „skóre stavu, chybovost a latenci na první pohled, s rozpadem chyb podle nástrojů, abyste přesně určili, co selhává“.

O rok dříve popsal Alex Volkov z Weights & Biases tentýž problém z druhé strany. Jakmile jeho agent začal volat nástroje přes MCP, „veškerá ta observabilita, na kterou jsem zvyklý, když můj vlastní kód běží od začátku do konce, trochu potemněla“. Jeho spolupřednášející Benjamin Eckel z Dylibso ukázal proč. Vzdálený MCP server se „nám v trasování zobrazuje jako jediný span služby“, protože běží mimo kontrolu volajícího.

Oba pohledy stojí mimo server. Klient vidí jeden neprůhledný span. Katalog vidí součty. Ani jeden neviděl, oč byl server požádán, co odmítl a čeho se dotkl. To viděl jen server, a tak jen server to může zapsat.

Toto zapisují MCP servery Tajo, vyčteno z kódu, který je provozuje, a popsáno v dokumentaci. Co je MCP server popisuje protokol. Tento text popisuje řádek.

Jeden řádek na volání

Dashboard je pohled kapitanátu přístavu: lodě dovnitř, lodě ven, které měly zpoždění. Log požadavků je vlastní lodní deník, psaný na palubě v tu chvíli.

Každé tools/call na serveru pracovního prostoru Tajo a na každém serveru konektoru končí jedním řádkem. Řádek se zapisuje po sestavení odpovědi, ať byla odpověď jakákoli. Volání odmítnuté proto, že klíč nesmí zapisovat, nebo proto, že endpoint je jen pro čtení, dostane řádek jako každé jiné. Stejně tak volání nástroje, který neexistuje.

Tady je, co řádek obsahuje a co obsahovat odmítá.

Pole	Uchovává se	Neuchovává se
Kdo	Id klíče API, který volal. Token z přihlášení přes OAuth je také klíč.	Tajná hodnota klíče ani jeho prefix.
Kde	Server pracovního prostoru nebo server konektoru, s jeho konektorem a profilem.
Nástroj	Název, pokud server má nástroj s tímto názvem.	Jakýkoli jiný název, který klient pošle: uloží se jako (unknown).
Účinek	read, write, send nebo destructive: nejtěžší účinek, který volání mohlo mít.
Výsledek	ok, nebo krátký kód chyby ve snake_case, například unknown_tool.	Text chyby: cokoli, co není kód, se uloží jako tool_error.
Doba trvání a velikost	Milisekundy od příchodu po odpověď a bajty, které volající obdržel.
Trace id	Id požadavku z hlavičky x-request-id, x-trace-id nebo W3C traceparent, jinak nové.	Hodnota hlavičky, která není hex ani UUID.
Záznamy	Až 20 id záznamů, které volání uvedlo nebo vytvořilo: kontakt, zpráva, schválení.	Samotné záznamy.
Těla	Argumenty a odpověď, vyčištěné, každé nejvýše 4 KB.	Tajné údaje, volný text a osobní údaje uvedené níže.

Tři z těchto odmítnutí se týkají klienta, ne dat. Název nástroje, kód chyby i trace id přicházejí zvenčí. Každé se uchovává jen v podobě, za kterou se server může zaručit. Log, který ukládá cokoli, co volající poslal, lze naplnit čímkoli, i e-mailovou adresou zákazníka ve sloupci s názvem nástroje.

Otevřená otázka Benjamina Eckela na konci přednášky zněla, jak kolektor pozná, „že je to volání nástroje MCP, které má chybu“. Na jednom serveru je odpovědí sloupec. ok je nepravda a kód říká, jaká chyba.

Argumenty: pravidlo, které jsme obrátili

Námitka je oprávněná a je naše vlastní. Když logujete argumenty, stavíte druhou kopii dat svých zákazníků, mimo dosah každé žádosti o výmaz. Do 18. října 2026 to bylo naše vlastní pravidlo. Log neuchovával argumenty ani tělo odpovědi, protože obojí může nést osobní údaje.

Byl to špatný kompromis. Log požadavků, který neumí ukázat, co se odeslalo a co se vrátilo, nedokáže odpovědět na jedinou otázku, kvůli které existuje: proč volání mého agenta selhalo?

Těla se tedy uchovávají a důvod, proč se dřív neuchovávala, se řeší jinak. Každé tělo projde jedním deterministickým průchodem, než se zařadí do fronty.

• Žádný tajný údaj nepřežije. Pole, jehož název říká token, password, secret, signature, cookie, session nebo zhruba dvacet podobných slov, si ponechá jen [secret]. Stejně tak hodnota ve známém tvaru přihlašovacích údajů, ať se objeví kdekoli. To zahrnuje bearer tokeny, JWT, privátní klíče, URL s heslem a jakýkoli neprůhledný řetězec 40 a více znaků klíče.
• Próza se neuchovává vůbec. Pole s názvem html, text, body, markdown nebo content si ponechá jen [redacted]. Próza obsahuje jména a adresy, které žádný vzor nenajde.
• Osobní údaje se maskují natrvalo. Pole, jehož název označuje osobní údaje, například e-mail, telefon, jméno, adresu nebo poznámku, si ponechá jen [redacted]. E-mailová adresa, telefonní číslo, karta nebo IBAN uvnitř jakéhokoli jiného řetězce se maskují.
• Těla zůstávají malá. Řetězce se zkracují na 512 znaků, seznamy na 20 položek, objekty na 50 klíčů a vnoření na 6 úrovní. Celé tělo se zkracuje na 4 KB a označí se jako zkrácené.

Dva druhy volání uchovávají méně. Kontakty, které chat dané osoby přinesl z jiné aplikace, se logují jako značka a počet, nikdy jako tělo. Volání, které čte log, neuchovává žádnou odpověď, protože odpovědí by byly jen jiné řádky logu.

A teď cena. Maskování je trvalé, není to šifrování klíčem, který někdo drží. Log Vám neukáže e-mailovou adresu, která se vrátila jako nedoručitelná. Ukáže Vám id kontaktu a kontakt je, podle svých vlastních pravidel, jedno volání daleko. Log leží mimo výmaz dat pracovního prostoru, a proto maskování nemůže na žádný výmaz čekat.

Proč log není auditní stopa

Tajo už má auditní log, do kterého lze jen připisovat. Každý řádek nese hash předchozího řádku, takže úprava kdekoli řetězec přeruší. Proč tam nezapisovat volání nástrojů?

Protože řetězec má svou cenu. Každé připsání bere zámek pro celý pracovní prostor a čte předchozí řádek, aby řetězec prodloužilo. Zapisovat přes něj každé čtení by postavilo volání pracovního prostoru do fronty za jediný zámek. Také by to zahrabalo změny stavu, které má auditní log ukazovat, pod tisíce čtení.

Oba záznamy se tedy dělí podle otázky. Log požadavků říká, oč agent požádal a co se stalo, po dobu 30 dní. Auditní log říká, co se změnilo, kdo to povolil a zda od té doby někdo záznam upravil.

Schválení patří na stranu auditu. V profilech konektorů Tajo nástroj propose připraví deklarovanou akci a nástroj apply ji po schválení provede. K poskytovateli nic nedojde, dokud návrh neschválí člověk nebo pravidlo, které pracovní prostor zapnul. Řádek volání propose uvádí mezi svými záznamy schválení, které vytvořilo. Samotné schválení je vázané na otisk SHA-256 přesného vstupu. Schválení se vztahuje přesně na vstup, který jste viděli: změňte jedno pole a už nesedí. Když zápis proběhne, jeho auditní řádek uchová otisk vstupu a otisk odpovědi poskytovatele, nikdy hodnoty z odpovědi.

Kolik řádek stojí

Řádek je zápis do databáze a zápis má commit. Do 8. října 2026 každé volání čekalo před odpovědí na vlastní commit, asi 2,6 ms na našem hostiteli. Pro jednoho klienta to byla čtvrtina malého volání nástroje.

Teď se řádek sestaví, když volání skončí, a zařadí se do fronty. Flush zapíše frontu nejvýše o 100 ms později, jednou transakcí na pracovní prostor, takže mnoho volání sdílí jeden commit. Na řádku se nic nemění, ani jeho časové razítko. Pokud čeká 5 000 řádků, další volání počká na flush, místo aby se řádek zahodil.

Zaznamenávání nikdy nezpůsobí selhání volání. Zápis, který selže, se zkouší znovu řádek po řádku, pak se zaloguje a zahodí. Tvrdé ukončení procesu ztratí to, co bylo ve frontě: nejvýše posledních 100 ms volání.

Zpětné čtení

logs.list vrací volání pracovního prostoru, od nejnovějších, bez těl. Filtruje podle času, podle výsledku nebo stavu HTTP, podle zdroje (MCP nebo REST API, které tabulku sdílí) a podle klíče API. Ve výchozím stavu stránkuje po 50, nejvýše po 100. logs.get vrací jedno volání s aktuálním názvem klíče, jeho stavem, dobou trvání, vyčištěným požadavkem a odpovědí a záznamy, kterých se týkalo.

Obě čtou jen pracovní prostor volajícího. Id řádku z jiného pracovního prostoru se nenajde.

Chyba nástroje nese id požadavku. Když toto id vytvořil server, nebo přišlo jako hex nebo UUID, je to trace id řádku. Agent, který dostal chybu, může člověku předat jedinou hodnotu, která volání pojmenuje.

Co je postavené a co ne

Postavené v době psaní:

• Jeden řádek na každé tools/call na serveru pracovního prostoru a každém serveru konektoru, včetně odmítnutých a neznámých volání.
• Id klíče, server, konektor, profil, nástroj, účinek, výsledek, doba trvání, velikost výsledku, trace id a až 20 dotčených záznamů.
• Vyčištěné argumenty a odpovědi, každé nejvýše 4 KB.
• logs.list a logs.get, omezené na pracovní prostor, s uchováním 30 dní.
• Schválení vázaná na otisk vstupu a provedené zápisy zaznamenané s otisky vstupu a výstupu v auditním logu s hashovým řetězcem.

Nepostavené, a stojí za to to vědět, než se na to spolehnete:

• Žádné skóre stavu, žádný graf po nástrojích a žádné upozornění na rostoucí chybovost. Souhrn po nástrojích s počty volání, chyb a nejpomalejšími dobami existuje pro provozní tým Tajo, ne na žádném místě, které můžete otevřít.
• logs.list neumí filtrovat podle názvu nástroje ani podle trace id. Chcete-li najít řádek za id požadavku, zužte výběr podle času a klíče.
• Řádky se neexportují do systému trasování, který provozujete. Trace id se čte jen z hlaviček HTTP, ne z pole MCP _meta, které přednáška použila k přenosu kontextu trasování.
• Po 30 dnech se řádek smaže. Neexistuje archiv ani export.
• Co bylo zamaskováno, nelze z logu obnovit.
• Tvrdé ukončení může ztratit řádky z posledních 100 ms.

Přednáška skončila konstatováním, že observabilita v MCP „není rovnoměrně rozložená“. Dashboard dál po proudu to nespraví a stejně tak ani trasování, které končí u dveří serveru. Synchronizace, která selže, potřebuje vlastní záznam; stejně tak každé volání, které o něj požádalo.

Server volání viděl. Nikdo jiný ne. Zapište to tam.