---
title: "Was du bei jedem MCP-Tool-Aufruf protokollieren solltest"
description: "Ein Client sieht einen entfernten MCP-Server als einen einzigen undurchsichtigen Span, ein Verzeichnis-Dashboard sieht Summen. Nur der Server hat den Aufruf gesehen. Die Zeile, die Tajos MCP-Server für jeden Aufruf schreiben, Feld für Feld, was daraus entfernt wird und was nicht gebaut ist."
url: https://tajo.io/de/blog/what-to-log-for-every-mcp-tool-call/
markdown: https://tajo.io/de/blog/what-to-log-for-every-mcp-tool-call.md
lang: de-DE
author: "Set Noa"
author_url: https://tajo.io/de/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, 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, hu-HU: /hu/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}
---

[KI-Agenten](https://tajo.io/de/blog/?category=ai-agents)

# Was du bei jedem MCP-Tool-Aufruf protokollieren solltest

Ein Client sieht einen entfernten MCP-Server als einen einzigen undurchsichtigen Span, ein Verzeichnis-Dashboard sieht Summen. Nur der Server hat den Aufruf gesehen. Die Zeile, die Tajos MCP-Server für jeden Aufruf schreiben, Feld für Feld, was daraus entfernt wird und was nicht gebaut ist.

MCP Server Logging

Was sollte ein MCP-Server bei jedem Tool-Aufruf festhalten?

Protokolliere eine Zeile pro Tool-Aufruf, auf dem Server, denn nur der Server hat ihn gesehen. Tajos MCP-Server halten fest, wer aufgerufen hat (die ID des Schlüssels, nie sein Geheimnis), welcher Server und Connector, das Tool, falls es existiert, seine Wirkungsklasse, ok oder einen kurzen Fehlercode, Dauer, Ergebnisgröße, Trace-ID, die Datensätze, die der Aufruf berührt hat, sowie Argumente und Antwort, bereinigt um Geheimnisse und personenbezogene Daten. Zeilen werden mit logs.list und logs.get gelesen und nach 30 Tagen gelöscht. Sie liegen getrennt vom Audit-Log mit Hash-Kette, in dem Freigaben und ihre Input-Digests aufbewahrt werden. Nicht gebaut: ein Health Score, ein Alarm bei der Fehlerrate, die Suche nach Tool oder Trace-ID und der Export in dein eigenes Tracing.

[Mehr erfahren](https://tajo.io/de/blog/what-to-log-for-every-mcp-tool-call/#eine-zeile-pro-aufruf)

Am 8. Juni 2026 gab Anthropic den Betreiber:innen von Connectors im Verzeichnis von Claude ein Dashboard. Es zeigt aktive Nutzer:innen, die Gesamtzahl der Tool-Aufrufe und den Rang im Verzeichnis. Es zeigt „[Health Score, Fehlerraten und Latenz auf einen Blick, mit einer Fehleraufschlüsselung pro Tool, um genau zu finden, was fehlschlägt](https://claude.com/resources/articles/observability-for-developers-building-connectors)“.

Ein Jahr zuvor hatte Alex Volkov von Weights & Biases dasselbe Problem vom anderen Ende aus beschrieben. Sobald sein Agent Tools über MCP aufrief, sei „[all die Observability, die ich gewohnt bin, wenn mein eigener Code einfach von Anfang bis Ende läuft, ein bisschen dunkel geworden](https://www.youtube.com/watch?v=Lcqat4iP_lE&t=61s)“. Sein Mitvortragender Benjamin Eckel von Dylibso zeigte, warum. Ein entfernter MCP-Server „[erscheint für uns im Trace als ein einziger Service-Span](https://www.youtube.com/watch?v=Lcqat4iP_lE&t=447s)“, weil er außerhalb der Kontrolle des Aufrufers läuft.

Beide Sichten stehen außerhalb des Servers. Der Client sieht einen undurchsichtigen Span. Das Verzeichnis sieht Summen. Keine von beiden hat gesehen, worum der Server gebeten wurde, was er abgelehnt und was er berührt hat. Nur der Server hat es gesehen, also kann nur der Server es aufschreiben.

Das hier schreiben Tajos MCP-Server auf, gelesen aus dem Code, der sie betreibt, und [in der Dokumentation beschrieben](https://tajo.io/de/docs/mcp/#mcp-request-log). [Was ein MCP-Server ist](https://tajo.io/de/blog/what-is-an-mcp-server/) erklärt das Protokoll. Hier geht es um die Zeile.

## Eine Zeile pro Aufruf

Ein Dashboard ist die Sicht des Hafenmeisters: Schiffe rein, Schiffe raus, welche zu spät kamen. Das Request-Log ist das Logbuch des Schiffs selbst, an Bord geschrieben, im selben Moment.

Jeder `tools/call` auf Tajos Workspace-Server und auf jedem Connector-Server [endet in einer Zeile](https://tajo.io/de/docs/mcp/#mcp-request-log). Die Zeile wird geschrieben, nachdem die Antwort erstellt ist, egal wie die Antwort lautete. Ein Aufruf, der abgelehnt wird, weil der Schlüssel nicht schreiben darf oder weil der Endpunkt nur lesbar ist, bekommt eine Zeile wie jeder andere. Ebenso ein Aufruf an ein Tool, das es nicht gibt.

Das steht in der Zeile, und das lehnt sie ab.

| Feld | Gespeichert | Nicht gespeichert |
| --- | --- | --- |
| Wer | Die ID des API-Schlüssels, der aufgerufen hat. Ein Token aus einer OAuth-Anmeldung ist ebenfalls ein Schlüssel. | Das Geheimnis des Schlüssels oder sein Präfix. |
| Wo | Der Workspace-Server oder ein Connector-Server, mit Connector und Profil. |  |
| Tool | Der Name, wenn der Server ein Tool mit diesem Namen hat. | Jeder andere Name, den der Client sendet: Er wird als `(unknown)` gespeichert. |
| Wirkung | `read`, `write`, `send` oder `destructive`: die schwerste Wirkung, die der Aufruf haben könnte. |  |
| Ergebnis | `ok` oder ein kurzer Fehlercode in snake\_case wie `unknown_tool`. | Fehlertext: Alles, was kein Code ist, wird als `tool_error` gespeichert. |
| Dauer und Größe | Millisekunden vom Eingang bis zur Antwort und die Bytes, die der Aufrufer erhalten hat. |  |
| Trace-ID | Die ID der Anfrage, aus einem `x-request-id`-, `x-trace-id`- oder W3C-`traceparent`-Header, sonst eine neue. | Ein Header-Wert, der weder Hex noch eine UUID ist. |
| Datensätze | Bis zu 20 IDs von Datensätzen, die der Aufruf genannt oder erzeugt hat: ein Kontakt, eine Nachricht, eine Freigabe. | Die Datensätze selbst. |
| Bodies | Die Argumente und die Antwort, [bereinigt](https://tajo.io/de/docs/mcp/#mcp-request-log), jeweils höchstens 4 KB. | Geheimnisse, Freitext und die unten aufgeführten personenbezogenen Daten. |

Drei dieser Ablehnungen betreffen den Client, nicht die Daten. Tool-Name, Fehlercode und Trace-ID kommen alle von außen. Jeder davon wird nur in einer Form gespeichert, für die der Server einstehen kann. Ein Log, das speichert, was auch immer der Aufrufer geschickt hat, lässt sich mit allem füllen, auch mit der E-Mail-Adresse einer Kundin oder eines Kunden in der Spalte für den Tool-Namen.

Benjamin Eckels offene Frage am Ende des Vortrags war, woher ein Collector weiß, „[dass es ein MCP-Tool-Aufruf ist, der einen Fehler hat](https://www.youtube.com/watch?v=Lcqat4iP_lE&t=906s)“. Auf einem einzelnen Server ist die Antwort eine Spalte. `ok` ist false, und der Code sagt, welcher Fehler.

## Die Argumente: eine Regel, die wir umgekehrt haben

Der Einwand ist berechtigt, und er ist unser eigener. Protokolliere die Argumente, und du hast eine zweite Kopie der Daten deiner Kund:innen gebaut, außerhalb jeder Löschanfrage. Bis zum 18. Oktober 2026 war das [unsere eigene Regel](https://tajo.io/de/docs/mcp/#mcp-request-log). Das Log behielt weder die Argumente noch den Ergebnis-Body, weil beide personenbezogene Daten enthalten können.

Es war der falsche Tausch. Ein Request-Log, das nicht zeigen kann, was gesendet wurde und was zurückkam, kann die eine Frage nicht beantworten, für die es existiert: Warum ist der Aufruf meines Agenten fehlgeschlagen?

Also werden die Bodies aufbewahrt, und dem Grund, aus dem sie es nicht wurden, wird auf andere Weise Rechnung getragen. Jeder Body durchläuft [einen deterministischen Durchgang](https://tajo.io/de/docs/mcp/#mcp-request-log), bevor er in die Warteschlange kommt.

- **Kein Geheimnis überlebt.** Ein Feld, dessen Name Token, Passwort, Secret, Signatur, Cookie, Session oder etwa zwanzig ähnliche Wörter enthält, behält nur `[secret]`. Ebenso ein Wert in einer bekannten Form von Zugangsdaten, wo immer er auftaucht. Das umfasst Bearer-Tokens, JWTs, private Schlüssel, URLs mit Passwort und jede undurchsichtige Folge von 40 oder mehr Schlüsselzeichen.
- **Fließtext wird gar nicht aufbewahrt.** Ein Feld namens `html`, `text`, `body`, `markdown` oder `content` behält nur `[redacted]`. Fließtext enthält Namen und Postanschriften, die kein Muster findet.
- **Personenbezogene Daten werden endgültig maskiert.** Ein Feld, dessen Name personenbezogene Daten kennzeichnet, etwa eine E-Mail, eine Telefonnummer, einen Namen, eine Adresse oder eine Notiz, behält nur `[redacted]`. Eine E-Mail-Adresse, eine Telefonnummer, eine Karte oder eine IBAN in jedem anderen String wird maskiert.
- **Bodies bleiben klein.** [Strings werden bei 512 Zeichen abgeschnitten](https://tajo.io/de/docs/mcp/#mcp-request-log), Listen bei 20 Einträgen, Objekte bei 50 Schlüsseln und Verschachtelung bei 6 Ebenen. Der ganze Body wird [bei 4 KB abgeschnitten](https://tajo.io/de/docs/mcp/#mcp-request-log) und als gekürzt markiert.

Zwei Arten von Aufrufen behalten weniger. Kontakte, die der Chat einer Person aus einer anderen App mitgebracht hat, werden als Markierung und Anzahl protokolliert, nie als Body. Ein Aufruf, der das Log liest, behält keine Antwort, denn die Antwort wären nur andere Log-Zeilen.

Jetzt die Kosten. Die Maskierung ist dauerhaft, keine Verschlüsselung mit einem Schlüssel, den jemand besitzt. Das Log kann dir die E-Mail-Adresse, die einen Bounce ausgelöst hat, nicht zeigen. Es zeigt dir die ID des Kontakts, und der Kontakt ist, nach seinen eigenen Regeln, einen Aufruf entfernt. Das Log liegt außerhalb des Löschdurchlaufs des Workspace, und deshalb kann die Maskierung nicht auf einen solchen warten.

## Warum das Log nicht der Audit-Trail ist

Tajo hat bereits [ein Append-only-Audit-Log](https://tajo.io/de/docs/mcp/#mcp-request-log). Jede Zeile trägt einen Hash der vorherigen Zeile, sodass eine Änderung an beliebiger Stelle die Kette bricht. Warum also nicht die Tool-Aufrufe dort schreiben?

Weil die Kette ihren Preis hat. Jedes Anhängen nimmt eine Sperre pro Workspace und liest die vorherige Zeile, um die Kette zu verlängern. Würde jeder Lesezugriff dort geschrieben, stünden die Aufrufe eines Workspace hinter einer einzigen Sperre Schlange. Außerdem gingen die Zustandsänderungen, die das Audit-Log zeigen soll, unter Tausenden Lesezugriffen unter.

Also teilen sich die beiden Aufzeichnungen nach Fragen auf. Das Request-Log sagt, was ein Agent gefragt hat und was passiert ist, [für 30 Tage](https://tajo.io/de/docs/mcp/#mcp-request-log). Das Audit-Log sagt, was sich geändert hat, wer es erlaubt hat und ob seitdem jemand den Eintrag bearbeitet hat.

Freigaben liegen auf der Audit-Seite. In Tajos Connector-Profilen [bereitet ein Propose-Tool eine deklarierte Aktion vor, und ein Apply-Tool führt sie aus, sobald sie freigegeben ist](https://tajo.io/de/docs/mcp/). Nichts erreicht den Provider, bevor der Vorschlag freigegeben ist, durch eine Person oder durch eine Regel, die der Workspace eingeschaltet hat. Die Zeile des Propose-Aufrufs nennt unter ihren Datensätzen die Freigabe, die er erstellt hat. Die Freigabe selbst ist an einen SHA-256-Digest des exakten Inputs gebunden. [Eine Freigabe gilt für genau den Input, den du gesehen hast](https://tajo.io/de/docs/mcp/agent-specification/): Ändere ein Feld, und sie passt nicht mehr. Wenn der Schreibvorgang ankommt, behält seine Audit-Zeile den Input-Digest und einen Digest der Antwort des Providers, nie deren Werte.

## Was die Zeile kostet

Eine Zeile ist ein Schreibvorgang in der Datenbank, und ein Schreibvorgang hat einen Commit. [Bis zum 8. Oktober 2026](https://tajo.io/de/docs/mcp/#mcp-request-log) wartete jeder Aufruf vor der Antwort auf seinen eigenen Commit, etwa 2,6 ms auf unserem Host. Für einen Client war das ein Viertel eines kleinen Tool-Aufrufs.

Jetzt wird die Zeile erstellt, wenn der Aufruf endet, und in eine Warteschlange gestellt. Ein Flush schreibt die Warteschlange [höchstens 100 ms später](https://tajo.io/de/docs/mcp/#mcp-request-log), eine Transaktion pro Workspace, sodass sich viele Aufrufe einen Commit teilen. An einer Zeile ändert sich nichts, auch nicht ihr Zeitstempel. Wenn [5.000 Zeilen warten](https://tajo.io/de/docs/mcp/#mcp-request-log), wartet der nächste Aufruf auf den Flush, statt eine Zeile zu verwerfen.

Das Aufzeichnen lässt nie einen Aufruf fehlschlagen. Ein fehlgeschlagener Schreibvorgang wird Zeile für Zeile wiederholt, dann protokolliert und verworfen. Was ein hartes Beenden des Prozesses verliert, ist das, was in der Warteschlange lag: [höchstens die Aufrufe der letzten 100 ms](https://tajo.io/de/docs/mcp/#mcp-request-log).

## Zurücklesen

[`logs.list`](https://tajo.io/de/docs/mcp/#mcp-request-log) gibt die Aufrufe des Workspace zurück, die neuesten zuerst, ohne Bodies. Es filtert nach Zeit, nach Ergebnis oder HTTP-Status, nach Quelle (MCP oder die REST-API, die dieselbe Tabelle nutzt) und nach API-Schlüssel. Es liefert standardmäßig 50 pro Seite, bis zu 100. `logs.get` gibt einen Aufruf zurück, mit dem aktuellen Namen des Schlüssels, seinem Status, seiner Dauer, der bereinigten Anfrage und Antwort und den Datensätzen, die er berührt hat.

Beide lesen nur den Workspace des Aufrufers. Eine Zeilen-ID aus einem anderen Workspace wird nicht gefunden.

Ein Tool-Fehler trägt die Request-ID. Wenn der Server diese ID erzeugt hat oder sie als Hex oder UUID ankam, ist sie die Trace-ID der Zeile. Ein Agent, der einen Fehler bekommen hat, kann einer Person den einen Wert geben, der den Aufruf benennt.

## Was gebaut ist und was nicht

Gebaut, Stand heute:

- Eine Zeile pro `tools/call` auf dem Workspace-Server und auf jedem Connector-Server, abgelehnte und unbekannte Aufrufe eingeschlossen.
- [Schlüssel-ID, Server, Connector, Profil, Tool, Wirkung, Ergebnis, Dauer, Ergebnisgröße, Trace-ID und bis zu 20 berührte Datensätze](https://tajo.io/de/docs/mcp/#mcp-request-log).
- [Bereinigte Argumente und Antworten](https://tajo.io/de/docs/mcp/#mcp-request-log), jeweils höchstens 4 KB.
- [`logs.list` und `logs.get`](https://tajo.io/de/docs/mcp/#mcp-request-log), auf den Workspace beschränkt, mit 30 Tagen Aufbewahrung.
- Freigaben, die an einen Input-Digest gebunden sind, und ausgeführte Schreibvorgänge, die mit Input- und Output-Digests im Audit-Log mit Hash-Kette festgehalten werden.

Nicht gebaut, und gut zu wissen, bevor du dich darauf verlässt:

- Kein Health Score, kein Diagramm pro Tool und kein Alarm bei steigender Fehlerrate. Eine Zusammenfassung pro Tool mit Aufrufen, Fehlern und den langsamsten Dauern [gibt es für Tajos Betriebsteam](https://tajo.io/de/docs/mcp/#mcp-request-log), auf keiner Oberfläche, die du öffnen kannst.
- `logs.list` kann nicht nach Tool-Name oder Trace-ID filtern. Um die Zeile zu einer Request-ID zu finden, grenze nach Zeit und Schlüssel ein.
- Zeilen werden nicht in ein Tracing-System exportiert, das du betreibst. Die Trace-ID wird nur aus HTTP-Headern gelesen, nicht aus dem MCP-Feld `_meta`, über das im Vortrag [Trace-Kontext transportiert wurde](https://www.youtube.com/watch?v=Lcqat4iP_lE&t=535s).
- [Nach 30 Tagen wird eine Zeile gelöscht](https://tajo.io/de/docs/mcp/#mcp-request-log). Es gibt kein Archiv und keinen Export.
- Was maskiert wurde, lässt sich aus dem Log nicht wiederherstellen.
- [Ein hartes Beenden kann die Zeilen der letzten 100 ms verlieren](https://tajo.io/de/docs/mcp/#mcp-request-log).

Der Vortrag endete mit dem Befund, Observability sei bei MCP „[nicht gleichmäßig verteilt](https://www.youtube.com/watch?v=Lcqat4iP_lE&t=841s)“. Ein nachgelagertes Dashboard kann das nicht beheben, und ein Trace, der an der Tür des Servers endet, auch nicht. [Ein Sync, der fehlschlägt, braucht seine eigene Aufzeichnung](https://tajo.io/de/blog/worker-died-sync-didnt/); ebenso jeder Aufruf, der einen angefordert hat.

Der Server hat den Aufruf gesehen. Sonst niemand. Schreib es dort auf.

## Häufig gestellte Fragen

**Was sollte ein MCP-Server bei jedem Tool-Aufruf protokollieren?**

Eine Zeile pro Aufruf, geschrieben vom Server: welcher API-Schlüssel aufgerufen hat, welcher Server und Connector, der Tool-Name, falls das Tool existiert, seine Wirkungsklasse, ok oder ein kurzer Fehlercode, die Dauer, die Größe des Ergebnisses, die Trace-ID der Anfrage, die IDs der Datensätze, die der Aufruf genannt oder erzeugt hat, sowie Argumente und Antwort, bereinigt um Geheimnisse und personenbezogene Daten. Tajos MCP-Server schreiben diese Zeile für jeden tools/call, abgelehnte Aufrufe eingeschlossen, und bewahren sie 30 Tage auf.

**Sollte ein MCP-Request-Log die Tool-Argumente behalten?**

Ja, bereinigt. Ein Log ohne die Argumente kann nicht sagen, warum ein Aufruf fehlgeschlagen ist. Tajo hat bis zum 18. Oktober 2026 keine Bodies aufbewahrt und behält jetzt beide, nach einem deterministischen Durchgang: Geheimnisse werden zu \[secret\], Freitext und personenbezogene Felder zu \[redacted\], E-Mail-Adressen, Telefonnummern, Karten und IBANs werden maskiert, und jeder Body wird bei 4 KB abgeschnitten. Die Maskierung ist dauerhaft, deshalb verweist das Log per ID auf den Datensatz, statt ihn zu kopieren.

**Warum wird das Log der MCP-Tool-Aufrufe getrennt vom Audit-Log geführt?**

Weil beide unterschiedliche Fragen zu unterschiedlichen Kosten beantworten. Tajos Audit-Log ist eine Hash-Kette von Zustandsänderungen, und jedes Anhängen nimmt eine Sperre pro Workspace, um die Kette zu verlängern. Würde jeder Lesezugriff dort geschrieben, stünden die Aufrufe eines Workspace hinter dieser Sperre Schlange, und die Änderungen gingen unter den Lesezugriffen unter. Tool-Aufrufe landen in einer separaten Tabelle ohne Kette, die 30 Tage aufbewahrt wird; die Schreibvorgänge, die ein Aufruf vorbereitet, hinterlassen weiterhin ihre eigenen Audit-Zeilen.

## Verwandte Artikel

### [Was ist ein MCP-Server? So funktionieren MCP und MCP UI 2026](https://tajo.io/de/blog/what-is-an-mcp-server/)

3\. Okt. 2026 · 14 Min. Lesezeit

Schritt 1 → Schritt 6

### [Grok Bot und Brevo: Produktfeedback bis zur bestätigten Rückmeldung verfolgen](https://tajo.io/de/blog/grok-bot-brevo-product-feedback/)

7\. Okt. 2026 · 4 Min. Lesezeit

3 Abschnitte

### [MCP oder CLI ist die falsche Frage. Frag, wo der Zustand liegt.](https://tajo.io/de/blog/mcp-or-cli-is-the-wrong-question/)

4\. Nov. 2026 · 7 Min. Lesezeit

5 Abschnitte