Claude zu LLM-Logs befragen: OAuth-MCP-Connector ohne API-Key

Ein LLM-Gateway als eigenen Connector in Claude einbinden, anmelden, Lesezugriff auf das Request-Log erlauben und im Chat fragen. Drei Fragen, 14 Tool-Aufrufe, geprüft.

11. Oktober 2026

„Welche Session war heute Morgen am teuersten, und warum?“ Das lässt sich durch Nachsehen in der Konsole beantworten. Oder man fragt Claude in einem Chat, der dieselben Daten lesen kann. In dieser Anleitung binden wir das Synthorai-Gateway über MCP (das Protokoll, mit dem Modelle Tools erhalten) als Connector in Claude ein. Statt einen API-Key einzufügen, melden wir uns an und erlauben ausschließlich Lesezugriff auf das Request-Log. Anschließend stellen wir drei Fragen zu den Sessions aus den bisherigen Anleitungen dieser Reihe. Jede Zahl in den Antworten stimmte mit den Abrechnungsdaten überein.

TL;DR

• Claude verbindet sich per OAuth-Anmeldung mit dem MCP-Server des Synthorai-Gateways als eigenem Connector. Ein API-Key muss nicht eingefügt werden.
• Die Freigabe ausschließlich für das Request-Log gab Claude vier schreibgeschützte Tools und einen Key mit dem Scope logs.read, der nach 7 Tagen abläuft.
• Claude Fable 5.1 beantwortete drei Fragen zum Log mit 14 Tool-Aufrufen. Alle Zahlen stimmten mit den Abrechnungsdaten überein.
• Die Log-Tools liefern Kosten, Token-Zahlen und Status, aber niemals Prompts oder Antworttexte.

Die Verbindung nutzt MCP (Model Context Protocol), den Standard für die Bereitstellung von Tools für Assistenten: Ein Server listet seine Tools auf, und der Assistent ruft sie auf. Das Gateway stellt einen solchen Server unter https://synthorai.io/v1/mcp bereit. Einen MCP-Server, den man seinem Account hinzugefügt hat, nennt Claude einen Connector. Auf dieser Seite gibt es keinen Code, und es muss nichts installiert werden.

Wir haben die Verbindung am 10. Oktober 2026 eingerichtet und die Fragen am nächsten Tag auf claude.ai im Browser gestellt. Als Chat-Modell kam Claude Fable 5.1 zum Einsatz. In Claude Desktop lässt sich ein eigener Connector genauso hinzufügen.

Wie fügt man das Gateway in Claude hinzu?

Für einen eigenen Connector gibt man einen Namen und die URL des Servers an. In Claude öffnet man „Anpassen“, dann „Connectors“, wählt „Hinzufügen“ und anschließend „Eigenen Connector hinzufügen“:

Nach „Weiter“ prüft Claude den Server. Danach zeigt es die Verbindungseinstellungen an. Zwei Optionen hat es bereits anhand der Serverangaben erkannt:

• Authentifizierung: „Jetzt anmelden“. Jeder Nutzer meldet sich am Server an, bevor er dessen Tools verwendet. Das läuft über OAuth: Der Server bittet im Browser um Freigabe der Verbindung und übergibt Claude ein Access-Token. Es wird kein API-Key eingegeben oder in einer Datei gespeichert.
• OAuth-Client: „Automatisch registrieren“. Claude registriert sich beim Verbindungsaufbau selbst am Server. Man muss nirgends eine Client-ID anlegen.

Beide erkannten Einstellungen bleiben unverändert. Nach „Hinzufügen“ leitet Claude zur Freigabe der Verbindung auf Synthorai weiter. Falls die Connector-Seite stattdessen eine abgelaufene Verbindung meldet, wählt man „Erneut verbinden“. So kamen wir zur Freigabeseite.

Was gibt man bei der Anmeldung frei?

Man wählt den Workspace, den Zweck der Verbindung, die zugänglichen Daten und das Ende des Zugriffs. Die Seite wird vom Gateway bereitgestellt. Wer noch nicht in dessen Konsole angemeldet ist, muss sich zuerst anmelden:

• Workspace. Die Verbindung sieht genau einen Workspace. Man wählt denjenigen aus, dessen Requests untersucht werden sollen.
• Zweck dieser Verbindung. Mit „Modelle ausführen“ kann Claude Modelle über das Gateway aufrufen. Die Kosten werden dem Workspace berechnet. Für diese Anleitung wählen wir „Workspace lesen und verwalten“. Damit werden nur die darunter angekreuzten Berechtigungen erteilt.
• Claude darf verwenden. Es gibt fünf Gruppen: Nutzung und Guthaben, das Request-Log, die Prompt-Bibliothek, API-Keys (nur lesend) sowie Mitglieder mit Audit-Log und Einstellungen. Wir haben nur das Request-Log angekreuzt.
• Zugriff. Nur lesend. Unser Workspace erlaubt per Workspace-Einstellung keine Änderungen über MCP. Deshalb bietet die Seite keine andere Option an.
• Zugriff endet nach. 1, 7, 30 oder 90 Tagen. Wir haben 7 beibehalten.

Nach „Erlauben“ kehrt der Browser zu Claude zurück. Claude meldet den Connector als verbunden und listet dessen Tools auf:

Der Connector hat vier Tools, alle nur lesend: search_requests, get_request, list_sessions und list_traces. Sie liefern Angaben zum Aufruf und seinem Verlauf (Modell, Status, Tokens, Kosten, Zeitdaten, Session, Trace und Labels), aber niemals den Prompt oder die Antwort. Auf dieser Seite lässt sich außerdem für jedes Tool festlegen, ob es immer erlaubt ist, zuerst nachfragen muss oder blockiert wird.

Wo erscheint die Verbindung auf der Gateway-Seite?

Sie erscheint als eigener Key unter „API-Keys“ im Tab „Admin-Keys“:

Der Key heißt MCP: Claude, hat den einen angekreuzten Scope (logs.read) und läuft am gewählten Tag ab. Ein Scope ist eine Berechtigung, die einem Key zugeordnet ist. Man bekommt den Key nie zu sehen und muss ihn nicht selbst verwalten. Hier lässt er sich aber deaktivieren oder löschen. Damit endet die Verbindung sofort, unabhängig davon, was Claude gespeichert hat.

Was haben wir gefragt, und stimmten die Antworten?

Wir stellten drei Fragen zu den Requests, die die Demos dieser Reihe gerade erzeugt hatten. Jede Zahl in den Antworten stimmte mit den Abrechnungsdaten überein, die die Demo-Skripte ausgegeben hatten. Jede Frage grenzt die Suche mit einem Zeitraum und einem Label ein. Ein Label ist ein Schlüssel-Wert-Paar, das die Anwendung mit jedem Request im Header X-Synthorai-Metadata sendet. Die Demos versehen jeden Request mit feature, mit case (dem nachgestellten Problem) und mit variant (before für den fehlerhaften Lauf, after für den zugehörigen korrigierten Lauf). Das in den Antworten erwähnte Prompt-Caching berechnet wiederholte Prompt-Präfixe günstiger: Beim ersten Senden wird ein Schreibzugriff abgerechnet, danach ein Lesezugriff.

Verwende den Synthorai-Connector. Berücksichtige nur Requests zwischen 2026-10-11T11:24:00Z und 2026-10-11T11:32:00Z mit dem Label feature = support-agent. Welche Session mit dem Label case = cache-miss, case = context-growth oder case = replay-mismatch war am teuersten, und was erklärt diese Kosten in ihren Token-Zahlen?

An drei Stellen gingen die Antworten über das bloße Wiedergeben von Zahlen hinaus:

• Claude nutzte Labels ohne Anleitung. Öffnet man einen Tool-Aufruf im Chat, sieht man dessen Argumente. Der erste Aufruf von list_sessions enthielt unter labels die Angaben case = cache-miss und feature = support-agent, den Zeitraum und ein Limit von 50. Für jeden Case gab es einen solchen Aufruf. Bei der dritten Frage suchte Claude zuerst nach dem Feld für den Nutzer, fand das Label _user und filterte danach.
• Claude fand den naheliegenden Vergleich. Die erste Antwort nennt die Session aus Warum ist mein LLM-Agent teuer?, in der eine Nachricht anders gespeichert als gesendet wurde. Claude fand die korrigierte Session anhand ihres Labels variant = after. Es stellte fest, dass beide fast dasselbe Prompt-Volumen hatten, und führte den Unterschied von 2.5x auf in den Cache geschriebene statt daraus gelesene Tokens zurück. Außerdem listete es die teure Session Runde für Runde auf. Daran sieht man, dass sich die Kosten mit wachsendem Prompt von der ersten bis zur sechsten Runde ungefähr verdoppeln.
• Claude benannte die Aussagekraft und die Grenzen der Zahlen. Die zweite Antwort weist darauf hin, dass die korrigierte Session mehr Output erzeugte (1,750 Tokens gegenüber 1,599). Die Einsparung beim Input allein ist deshalb größer als die Nettodifferenz von 25.6%. In der ersten Antwort erklärt Claude, dass der Connector keine Prompt-Inhalte zurückgibt und es deshalb nicht sehen kann, was den Cache-Treffer verhindert hat.

Wir haben bei der ersten Antwort nicht nur die Zahlen, sondern auch die Erklärung geprüft. Das Modell in diesen Sessions ist GPT-6 Luna. Pro Million Tokens berechnet es $0.10 für Input, $0.01 für aus dem Cache gelesenen Input, $0.125 für in den Cache geschriebenen Input und $0.50 für Output. Zu diesen Preisen ergeben die 24,539 in den Cache geschriebenen Tokens, 18 sonstigen Input-Tokens und 1,523 Output-Tokens der teuren Session $0.003831. Die zugehörige korrigierte Session kommt mit 5,840 geschriebenen, 18,844 gelesenen, 18 sonstigen Input-Tokens und 1,204 Output-Tokens auf $0.001522. Beide Beträge entsprechen der Abrechnung. Die Erklärung über Cache-Schreib- und Lesezugriffe stimmt also.

Was sollte man an einer Antwort prüfen?

Zuerst prüft man den Suchbereich der Tool-Aufrufe, danach Erklärungen, die von Preisen oder der eigenen Konfiguration abhängen. Die Zahlen unserer drei Antworten waren richtig. Am verlässlichsten sind Zahlen, die direkt aus einem Tool-Ergebnis übernommen wurden. Prozentsätze und Verhältnisse berechnet das Modell selbst; diese sollte man nachrechnen. Vier Dinge können trotzdem in die Irre führen:

• Eine Antwort deckt nur den Bereich ihrer Tool-Aufrufe ab. Jeder Aufruf hat einen Zeitraum, Labels und ein Limit. Der Chat zeigt jeden Aufruf mit seinen Argumenten. So lässt sich erkennen, ob „die teuerste Session“ aus allen Sessions oder nur aus den ersten 50 ausgewählt wurde.
• Erklärungen stammen aus allgemeinem Wissen. Die Datensätze zeigen, was passiert ist. Warum es passiert ist, leitet das Modell selbst ab. Das muss nicht zu den verwendeten Modellen oder Preisen passen. Bevor man auf Grundlage einer Erklärung handelt, sollte man eine Zahl nachrechnen, wie wir es oben getan haben.
• Zeiten werden in der eigenen Zeitzone angezeigt. Das Log verwendet UTC, und wir haben in UTC gefragt. Die Antworten nannten Zeiten in Pacific Time, der Zeitzone, die Claude für unseren Account hatte. Man muss sie deshalb mit dem UTC-Zeitraum der Frage abgleichen.
• Die Tools liefern niemals Inhalte. Claude kann sagen, dass ein Request mit einem 404 fehlgeschlagen ist und was die Fehlermeldung lautete. Es kann nicht sagen, was der Nutzer gefragt hat. Wenn eine Frage diese Information benötigt, weist Claude darauf hin.

Ein Label und ein enger Zeitraum in der Frage halten die Antwort präzise und kurz. Jede Zeile, die ein Tool zurückgibt, wird Teil des Gesprächs.

Was kostet das, und wie begrenzt man den Zugriff?

Die Log-Tools lassen sich kostenlos aufrufen. Die Arbeit des Modells ist Teil des Claude-Abos, sodass die Fragen keine Kosten auf der Gateway-Rechnung verursachen. Eine längere Untersuchung verbraucht allerdings Kontingent im Abo, weil Tool-Ergebnisse als Gesprächsinhalt zählen.

Die Verbindung erhält nur den freigegebenen Zugriff:

• Eine Datengruppe. Nur das Request-Log wurde angekreuzt. Die Verbindung hat deshalb keine Tools für Guthaben, Prompts, Keys oder Mitglieder.
• Nur lesend. Kein Tool ändert etwas oder ruft ein Modell auf.
• Ein Ablaufdatum. Der Key läuft nach dem gewählten Zeitraum ab und lässt sich vorher löschen.
• Keine Prompts oder Antworttexte. Die Tools liefern ausschließlich Metadaten.
• Tool-Berechtigungen in Claude. Jedes Tool lässt sich so einstellen, dass es vor der Ausführung nachfragt. Das ist die Standardeinstellung auf der Connector-Seite. Unser Chat lief in Claudes Berechtigungsmodus „Auto“. In diesem Modus verwendet Claude Connectoren selbstständig und hält nur an, wenn etwas unsicher erscheint. Die Lesezugriffe liefen deshalb ohne Rückfrage.

Beim Teilen eines solchen Chats ist Vorsicht nötig. Eine Antwort kann Session-IDs, Nutzer-IDs aus dem Label _user und Modellnamen enthalten.

FAQ

Kann Claude meine LLM-Request-Logs lesen?

Ja, über einen Connector zu einem MCP-Server, der diese Logs bereitstellt. Wenn das Synthorai-Gateway als eigener Connector hinzugefügt und das Request-Log bei der Anmeldung freigegeben wurde, kann Claude Requests durchsuchen, Sessions und Traces auflisten sowie Kosten, Tokens, Status und Labels lesen. Prompts und Antworten kann es nicht lesen, weil die Tools diese nicht zurückgeben.

Brauche ich einen API-Key, um Claude mit einem MCP-Server zu verbinden?

Nicht, wenn der Server eine OAuth-Anmeldung unterstützt. Fügt man https://synthorai.io/v1/mcp als eigenen Connector hinzu, wird man auf eine Freigabeseite weitergeleitet. Das Gateway erstellt selbst einen Key für die Verbindung, mit ausschließlich den angekreuzten Scopes und einer Laufzeit von 1 bis 90 Tagen. Der Key erscheint unter „API-Keys“ und lässt sich dort löschen.

Wie genau analysiert Claude Logs?

In unserem Test mit Claude Fable 5.1 stimmte jede Zahl in drei Antworten mit den Abrechnungsdaten überein: Kosten, Token-Zahlen, Request-Zahlen und Statuscodes. Auch die Erklärung für die teuerste Session bestätigte sich, als wir die Abrechnung anhand der Modellpreise nachrechneten. Trotzdem sollte man prüfen, auf welchen Tool-Aufrufen eine Antwort beruht.

Was kostet es, Claude zum Gateway-Log zu befragen?

Auf der Gateway-Rechnung kostet es nichts: Die Log-Tools sind kostenlos, und für die drei Fragen auf dieser Seite wurden 14 Tool-Aufrufe ausgeführt. Die Arbeit des Modells wird auf das Claude-Abo angerechnet. Ein Programm, das über die API fragt, bezahlt stattdessen seine eigenen Modell-Tokens. Das wird in Log-Tools für den eigenen Agenten gemessen.

Ist es sicher, Claude mit einem Request-Log zu verbinden?

Die Sicherheit hängt von den freigegebenen Berechtigungen ab. Diese Verbindung hatte Zugriff auf eine Datengruppe (das Request-Log), ausschließlich Leserechte, eine Laufzeit von 7 Tagen und keinen Zugriff auf Prompts oder Antworttexte. Sie kann den Workspace nicht ändern und kein Modell aufrufen. Löscht man ihren Key unter „API-Keys“, endet die Verbindung.

Weiterführende Artikel

• Einen LLM-Agenten mit Traces untersuchen: Wie Requests die Session-IDs und Labels erhalten, nach denen diese Fragen filtern.
• Warum ist mein LLM-Agent teuer?: Die Sessions, auf die sich die ersten beiden Fragen beziehen.
• Warum ist mein LLM-Agent langsam? und Einen LLM-Agenten debuggen: Dieselbe Art der Untersuchung, von Hand in der Konsole durchgeführt.
• Claude-Code-Kosten nach Sub-Agent: Wie die eigenen Sessions von Claude Code im selben Log aussehen.
• Log-Tools für den eigenen Agenten: Dieselben Tools aus einem Programm mit API-Key und die Kosten der Modell-Tokens.
• MCP-Server-Referenz: Alle Tools, die Key-Scopes und Möglichkeiten, eine Verbindung einzuschränken.

← Anwendungsfälle