Persönlicher Cronometer MCP

Dies ist eine lokale, persönliche Brücke zwischen Cronometer und MCP-Clients wie Codex und Claude Code. Sie kombiniert die nützliche Live-Kontenabdeckung des cronometer-mcp-Clients von Paul Hoskins mit einer strengeren TypeScript-Schicht, die fehlende Ernährungsdaten bewahrt, kontenändernde Aktionen ehrlich kennzeichnet und Anmeldedaten aus MCP-Konfigurationsdateien heraushält.

Es ist ein persönliches Lernprojekt, das von einem NASM Certified Sports Nutrition Coach (CSNC) erstellt wurde, der zusätzlich Universitätskurse in Ernährung außerhalb seines Studienfachs belegt hat. Dieser Hintergrund prägt die Prioritäten des Projekts, aber diese Software ist kein medizinisches Gerät und kein Ersatz für medizinische Versorgung.

Es bietet vollen Live-Zugriff, unterstützt durch den festgelegten Client: Ernährungstagebuch lesen und schreiben, abdeckungsbewusste Nährstoffzusammenfassungen, Roh-CSV-Exporte, Lebensmittelsuche, Makroziele und -zeitpläne, Fastenaufzeichnungen, Biometriedaten, Tageskopie/-abschluss und wiederkehrende Lebensmittel.

Wichtige Einschränkungen

• Dies ist ein inoffizielles persönliches Tool. Cronometer stellt diese Schnittstelle nicht bereit und unterstützt sie nicht. Eine Änderung der Cronometer-Website kann es ohne Vorwarnung zerstören, und automatisierter Zugriff kann das Konto gefährden. Lesen Sie die aktuellen Nutzungsbedingungen von Cronometer, bevor Sie es aktivieren.

• Einige CSV-Exportfunktionen erfordern möglicherweise Cronometer Gold. Cronometer dokumentiert seinen unterstützten manuellen Exportablauf in Kontoeinstellungen: Datenexport.

• Dieses Tool berichtet, was protokolliert wurde und wie vollständig der Eintrag ist. Es ist kein medizinisches Gerät, diagnostiziert keine Nährstoffmängel und bietet keine medizinische Beratung.

• Alles bleibt lokal. Das Projekt hat bewusst keinen HTTP-Server, keinen Remote-Bereitstellungsmodus, keine Telemetrie und kein Werkzeug zur Ausführung beliebigen Codes.

Warum die Nährstoffzusammenfassung sicherer ist

Cronometers tägliche Zusammenfassung hat eine subtile Falle: Eine leere Nährstoffzelle bedeutet „keine Daten“, während eine angezeigte Null eine erfasste Null bedeutet. Die Zeile Total kann fehlende Zellen auf Null reduzieren. Dieser Server parst die Zeilen der Tagebuchgruppen selbst, berechnet die Abdeckung für jeden Nährstoff und gibt nur dann einen Aufnahmewert zurück, wenn die angeforderte Abdeckungsschwelle erreicht ist. Bei der Standardschwelle von 1 muss jede Zelle der Tagebuchgruppe für diesen Nährstoff Daten enthalten.

Ein Nährstoffergebnis hat daher eine von zwei Formen:

• kind: "value" — enthält den Wert, die Einheit, die Gruppenabdeckung, die Tagesabdeckung und den Vergleich mit dem Cronometer-Gesamtwert.

• kind: "insufficient-data" — enthält die Abdeckung und die explizit benannte Untergrenze observedSubtotal, kann diese Zwischensumme jedoch nicht als Aufnahme ausdrücken.

Diese Unterscheidung wird vom CSV-Parsing bis zur endgültigen MCP-Ausgabe beibehalten.

Jedes Auslesen des Tagebuchs wird hier geparst, nicht vorgelagert

Der festgelegte Client liest eine CSV mit csv.DictReader und gibt Zeilen untypisierter Strings zurück. Das ist als Transport gut und als Modell Ihres Tagebuchs nutzlos, daher verwendet dieser Server es nicht. cronometer_get_food_log, cronometer_get_exercises, cronometer_get_biometric_log und cronometer_get_notes rufen jeweils den Roh-Export ab und parsen ihn stattdessen hier. Was Ihnen das bringt:

• 1.00 container - each 5.3 oz kommt als Menge und Einheit zurück, nicht als ein String, der später erraten werden muss.

• Eine leere Trainingsdauer wird als fehlend gemeldet, nicht als null Minuten.

• Die Einheiten bleiben so, wie Ihr Konto sie anzeigt. Es wird nichts umgerechnet.

• Eine Zeile, die nicht gelesen werden kann, wird verworfen und gemeldet, mit Datei und Zeile, sodass eine kurze Liste nie stillschweigend kurz ist.

• Eine Zeit, die nie aufgezeichnet wurde, ist null, niemals Mitternacht.

Eine bewusste Verweigerung ist wissenswert. Wenn Cronometers Export jemals eine Spalte verliert, die dieser Server benötigt, würde der Parser null Zeilen zurückgeben – was genau wie ein Tag aussieht, an dem Sie nichts protokolliert haben. Anstatt das zurückzugeben, schlägt der Aufruf fehl und benennt die fehlende Spalte. Eine leere Antwort hier wäre derselbe Fehlertyp wie das Lesen eines fehlenden Nährstoffs als Null.

Dieselbe Regel gilt nun für Live-Abfragen, die nicht über eine CSV laufen. Wenn eine davon in einer Form zurückkommt, die der Connector nicht erkennt, trägt das Ergebnis unverified: true – das bedeutet „leer, und ich konnte das nicht bestätigen“. Ein Aufruf, der wirklich fehlschlägt, löst stattdessen eine Ausnahme aus. Das Flag ist also dem einen wirklich mehrdeutigen Fall vorbehalten: einer Antwort, die Daten benennt, die sie anschließend nicht finden kann.

Die richtige Abgrenzung zu finden, brauchte zwei Durchgänge. Der erste markierte jedes leere Ergebnis als unbestätigt, in der Annahme, dass ein fehlender Elementtyp-Marker bedeuten könnte, dass sich das Format geändert hat. Die Prüfung der tatsächlichen Antworten zeigte das Gegenteil – eine leere Sammlung hat keinen Elementtyp, weil sie keine Elemente hat. Die Warnung feuerte also bei korrekten Antworten, und genau so wird eine Warnung zu Rauschen. Jetzt feuert sie nur noch, wenn die Antwort etwas enthält, das der Parser nicht lesen konnte.

Live-Aufrufe sind außerdem gedrosselt, mindestens eine Sekunde Abstand. Das ist beim Lesen der Antworten nicht wahrnehmbar und macht den Unterschied zwischen einem Gespräch und einem Scraping.

Eine Sache, die Sie bei der Einrichtung Ihres Tagebuchs vermeiden sollten: Benennen Sie keine Tagebuchgruppe Total. Cronometer schreibt seine eigene tägliche Summe in dieselbe Spalte wie Ihre Gruppennamen, und der Export bietet keine Möglichkeit, die beiden zu unterscheiden. Eine Gruppe mit diesem Namen würde als Tagesgesamtbetrag gelesen und aus der Summe herausgelassen, sodass ihre Lebensmittel stillschweigend aus jeder Aufnahmezahl verschwinden würden. Jeder andere Name ist in Ordnung.

Nährstoffzellen werden ebenfalls streng gelesen. Eine Zelle muss leer oder eine einfache nicht-negative Dezimalzahl sein; alles andere – Text, ein Tausendertrennzeichen, eine negative Zahl – wird als fehlend aufgezeichnet, mit einem Hinweis, welche Spalte und Zeile betroffen ist, anstatt in eine Zahl umgewandelt zu werden, die stillschweigend eine Summe verändern würde.

Windows-Einrichtung

Öffnen Sie PowerShell und führen Sie Folgendes aus:

Set-Location C:\dev\cronometer
.\scripts\setup-windows.ps1

Auf macOS lautet das Äquivalent sh scripts/setup-macos.sh, das dieselben Dinge in derselben Reihenfolge tut — siehe Andere Plattformen für das, was dort getestet ist und was nicht.

Das Setup führt Folgendes aus:

1. Installiert die festgelegten Node-Abhängigkeiten neu.

2. Erstellt oder aktualisiert eine private Python-3.12-Umgebung anhand einer hash-geprüften Lock-Datei mit fünf Paketen (requests und seine vier transitiven Abhängigkeiten – der Protokoll-Client ist mitgeliefert, nicht installiert).

3. Baut den Server und führt alle Offline-Tests aus.

4. Fragt nach der Cronometer-Tagebuchzeitzone. America/New_York ist die empfohlene Standardeinstellung für diesen Computer.

5. Zeigt die Warnung zur nicht unterstützten Schnittstelle und verlangt das genaue Wort ENABLE, bevor der Live-Zugriff aktiviert wird.

6. Fordert zur Eingabe von Cronometer-Benutzername und -Passwort auf. Windows-DPAPI verschlüsselt das Passwort für das aktuelle Windows-Konto; es wird nicht in dieses Repository, in eine Befehlszeile, in die Codex-Konfiguration oder die Claude-Konfiguration geschrieben.

7. Bietet an, den Server bei jedem Client zu registrieren, den es installiert vorfindet – Codex, Claude Code und Claude Desktop. Jeder Client wird getrennt angefragt, und das Überspringen eines Clients hat keine Auswirkungen auf die anderen.

   • Codex erhält zusätzlich default_tools_approval_mode = "writes" in seine config.toml geschrieben, sodass jedes nicht als schreibgeschützt markierte Werkzeug eine Genehmigung anfordert. Wenn dieser Schritt fehlschlägt, sagt das Setup das deutlich, anstatt Sie mit einem registrierten Server zurückzulassen, der nicht nachfragt.

   • Claude Code benötigt keine Genehmigungseinstellung; siehe Schreibsicherheit warum.

   • Claude Desktop hat kein CLI dafür, daher wird seine claude_desktop_config.json direkt bearbeitet. Die vorherige Datei wird zuerst gesichert, alle bereits vorhandenen Server bleiben erhalten, und ein vorhandener cronometer-personal-Eintrag wird niemals überschrieben.

Starten Sie den MCP-Client nach der Registrierung neu. Beginnen Sie mit:

Rufen Sie cronometer_status auf, prüfen Sie dann die Cronometer-Verbindung. Ändern Sie nichts.

Die erste echte Verbindung kann länger dauern, weil sie sich anmeldet und eine Sitzung erstellt. Spätere Verbindungen verwenden einen validierten JSON-Sitzungscache erneut.

Nährstoffabdeckung erfordert einen heruntergeladenen Export

Dies ist der Teil, den es zu verstehen lohnt, denn er entscheidet, welches Werkzeug eine Frage zu Nährstoffen beantwortet.

Cronometer bietet dieselben Daten auf zwei Arten an, und sie sind nicht gleichwertig:

Die Abdeckung funktioniert durch den Vergleich von Mahlzeiten. Wenn die Omega-3-Zelle des Mittagessens leer ist, während das Frühstück 0.00 anzeigt, ist das eine Datenbanklücke und keine Nullaufnahme. Der Live-Export hat diese Mahlzeiten bereits zu einer Zahl zusammengefasst – und genau diese Zahl hat die Leerstellen als Null gezählt. Daher verweigert die Live-Zusammenfassung jetzt die Antwort und verweist hierher, anstatt etwas zurückzugeben, das wie eine Antwort aussieht.

An einem echten Tag von diesem Konto, bei voller Abdeckung, konnten 16 von 61 Nährstoffen als Zahlen gemeldet werden. Die anderen 45 wurden verweigert, jeder einzelne ein Fall, in dem Cronometers eigene Gesamtsumme fehlende Daten als Null aufsummiert hatte. Energie und Protein stimmten exakt mit Cronometer überein und sind vertrauenswürdig. Omega-3 zeigte 0,01 g – an einem Tag mit Lachs – aus nur zwei von vier Mahlzeiten.

So verwenden Sie es: In Cronometer Einstellungen → Konto → Daten exportieren herunterladen und die CSVs in einen datierten Ordner unter dem Exportverzeichnis entpacken, das der Launcher konfiguriert (%LOCALAPPDATA%\CronometerPersonalMcp\exports\2026-08-16\ usw.). cronometer_list_exports zeigt, was es sehen kann. Jeder Export ist eine Momentaufnahme. Wenn Sie sie datiert aufbewahren, entsteht der Verlauf, den eine mehrmonatige Analyse benötigt.

Zwei Dinge zu diesem Verzeichnis. Es liegt in demselben ACL-geschützten Ordner wie Ihre Anmeldedaten, denn ein Export ist Ihr gesamtes Tagebuch pro Mahlzeit. Und der Server akzeptiert niemals einen Pfad – ein Werkzeug übergibt einen Ordnernamen, der aufgelöst und geprüft wird, ob er sich in diesem Verzeichnis befindet. So kann nichts außerhalb davon gelesen werden, nicht einmal durch einen Symlink.

Lebensmittel protokollieren

Ende-zu-Ende verifiziert funktionierend am 2026-08-17: Suchen, Hinzufügen, Zurücklesen, Löschen, Zurücklesen.

Es sind zwei Schritte nötig, denn ein Tagebucheintrag wird über eine Maßeinheit identifiziert, nicht über ein Lebensmittel:

1. cronometer_search_foods — gibt food_source_id (das Lebensmittel) und food_id (seine Standardmaßeinheit) zurück, plus eine Beschreibung wie 1 large - 50g, die Ihnen sagt, wie viel eines davon wiegt.

2. cronometer_add_food_entry — übergeben Sie beide Kennungen, measure_id: 0, die Anzahl der Maßeinheiten als quantity und das tatsächliche Gesamtgewicht als weight_grams.

cronometer_get_food_details listet jede Maßeinheit eines Lebensmittels mit ihrem Gewicht in Gramm auf, sodass Sie weight_grams für „zwei große“ oder „eine halbe Tasse“ ohne Raten ermitteln können.

Eine echte Einschränkung. servings.csv enthält keine Portionskennung, daher kann cronometer_get_food_log keine zurückgeben – und cronometer_remove_food_entry benötigt sie. In der Praxis können Sie nur einen Eintrag löschen, dessen ID Sie noch aus dem Protokollieren in derselben Konversation haben. Um etwas zu entfernen, das früher oder in der App protokolliert wurde, verwenden Sie die Cronometer-App. Dies ist eine Lücke in dem, was der Export offenlegt, und nichts, was der Connector umgehen kann.

Was tatsächlich verifiziert wurde

Die Werkzeuge sind nach Belegen gruppiert, nicht nach Absicht. Alles unten wurde am 2026-08-17 gegen ein echtes Konto getestet.

Verifiziert funktionierend. Lebensmittelsuche, Lebensmitteldetails, das Ernährungstagebuch und die anderen CSV-gestützten Abfragen, die Analyse des heruntergeladenen Exports, Makrovorlagen auflisten/erstellen/löschen, Wiederholungseinträge hinzufügen/löschen, Biometriedaten hinzufügen/entfernen für Gewicht, sowie das Hinzufügen und anschließende Entfernen eines Lebensmitteleintrags.

Verifiziert defekt, und verweigert statt versucht.

• cronometer_add_biometric akzeptiert nur Gewicht. Die Angabe einer Herzfrequenz von 60 erzeugte einen Gewicht-Eintrag von 60 lbs — die Metrik-Kodierung der anderen drei ist Spekulation, und body_fat teilt die Kodierung von weight Byte für Byte, also muss es auf dieselbe Weise falsch ablegen. Ein Schreibvorgang, der Daten stillschweigend unter der falschen Metrik ablegt, korrumpiert einen Trend, den du später liest, und gibt kein Zeichen, dass es passiert ist, daher werden die anderen Metriken verweigert. Trage sie in der Cronometer-App ein.

• cronometer_set_day_complete schlägt fehl: Cronometer hat die Methode setDayComplete entfernt, ebenso wie es findFoods entfernt hat. Lokal lässt sich das nicht beheben.

Nach einem Live-Test behoben. cronometer_get_repeated_items gab früher food_source_id und measure_id vertauscht zurück, eine stets leere Wochentagsliste und eine Tagebuchgruppe von 0. Nun liest es die Antwort so, wie das Protokoll sie tatsächlich schreibt — von hinten nach vorn — und meldet die Wochentage korrekt.

Die Tagebuchgruppe wird als null gemeldet, weil Cronometer sie nicht zurücksendet: Zwei in verschiedenen Gruppen erstellte Regeln lieferten identische Antworten abgesehen von ihren IDs, der Menge und den Wochentagen. Die Gruppe, die du beim Erstellen einer Regel wählst, wird angewendet, nur kann sie nicht zurückgelesen werden. null sagt das aus; 0 hätte wie eine echte Gruppe ausgesehen.

Nie ausgeführt. copy_day (es kopiert einen ganzen Tag und kann nicht sauber rückgängig gemacht werden, weil Portions-IDs nicht aus dem Export zurückgelesen werden können), set_macro_targets und set_macro_schedule_day (Cronometer berechnet empfohlene Ziele aus deinem Profil, und diese Einstellungen überschreiben diese Berechnung — nichts, was man als Test tun sollte), und die beiden Fasten-Tools (es gibt kein create-fast-Werkzeug, also gibt es nichts zu löschen oder abzubrechen).

Schreibsicherheit

Lese- und Schreibwerkzeuge sind bewusst getrennt. Jedes kontoändernde Werkzeug ist als nicht schreibgeschützt markiert, und jedes als destruktiv markierte Werkzeug lehnt den Aufruf ab, wenn nicht confirm: true vorhanden ist.

Der Genehmigungsprozess funktioniert in jedem Client anders, also hier genau, was du wo bekommst:

Der Fall von Claude Code ist der starke, weil die Anforderung mit dem Werkzeug reist, statt in einer Konfigurationsdatei zu leben, die du später ändern könntest. Die anderen hängen von der Client-Konfiguration ab: Das Setup-Skript setzt die von Codex und teilt dir laut mit, wenn es das nicht konnte. Ältere Versionen von Claude Code ignorieren das Flag und fallen auf ihre normale Berechtigungsbehandlung zurück, ebenso wie andere MCP-Clients — ein unbekannter _meta-Schlüssel ist harmlos, weshalb er bedingungslos gesendet wird.

Lesewerkzeuge tragen bewusst kein solches Flag. Eine Statusprüfung, die nervt, würde dir nur beibringen, Aufforderungen zu überspringen, ohne sie zu lesen.

Schreibvorgänge werden nie automatisch wiederholt. Wenn ein Schreibvorgang zeitüberschreitet, meldet der Server, dass sein Ergebnis unbekannt ist. Überprüfe die Cronometer-App, bevor du entscheidest, ob du etwas erneut versuchst; andernfalls könnte ein erneuter Versuch Lebensmittel, Biometriedaten, Vorlagen oder wiederkehrende Elemente duplizieren.

Manuelle MCP-Registrierung

Das Setup bietet normalerweise an, dies zu tun. Wenn du es übersprungen hast, enthält der Befehl nur den lokalen Launcher-Pfad — nie Anmeldeinformationen.

Codex:

codex mcp add cronometer-personal -- pwsh -NoProfile -ExecutionPolicy Bypass -File C:\dev\cronometer\scripts\run-mcp.ps1

Füge dann diese Zeile innerhalb des neuen Abschnitts [mcp_servers.cronometer-personal] der Datei %USERPROFILE%\.codex\config.toml hinzu:

default_tools_approval_mode = "writes"

Claude Code, für den Windows-Benutzer in jedem Projekt verfügbar:

claude mcp add --scope user cronometer-personal -- pwsh -NoProfile -ExecutionPolicy Bypass -File C:\dev\cronometer\scripts\run-mcp.ps1

Claude Desktop hat keinen Registrierungsbefehl. Füge dies zum mcpServers-Objekt in %APPDATA%\Claude\claude_desktop_config.json hinzu, behalte alle bereits vorhandenen Server bei und starte dann Desktop neu:

"cronometer-personal": {
  "command": "C:\\Program Files\\PowerShell\\7\\pwsh.exe",
  "args": ["-NoProfile", "-ExecutionPolicy", "Bypass", "-File", "C:\\dev\\cronometer\\scripts\\run-mcp.ps1"]
}

Verwende den echten Pfad zu pwsh.exe auf diesem Rechner — (Get-Command pwsh).Source gibt ihn aus. Sichere die Datei, bevor du sie bearbeitest: Sie enthält sowohl die eigenen Einstellungen von Claude Desktop als auch die Serverliste, und eine fehlerhafte Bearbeitung würde sie verlieren. Das Setup-Skript erledigt das alles für dich, was der bessere Weg ist.

Überprüfe die Registrierung mit codex mcp get cronometer-personal oder claude mcp get cronometer-personal. Anthropics aktuelle MCP-Anleitung für Claude Code erklärt seine Konfigurationsbereiche und die Berechtigungsregeln, die für MCP-Werkzeuge gelten. Codex verwendet dieselbe MCP-Konfiguration für seine CLI und IDE-Erweiterung; siehe OpenAIs MCP-Dokumentation.

Dies als Desktop-Erweiterung (.mcpb/.dxt) zu verpacken, würde den Schritt der manuellen Bearbeitung entfernen, aber ein Erweiterungsbündel müsste auch die Anmeldeabfrage und die Python-Umgebung mitführen. Das ist nicht gebaut; die Launcher-plus-Konfigurations-Route oben ist das, was dieses Repository unterstützt.

Grenze von Anmeldeinformationen und Netzwerk

• scripts/run-mcp.ps1 entschlüsselt das DPAPI-geschützte Passwort und übergibt es dem Server über Umgebungsvariablen. Sei dir darüber im Klaren, was das kostet: Der Launcher läuft so lange wie die MCP-Sitzung, und während er läuft, ist das Klartext-Passwort in der Umgebung von drei Prozessen vorhanden — dem Launcher, Node und dem Python-Kindprozess. Es wird niemals im Klartext auf die Festplatte geschrieben, niemals auf eine Befehlszeile gesetzt und niemals in einer MCP-Konfigurationsdatei gespeichert, aber jeder Prozess, der als dieser Windows-Benutzer läuft, könnte es lesen. Das ist der Handel, um kein Passwort in eine Konfigurationsdatei tippen zu müssen.

• Der Python-Kindprozess ersetzt die vorhandene ausführbare Pickle-Sitzung durch JSON mit Größenprüfung und speichert sie im privaten Anwendungsdatenverzeichnis. Unter Windows ist dieses Verzeichnis durch eine ACL geschützt, die das Setup-Skript anwendet: Vererbung unterbrochen, eine einzelne Zugriffsregel für dein eigenes Konto und kein Eintrag für SYSTEM oder die Administratorengruppe. Zwei Schichten schützen es, und sie prüfen verschiedene Dinge. Der Launcher liest die tatsächliche ACL bei jedem Start und weigert sich zu laufen, wenn das Verzeichnis vererbbar geworden ist oder eine andere Identität hinzugewonnen hat. Die Python-Brücke kann ohne zusätzliche Pakete keine Windows-ACL lesen, also weigert sie sich nur zu laufen, wenn CRONOMETER_DATA_DIR nicht gesetzt ist — genug, um zu verhindern, dass das Sitzungscookie auf einen ungeschützten Standard im Home-Verzeichnis zurückfällt, aber keine Prüfung der Berechtigungen selbst. Wenn du den Server auf andere Weise als über den Launcher startest, erhältst du die schwächere der beiden.

• Die Netzwerksitzung akzeptiert nur HTTPS-Anfragen, deren exakter Host cronometer.com ist, einschließlich Weiterleitungen. Proxy- und Zertifikat-Umgebungsvariablen werden nicht an den Kindprozess weitergegeben, sodass ein maschinenweiter Proxy sich nicht dazwischenschalten kann.

• Aufrufe werden serialisiert, Daten und Kennungen werden zweimal validiert, und jedes Werkzeugergebnis über 2 MB wird abgelehnt, anstatt stillschweigend abgeschnitten zu werden — frag einen kürzeren Datumsbereich ab.

• Lebensmittelnamen, Notizen, Website-Fehler und alle anderen Live-Texte werden innerhalb einer expliziten Grenze für nicht vertrauenswürdige Daten zurückgegeben, JSON-kodiert, sodass der Text das Ende dieser Grenze nicht fälschen kann. Sie dürfen niemals als Anweisungen behandelt werden.

Nützliche Werkzeuge

Die 32 MCP-Werkzeuge sind konzeptionell wie folgt gruppiert:

• Verbindung: Status- und Verbindungsprüfung.

• Heruntergeladene Exporte: Liste sie auf und führe die abdeckungsbewusste Nährstoffanalyse über einen aus. Diese lesen einen Ordner auf diesem Computer und berühren niemals das Netzwerk.

• Tagebuch: Lebensmittelprotokoll, Bewegung, Biometrieverlauf, Notizen, abdeckungsbewusste Ernährungszusammenfassung, roher CSV-Export, Lebensmittel hinzufügen/entfernen, einen Tag kopieren und einen Tag als abgeschlossen markieren.

• Lebensmitteldatenbank: Suche und Lebensmitteldetails.

• Makros: Ziele/Zeitpläne lesen, tägliche Ziele festlegen, Vorlagen auflisten/erstellen/löschen und eine Vorlage einem Wochentag zuweisen.

• Fasten: Verlauf, Statistiken, ein Fasten löschen und ein aktives Fasten abbrechen, während seine Serie erhalten bleibt.

• Biometrie: aktuelle Werte lesen, einen Wert hinzufügen und einen Wert löschen.

• Wiederkehrende Lebensmittel: Regeln auflisten, hinzufügen und löschen.

Es gibt bewusst kein Werkzeug für beliebige GWT-Anfragen, keine Browser-Automatisierung, kein rohes SQL, keine Shell-Ausführung, keine automatische Hintergrundsynchronisation und keinen entfernten HTTP-Transport.

Entwicklungsverifikation

Alle Tests sind offline und verwenden synthetische Daten:

npm run verify      # typecheck, TypeScript, Python, and the setup scripts

Das sind 450 TypeScript-Tests, 45 Python- und 24 Setup-Prüfungen. Die einzelnen Schritte sind npm run typecheck, npm test, npm run test:python und npm run test:setup; der letzte überspringt sich lautstark, wenn PowerShell fehlt, anstatt aus einem Grund zu scheitern, der nichts mit dem geprüften Code zu tun hat.

npm test baut zuerst und prüft sowohl das alte MCP als auch den modernen 2026-07-28-Stdio-Handshake. Die Protokollsuite ruft jedes Werkzeug gegen eine Fake-Brücke auf, verifiziert Werkzeug-Berechtigungskennzeichnungen, prüft, dass jedes destruktive Werkzeug einen unbestätigten Aufruf ablehnt, stellt sicher, dass Leselogik Mutationsmethoden nicht erreichen kann, und treibt feindlichen mehrzeiligen Text durch sowohl die Erfolgs- als auch die Fehlerpfade, um zu beweisen, dass keiner das Ende der Grenze für nicht vertrauenswürdige Daten fälschen kann.

Zwei ehrliche Grenzen dessen, was diese Tests zeigen. Das generische Ausgabeschema typisiert data absichtlich als unknown, weil die Form einer Live-Antwort von Cronometer zu entscheiden ist — also ist „validiert gegen das Ausgabeschema“ nur für die Ernährungszusammenfassung eine echte Prüfung, das einzige Werkzeug mit einem vollständig spezifizierten Ergebnis. Und jeder Test ist offline: Sie beweisen, dass der Wrapper sich verhält, nicht, dass die undokumentierte Schnittstelle noch funktioniert.

Die einzige Live-Prüfung, die beiläufig ausgeführt werden sollte, ist die Verbindungsprüfung. Teste Schreibwerkzeuge nicht gegen das echte Konto, es sei denn, die beabsichtigte Kontoänderung ist selbst der Test.

Ein Hinweis zu zwei Dateien, die dieses Repository nicht enthält

Teile des Quellcodes und des Sicherheits-Audits verweisen auf CLAUDE.md und AGENTS.md. Das sind Arbeitsdateien für die KI-Assistenten, die zum Bau dieses Projekts verwendet wurden, und sie bleiben auf dem Rechner statt im Repository — sie sind an einen Assistenten geschrieben statt an einen Leser, und sie enthalten persönlichen Kontext, der sich ohne ihn schlecht liest.

Nichts Tragendes wird dadurch verborgen. Die Designregeln, die sie aufstellen, sind dort sichtbar, wo sie durchgesetzt werden: der Fehlt-versus-Null-Typ in src/domain/nutrient.ts, die Schreib-Annotationen in src/mcp/registry.ts, die Grenze für nicht vertrauenswürdige Daten in src/mcp/server.ts, die Netzwerkgrenze in python/live_bridge.py. Die Begründung dahinter steht in BUILD_PLAN.md, DATA_MODEL.md und im Sicherheits-Audit, die alle an eine Person gerichtet sind. Verweise auf die beiden fehlenden Dateien bleiben so, wie sie geschrieben sind, anstatt sie herauszuschneiden, denn gerade das Audit ist eine datierte Aufzeichnung, und ein stilles Umschreiben seiner Zitate würde es weniger vertrauenswürdig machen, nicht mehr.

Andere Plattformen

macOS ist gebaut: scripts/setup-macos.sh und scripts/run-mcp.sh spiegeln das Windows-Paar Schritt für Schritt, speichern das Passwort in der Login-Keychain statt in DPAPI und schützen das Datenverzeichnis mit Modus 700 statt mit einer ACL. Alles andere ist derselbe Code.

Um es deutlich zu sagen, wie es darum steht, denn das zählt mehr als die Behauptung:

Die Teile des macOS-Pfads, die gewöhnlicher Code sind — der Claude-Desktop-Konfigurationsschreiber, der Konfigurationsvalidator, jeder Parser — sind durch Tests abgedeckt, die bei jedem Push in CI auf macOS laufen. Was auf einem Mac nie ausgeführt wurde, ist der Teil, der einen benötigt: die Keychain-Abfrage, die Verweigerung des Verzeichnismodus und ein echtes Lesen und Schreiben. MACOS.md listet diese vier Prüfungen explizit auf und gibt an, welche am wahrscheinlichsten einen Unterschied aufdecken wird.

Linux bekommt den Launcher automatisch, da es für sein Datenverzeichnis und die Berechtigungsprüfung den Nicht-Darwin-Zweig verwendet, aber es gibt kein Setup-Skript und niemand hat ihn ausgeführt.

Herkunft und Lizenz

Die Implementierung des GWT-RPC-Protokolls entstand aus Paul Hoskins' MIT-lizenziertem cronometer-mcp 2.0.3. Sie ist jetzt eingebunden und modifiziert unter python/vendor/cronometer_client.py, anstatt von PyPI installiert zu werden, wobei sein Copyright-Hinweis wie von der Lizenz gefordert in THIRD_PARTY_NOTICES.md erhalten bleibt.

Diese Änderung wurde im August 2026 aus einem bestimmten Grund vorgenommen. Der letzte Commit von Upstream war am 8. März 2026. Bis August gab es acht offene Issues und vier nicht gemergte Pull Requests — zwei davon behoben einen durch eine Cronometer-Änderung verursachten Bruch, der die Lebensmittelsuche und damit auch die Möglichkeit, überhaupt Lebensmittel zu protokollieren, völlig lahmgelegt hatte. Eine gepinnte Abhängigkeit kann nicht gepatcht werden. Vendoring bedeutete, dass diese Fixes angewendet werden konnten, und es bedeutet, dass der nächste Bruch hier behebbar ist, statt nur anderswo meldbar zu sein.

Jede bewusste Abweichung vom Original ist im Kopf der eingebundenen Datei aufgelistet, und zwei davon sind aus öffentlichen Pull Requests anderer Mitwirkender übernommen und in den Hinweisen genannt.

Das Reverse-Engineering des Protokolls selbst ist Paul Hoskins' Arbeit und bleibt der schwierigste Teil dieses Projekts.

requests ist jetzt die einzige Laufzeitabhängigkeit, die dieses Projekt nicht selbst besitzt.

Der eigene Code dieses Projekts ist MIT-lizenziert; siehe LICENSE.