Co logować przy każdym wywołaniu narzędzia MCP

8 czerwca 2026 Anthropic dało właścicielom konektorów w katalogu Claude dashboard. Pokazuje aktywnych użytkowników, łączną liczbę wywołań narzędzi i pozycję w katalogu. Pokazuje „wskaźnik kondycji, odsetek błędów i opóźnienia w jednym widoku, z rozbiciem błędów na narzędzia, żeby wskazać, co zawodzi”.

Rok wcześniej Alex Volkov z Weights & Biases opisał ten sam problem z drugiej strony. Gdy jego agent zaczął wywoływać narzędzia przez MCP, „cała ta obserwowalność, do której jestem przyzwyczajony, gdy mój własny kod działa od początku do końca, trochę przygasła”. Jego współprelegent, Benjamin Eckel z Dylibso, pokazał dlaczego. Zdalny serwer MCP „pojawia się u nas w śladzie jako pojedynczy span usługi”, bo działa poza kontrolą wywołującego.

Oba widoki stoją poza serwerem. Klient widzi jeden nieprzejrzysty span. Katalog widzi sumy. Żaden z nich nie widział, o co poproszono serwer, czego odmówił i czego dotknął. Widział to tylko serwer, więc tylko serwer może to zapisać.

Oto co zapisują serwery MCP Tajo, odczytane z kodu, który je uruchamia, i opisane w dokumentacji. Czym jest serwer MCP omawia protokół. Ten tekst omawia wiersz.

Jeden wiersz na wywołanie

Dashboard to widok kapitanatu portu: statki wpływają, statki wypływają, które się spóźniły. Dziennik żądań to własny dziennik pokładowy statku, pisany na pokładzie na bieżąco.

Każde tools/call na serwerze przestrzeni roboczej Tajo i na każdym serwerze konektora kończy się jednym wierszem. Wiersz jest zapisywany po zbudowaniu odpowiedzi, bez względu na to, jaka była. Wywołanie odrzucone, bo klucz nie ma prawa zapisu albo endpoint jest tylko do odczytu, dostaje wiersz jak każde inne. Tak samo wywołanie narzędzia, które nie istnieje.

Oto co wiersz zawiera i czego odmawia zawierać.

Pole	Przechowywane	Nieprzechowywane
Kto	Identyfikator klucza API, który wywołał. Token z logowania OAuth też jest kluczem.	Sekret klucza ani jego prefiks.
Gdzie	Serwer przestrzeni roboczej albo serwer konektora, wraz z konektorem i profilem.
Narzędzie	Nazwa, gdy serwer ma narzędzie o tej nazwie.	Każda inna nazwa przesłana przez klienta: zapisywana jest jako (unknown).
Efekt	read, write, send albo destructive: najcięższy efekt, jaki mogło mieć wywołanie.
Wynik	ok albo krótki kod błędu w snake_case, np. unknown_tool.	Opis błędu: wszystko, co nie jest kodem, zapisywane jest jako tool_error.
Czas trwania i rozmiar	Milisekundy od przyjęcia do odpowiedzi i bajty, które otrzymał wywołujący.
Identyfikator śledzenia	Identyfikator żądania z nagłówka x-request-id, x-trace-id lub W3C traceparent, a w przeciwnym razie nowy.	Wartość nagłówka, która nie jest szesnastkowa ani nie jest UUID.
Rekordy	Do 20 identyfikatorów rekordów, które wywołanie wskazało lub utworzyło: kontakt, wiadomość, zatwierdzenie.	Same rekordy.
Treści	Argumenty i odpowiedź, oczyszczone, maksymalnie 4 KB każda.	Sekrety, wolny tekst i dane osobowe wymienione poniżej.

Trzy z tych odmów dotyczą klienta, nie danych. Nazwa narzędzia, kod błędu i identyfikator śledzenia przychodzą z zewnątrz. Każde z nich jest przechowywane tylko w postaci, za którą serwer może ręczyć. Dziennik, który zapisuje cokolwiek przysłał wywołujący, da się zapełnić czymkolwiek, nawet adresem e-mail klienta w kolumnie z nazwą narzędzia.

Otwarte pytanie Benjamina Eckela na końcu wystąpienia brzmiało: skąd kolektor ma wiedzieć, „że to wywołanie narzędzia MCP zakończyło się błędem”. Na jednym serwerze odpowiedzią jest kolumna. ok ma wartość fałsz, a kod mówi, jaki to błąd.

Argumenty: reguła, którą odwróciliśmy

Zarzut jest słuszny i jest nasz własny. Logując argumenty, budujesz drugą kopię danych swoich klientów, poza zasięgiem każdego żądania usunięcia. Do 18 października 2026 była to nasza własna reguła. Dziennik nie przechowywał ani argumentów, ani treści odpowiedzi, bo obie mogą zawierać dane osobowe.

To był zły kompromis. Dziennik żądań, który nie pokazuje, co zostało wysłane i co wróciło, nie odpowie na jedyne pytanie, dla którego istnieje: dlaczego wywołanie mojego agenta się nie powiodło?

Dlatego treści są przechowywane, a powód, dla którego wcześniej nie były, rozwiązano inaczej. Każda treść przechodzi jeden deterministyczny przebieg, zanim trafi do kolejki.

• Żaden sekret nie przetrwa. Pole, którego nazwa mówi token, password, secret, signature, cookie, session lub około dwudziestu podobnych słów, zachowuje tylko [secret]. Tak samo wartość o znanym kształcie danych uwierzytelniających, gdziekolwiek się pojawi. Obejmuje to tokeny bearer, JWT, klucze prywatne, adresy URL z hasłem i każdy nieprzejrzysty ciąg 40 lub więcej znaków klucza.
• Proza nie jest przechowywana wcale. Pole o nazwie html, text, body, markdown lub content zachowuje tylko [redacted]. Proza zawiera nazwiska i adresy, których żaden wzorzec nie znajdzie.
• Dane osobowe są maskowane na stałe. Pole, którego nazwa wskazuje dane osobowe, takie jak e-mail, telefon, imię i nazwisko, adres czy notatka, zachowuje tylko [redacted]. Adres e-mail, numer telefonu, karta lub IBAN wewnątrz dowolnego innego ciągu są maskowane.
• Treści pozostają małe. Ciągi są przycinane do 512 znaków, listy do 20 elementów, obiekty do 50 kluczy, a zagnieżdżenie do 6 poziomów. Cała treść jest przycinana do 4 KB i oznaczana jako obcięta.

Dwa rodzaje wywołań zachowują mniej. Kontakty, które czat danej osoby przeniósł z innej aplikacji, są logowane jako znacznik i liczba, nigdy jako treść. Wywołanie, które odczytuje dziennik, nie zachowuje odpowiedzi, bo odpowiedzią byłyby tylko inne wiersze dziennika.

Teraz koszt. Maskowanie jest trwałe, to nie szyfrowanie kluczem, który ktoś posiada. Dziennik nie pokaże Ci adresu e-mail, który się odbił. Pokaże Ci identyfikator kontaktu, a kontakt, na własnych zasadach, jest o jedno wywołanie dalej. Dziennik leży poza procesem usuwania danych przestrzeni roboczej, dlatego maskowanie nie może na niego czekać.

Dlaczego dziennik nie jest ścieżką audytu

Tajo ma już dziennik audytu, do którego można tylko dopisywać. Każdy wiersz zawiera hasz poprzedniego wiersza, więc zmiana w dowolnym miejscu przerywa łańcuch. Dlaczego nie zapisywać tam wywołań narzędzi?

Bo łańcuch ma swoją cenę. Każde dopisanie zakłada blokadę na przestrzeń roboczą i odczytuje poprzedni wiersz, by przedłużyć łańcuch. Zapisywanie przez niego każdego odczytu ustawiłoby wywołania przestrzeni roboczej w kolejce za jedną blokadą. Zakopałoby też zmiany stanu, które dziennik audytu ma pokazywać, pod tysiącami odczytów.

Dlatego te dwa zapisy dzielą się według pytania. Dziennik żądań mówi, o co poprosił agent i co się stało, przez 30 dni. Dziennik audytu mówi, co się zmieniło, kto na to pozwolił i czy ktoś od tego czasu edytował zapis.

Zatwierdzenia są po stronie audytu. W profilach konektorów Tajo narzędzie propose przygotowuje zadeklarowaną akcję, a narzędzie apply wykonuje ją po zatwierdzeniu. Nic nie trafia do dostawcy, dopóki propozycja nie zostanie zatwierdzona przez osobę lub przez regułę włączoną w przestrzeni roboczej. Wiersz wywołania propose wymienia wśród swoich rekordów utworzone przez nie zatwierdzenie. Samo zatwierdzenie jest powiązane ze skrótem SHA-256 dokładnych danych wejściowych. Zatwierdzenie obejmuje dokładnie te dane wejściowe, które zostały Ci pokazane: zmień jedno pole, a przestanie pasować. Gdy zapis trafia do celu, jego wiersz audytu zachowuje skrót danych wejściowych i skrót odpowiedzi dostawcy, nigdy wartości z odpowiedzi.

Ile kosztuje wiersz

Wiersz to zapis w bazie danych, a zapis ma commit. Do 8 października 2026 każde wywołanie czekało na własny commit przed odpowiedzią, około 2,6 ms na naszym hoście. Dla jednego klienta była to jedna czwarta małego wywołania narzędzia.

Teraz wiersz jest budowany po zakończeniu wywołania i trafia do kolejki. Opróżnienie zapisuje kolejkę najpóźniej 100 ms później, jedną transakcją na przestrzeń roboczą, więc wiele wywołań dzieli jeden commit. Nic w wierszu się nie zmienia, łącznie ze znacznikiem czasu. Jeśli czeka 5 000 wierszy, następne wywołanie czeka na opróżnienie, zamiast porzucać wiersz.

Zapis nigdy nie powoduje niepowodzenia wywołania. Zapis, który się nie powiedzie, jest ponawiany wiersz po wierszu, a potem logowany i porzucany. To, co traci twarde zabicie procesu, to zawartość kolejki: najwyżej ostatnie 100 ms wywołań.

Odczytywanie

logs.list zwraca wywołania przestrzeni roboczej, od najnowszych, bez treści. Filtruje po czasie, po wyniku lub statusie HTTP, po źródle (MCP albo REST API, które współdzieli tabelę) i po kluczu API. Domyślnie zwraca 50 na stronę, maksymalnie 100. logs.get zwraca jedno wywołanie z bieżącą nazwą klucza, jego statusem, czasem trwania, oczyszczonym żądaniem i odpowiedzią oraz rekordami, których dotyczyło.

Oba odczytują tylko przestrzeń roboczą wywołującego. Identyfikator wiersza z innej przestrzeni roboczej nie zostanie znaleziony.

Błąd narzędzia zawiera identyfikator żądania. Gdy serwer utworzył ten identyfikator albo przyszedł on jako wartość szesnastkowa lub UUID, jest to identyfikator śledzenia wiersza. Agent, który otrzymał błąd, może przekazać człowiekowi jedną wartość, która wskazuje wywołanie.

Co zbudowano, a czego nie

Zbudowane w chwili pisania:

• Jeden wiersz na każde tools/call na serwerze przestrzeni roboczej i każdym serwerze konektora, łącznie z wywołaniami odrzuconymi i nieznanymi.
• Identyfikator klucza, serwer, konektor, profil, narzędzie, efekt, wynik, czas trwania, rozmiar wyniku, identyfikator śledzenia i do 20 rekordów, których dotyczyło wywołanie.
• Oczyszczone argumenty i odpowiedzi, maksymalnie 4 KB każda.
• logs.list i logs.get, ograniczone do przestrzeni roboczej, z przechowywaniem przez 30 dni.
• Zatwierdzenia powiązane ze skrótem danych wejściowych oraz wykonane zapisy rejestrowane ze skrótami danych wejściowych i wyjściowych w dzienniku audytu opartym na łańcuchu haszy.

Niezbudowane, i warto to wiedzieć, zanim zaczniesz na tym polegać:

• Brak wskaźnika kondycji, wykresu na narzędzie i alertu przy rosnącym odsetku błędów. Podsumowanie na narzędzie z liczbą wywołań, błędów i najwolniejszymi czasami istnieje dla operatorów Tajo, ale nie w żadnym miejscu, które możesz otworzyć.
• logs.list nie filtruje po nazwie narzędzia ani po identyfikatorze śledzenia. Żeby znaleźć wiersz za identyfikatorem żądania, zawęź wyniki po czasie i kluczu.
• Wiersze nie są eksportowane do systemu śledzenia, który sam prowadzisz. Identyfikator śledzenia jest odczytywany tylko z nagłówków HTTP, a nie z pola MCP _meta, którego w wystąpieniu użyto do przenoszenia kontekstu śledzenia.
• Po 30 dniach wiersz jest usuwany. Nie ma archiwum ani eksportu.
• Tego, co zamaskowano, nie da się odzyskać z dziennika.
• Twarde zabicie procesu może stracić wiersze z ostatnich 100 ms.

Wystąpienie zakończyło się stwierdzeniem, że obserwowalność w MCP „nie jest równo rozłożona”. Dashboard dalej w łańcuchu tego nie naprawi, podobnie jak ślad, który zatrzymuje się u drzwi serwera. Synchronizacja, która się nie powiodła, potrzebuje własnego zapisu; tak samo każde wywołanie, które o niego poprosiło.

Serwer widział wywołanie. Nikt inny go nie widział. Zapisz to właśnie tam.