Skip to content

MCP-Telemetrie

Optionale, ausdrücklich einzuschaltende Nutzungs-Telemetrie für den CodeCharter-MCP-Server. Was sie erhebt, was sie niemals erhebt, wie Sie sie einschalten und was Sie auf der Insights-Seite dafür bekommen.

Aktualisiert am 2026-06-10

Der CodeCharter-MCP-Server kann anonymisierte Nutzungs-Telemetrie an das Portal senden, damit Sie sehen, wie Ihr Team CodeCharter nutzt. Die Telemetrie ist ausdrücklich einzuschalten und standardmäßig aus. Es verlässt nichts Ihren Rechner, bis Sie sie über einen der drei Aktivierungswege unten einschalten. Sobald Sie das tun, weist Sie der Server beim Start in Klartext darauf hin, und Sie können sie jederzeit wieder ausschalten.

Die Daten sind so geschnitten, dass sie weder Ihren Source-Code noch Ihre Datei-Struktur noch die Identität einer Person tragen. Die erhobenen Felder sind eine feste Allowlist. Die sensiblen Felder werden nicht zur Laufzeit herausgefiltert, sie sind strukturell nicht Teil des Payload-Typs und können deshalb auch nicht versehentlich gesendet werden.

Telemetrie einschalten

Die Telemetrie aktiviert sich, sobald einer der folgenden Wege vorliegt. Die drei Wege sind mit ODER verknüpft, ein einzelner reicht also aus. Liegen mehrere Wege gleichzeitig vor, werden sie in einer festen Reihenfolge geprüft: erst das CLI-Flag, dann die Umgebungsvariable, dann die Konfigurationsdatei. Der erste Weg, der die Telemetrie einschaltet, bestimmt auch den Endpoint. Insbesondere gilt: Solange CODECHARTER_TELEMETRY=1 gesetzt ist, wird der Standard-Endpoint verwendet und ein eigener telemetry.endpoint in der codecharter.config.json ignoriert.

1. Konfigurationsdatei

Legen Sie eine codecharter.config.json in dem Arbeitsverzeichnis an, in dem Sie den MCP-Server starten:

{
  "telemetry": {
    "enabled": true,
    "endpoint": "https://codecharter.tools"
  }
}

Der Schlüssel endpoint ist optional und hat den Standardwert https://codecharter.tools.

Eine fehlerhafte codecharter.config.json (ungültiges JSON oder ein falscher Werttyp) wird ohne Warnung wie ausgeschaltete Telemetrie behandelt. Wenn die Telemetrie unerwartet aus bleibt, prüfen Sie zuerst das JSON der Datei.

2. Umgebungsvariable

Setzen Sie CODECHARTER_TELEMETRY=1 in der Umgebung, bevor Sie codecharter mcp starten. Nur der Wert 1 schaltet die Telemetrie ein. Jeder andere Wert (auch 0) hat keine Wirkung. Die Variable kann die Telemetrie nur einschalten, nicht ausschalten. Die Telemetrie ist opt-in und standardmäßig aus, unabhängig davon ob die Variable gesetzt ist.

CODECHARTER_TELEMETRY=1 codecharter mcp

3. CLI-Flag

Übergeben Sie --telemetry an codecharter mcp. Ein optionales --telemetry-endpoint überschreibt die Ingest-URL:

codecharter mcp --telemetry
codecharter mcp --telemetry --telemetry-endpoint https://codecharter.tools

Hinweis beim ersten Start

Wenn die Telemetrie aktiv ist, schreibt der MCP-Server beim Start eine einzelne Zeile nach stderr, sodass die Aktivierung nie stillschweigend passiert:

[codecharter] Telemetry enabled. Data goes to <endpoint>. Overview: /docs/en/cli/telemetry

Um die Telemetrie wieder auszuschalten, entfernen Sie jeden gerade aktiven Aktivierungsweg: lassen Sie das Flag --telemetry weg, löschen Sie CODECHARTER_TELEMETRY und setzen Sie "enabled": false in der Konfigurationsdatei (oder entfernen Sie die Datei). Weil die Wege mit ODER verknüpft sind, hebt ein "enabled": false in der Konfigurationsdatei allein ein weiterhin gesetztes Flag oder eine gesetzte Umgebungsvariable nicht auf. Sobald kein Weg mehr die Telemetrie einschaltet, werden ab dem nächsten Server-Start keine Events mehr gesendet.

Welche Daten erhoben werden

Jeder Tool-Aufruf erzeugt ein Event. Der Payload enthält ausschließlich die Felder aus der folgenden Allowlist.

Feld Beschreibung
tool_name Name des aufgerufenen MCP-Tools (zum Beispiel analyze_file).
latency_bucket Latenz des Aufrufs, abgerundet auf das nächstniedrigere Vielfache von 50 ms (74 ms werden zum Beispiel als 50 gemeldet). Der exakte Wert wird nie übertragen.
is_success true, wenn der Aufruf erfolgreich abgeschlossen wurde. false, wenn das Tool ein Fehlerergebnis zurückgegeben oder eine unbehandelte Ausnahme ausgelöst hat.
workspace_id Reserviertes Feld. Der MCP-Server überträgt Ihren Repository-Pfad nie, auch nicht gehasht: Er sendet hier immer einen festen Platzhalter-Hash.
finding_summaries Reserviertes Feld aus Einträgen { rule_id, severity, count }. Der MCP-Server sendet immer eine leere Liste; aus MCP-Tool-Aufrufen verlassen keine Finding-Zahlen pro Regel Ihren Rechner.
license_id Lizenz-Nonce-GUID zur Zuordnung zum Account. Fehlt, wenn keine Lizenz geladen ist.
client_instance_id Stabile GUID pro Installation, lokal beim ersten telemetrie-aktiven Server-Start zufällig erzeugt und gespeichert. Erlaubt dem Portal, die Nutzung pro Arbeitsplatz aufzuschlüsseln, ohne jemanden zu identifizieren. Siehe client_instance_id zurücksetzen.
code_guard_version Versionszeichenkette der CodeCharter-CLI.
dot_net_version Versionszeichenkette der .NET-Laufzeit (zum Beispiel 9.0.1).
os_family Betriebssystem-Familie: win, mac oder linux.
occurred_at_utc UTC-Zeitstempel, zu dem das Event aufgezeichnet wurde.

Welche Daten niemals erhoben werden

Die folgenden Felder sind ausdrücklich ausgeschlossen. Sie sind strukturell nicht Teil des Telemetrie-Payload-Typs und können deshalb nicht ohne eine getrennte, nachverfolgte Änderung hinzukommen. Das ist der Kern des Datenschutz-Entwurfs: Ihr geistiges Eigentum und die Identität Ihrer Entwickler bleiben auf Ihrem Rechner.

Ausgeschlossenes Feld Grund
Source-Code-Inhalt Enthält Ihr geistiges Eigentum.
Datei-Pfade, auch in Findings Verraten Verzeichnislayout und Projektstruktur.
Diff-Inhalte Enthalten Ihr geistiges Eigentum.
Git-Author-Name und -Email Personenbezogene Daten nach Art. 4 DSGVO.
Text eigener Regel-DSL Enthält Ihre Konventionen und Geschäftslogik.
Dateinamen Verraten die Projektstruktur.
Klassennamen Verraten Design-Entscheidungen.
Methodennamen Verraten Design-Entscheidungen.
Finding-Message-Text Kann Code-Snippets enthalten.

Was Sie dafür bekommen: die Insights-Seite

Mit eingeschalteter Telemetrie aggregiert das Portal die Events unter Ihrer Lizenz und stellt sie auf der Insights-Seite dar. Die Seite steht jedem angemeldeten Account zur Verfügung und ist vor allem für Team-Leitungen nützlich, die verstehen wollen, wie CodeCharter im Team genutzt wird. Jede Ansicht lässt sich zwischen einem 7-Tage-, 30-Tage- und 90-Tage-Fenster umschalten. Bis die ersten Events eintreffen, zeigt die Seite einen leeren Zustand mit einem Link zurück auf diese Dokumentation. Erwarten Sie also nicht sofort nach dem Einschalten Daten.

Die Insights-Seite zeigt:

  • Tool-Aufruf-Volumen pro Tool, also wie oft jedes MCP-Tool (analyze_file, analyze_solution, dry_run_rule und die übrigen) im gewählten Zeitraum aufgerufen wurde.
  • Latenz-Perzentile pro Tool, also p50, p95 und p99 pro Tool, sodass langsame Tools und Regressionen auffallen.
  • Die häufigsten Regeln nach Finding-Zahl, ein guter Hinweis darauf, wo Ihr Code oder Ihr Team Aufmerksamkeit braucht. MCP-Events tragen keine Finding-Zahlen, diese Ansicht füllt sich also nur aus Läufen von codecharter analyze --telemetry.
  • Erfolgs- und Fehlerquote über die Zeit, also den Anteil erfolgreicher und fehlgeschlagener Aufrufe pro Tag über den Zeitraum.
  • Eine Aufschlüsselung pro Arbeitsplatz, also eine Zeile je client_instance_id mit Aufruf-Volumen, Erfolgsquote und den Regeln, die der jeweilige Arbeitsplatz am häufigsten auslöst. Die Regel-Spalte bleibt bei reiner MCP-Nutzung ebenfalls leer und füllt sich durch Läufe von codecharter analyze --telemetry. Das beantwortet Fragen wie, welcher Arbeitsplatz welche Regel am häufigsten trifft, ohne je eine Person zu identifizieren, weil die Id eine zufällige lokale GUID ist.

Transport

Events werden im Speicher gebündelt und als JSON-Array per HTTPS an {endpoint}/api/v1/telemetry/events gesendet. Der Puffer wird alle 30 Sekunden oder bei 50 angesammelten Events geleert, je nachdem, was zuerst eintritt. Beim Herunterfahren des Servers wird der Restpuffer geleert. Die Telemetrie ist fail-open: Transport-Fehler werden verschluckt und nach stderr geloggt, ein fehlgeschlagener Versand bricht also nie den normalen Betrieb des Servers ab. Es gibt keine Retry-Queue, ein fehlgeschlagener POST wird verworfen.

Die Uploads sind mit Ihrer Lizenz authentifiziert: Sie wird bei jedem Telemetrie-POST als Bearer-Credential mitgesendet, und das Portal weist nicht authentifizierte Uploads ab. Events erscheinen auf der Insights-Seite deshalb nur, wenn eine gültige Lizenz geladen ist.

Aufbewahrungsdauer

Telemetrie-Events werden 60 Tage aufbewahrt und danach automatisch gelöscht. Aggregierte Auswertungen ohne Personenbezug behalten wir darüber hinaus.

client_instance_id zurücksetzen

Die client_instance_id liegt als Klartext in einer einzelnen Datei:

  • Windows: %LOCALAPPDATA%\CodeCharter\client-instance-id
  • Linux und macOS: $XDG_DATA_HOME/codecharter/client-instance-id, mit dem Fallback ~/.codecharter/client-instance-id, wenn XDG_DATA_HOME nicht gesetzt ist.

Löschen Sie die Datei, um die Id zurückzusetzen. Der nächste telemetrie-aktive MCP-Start erzeugt und speichert eine neue zufällige GUID. Vergangene Events mit der alten Id bleiben auf dem Portal, bis das 60-Tage-Fenster abläuft. Sobald die Id ersetzt ist, verweist kein neues Event mehr auf die alte.

Datenschutz und Löschanfragen

Der Payload enthält keine personenbezogenen Daten im Sinne von Art. 4 DSGVO. Die Workspace-Id ist ein fester Platzhalter-Hash, die Lizenz-Nonce ist eine zufällige UUID, die außerhalb des Abrechnungssystems auf keinen Namen und keine Email abbildet, und die client_instance_id ist eine zufällige lokale GUID, die nicht aus Hardware oder einem personenbezogenen Merkmal abgeleitet ist. Die vollständige DSGVO-Auskunft steht auf der Seite Datenschutz und DSGVO.

Um die Löschung aller zu Ihrer Lizenz gesendeten Events zu verlangen, schreiben Sie an [email protected] mit dem Betreff "Telemetry deletion request" und Ihrer Lizenz im Anhang. Ihre Lizenzdatei (codecharter.license) können Sie auf der Downloads-Seite des Portals herunterladen.

Verwandt