Personal Cronometer MCP

これは、Cronometer と Codex や Claude Code などの MCP クライアントとの間をつなぐ、ローカルで動作する個人用ブリッジです。Paul Hoskins の cronometer-mcp クライアントが持つ便利なライブアカウント対応を、より厳格な TypeScript レイヤーと組み合わせており、欠落した栄養データを保持し、アカウントを変更する操作に正直なラベルを付け、認証情報を MCP 設定ファイルに保存しません。

これは、NASM 公認スポーツ栄養コーチ (CSNC) であり、専攻外で大学レベルの栄養学の講義も受けた人物による個人学習プロジェクトです。その経歴がプロジェクトの優先順位に影響を与えていますが、このソフトウェアは医療機器ではなく、医療ケアの代替でもありません。

固定されたクライアントがサポートする完全なライブアクセスを提供します。食事記録の読み書き、カバレッジ対応の栄養素サマリー、生 CSV エクスポート、食品検索、マクロ目標とスケジュール、断食記録、バイオメトリクス、日のコピー/完了、繰り返し食品などです。

重要な制限

• これは非公式の個人用ツールです。Cronometer はこのインターフェースを提供もサポートもしていません。Cronometer の Web サイトの変更により予告なく動作しなくなる可能性があり、自動アクセスはアカウントを危険にさらす可能性があります。有効にする前に、Cronometer の現在の利用規約をお読みください。

• CSV エクスポート機能の中には Cronometer Gold が必要な場合があります。Cronometer はサポートされている手動エクスポートの手順をアカウント設定: データエクスポートで説明しています。

• これは、記録された内容と記録の完全性を報告します。医療機器ではなく、栄養素欠乏を診断するものではなく、医学的助言を提供するものでもありません。

• ローカルに保ちます。このプロジェクトは意図的に、HTTP サーバー、リモートデプロイモード、テレメトリ、任意のコード実行ツールを一切持っていません。

栄養サマリーがより安全な理由

Cronometer の日次サマリーには微妙な罠があります。空の栄養素セルは「データなし」を意味し、表示されたゼロは記録されたゼロを意味します。Total 行は欠落したセルをゼロに潰してしまうことがあります。このサーバーはダイアリーグループの行を自ら解析し、すべての栄養素のカバレッジを計算し、要求されたカバレッジしきい値を満たした場合にのみ摂取量の値を返します。デフォルトのしきい値 1 では、その栄養素のダイアリーグループのすべてのセルにデータが含まれている必要があります。

したがって、栄養素の結果は次の 2 つの形式のいずれかになります。

• kind: "value" — 値、単位、グループカバレッジ、日次カバレッジ、Cronometer の Total との比較を含みます。

• kind: "insufficient-data" — カバレッジと、明示的に名前が付けられた下限値 observedSubtotal を含みますが、その小計を摂取量として表すことはできません。

その区別は、CSV 解析から最終的な MCP 出力まで維持されます。

すべてのダイアリー読み取りは上流ではなくここで解析されます

固定されたクライアントは csv.DictReader で CSV を読み取り、型のない文字列の行を返します。これは輸送手段としては問題ありませんが、あなたのダイアリーのモデルとしては役に立たないため、このサーバーはそれを使用しません。代わりに、cronometer_get_food_log、cronometer_get_exercises、cronometer_get_biometric_log、cronometer_get_notes はそれぞれ生のエクスポートを取得し、ここで解析します。これによって得られるもの:

• 1.00 container - each 5.3 oz は、後で推測する文字列ではなく、数量と単位として返されます。

• 空の運動時間はゼロ分ではなく、欠落として報告されます。

• 単位はアカウントに表示されている通りに保たれます。何も変換されません。

• 読み取れない行は破棄され、ファイルと行番号とともに報告されるため、短いリストが黙って短くなることはありません。

• 記録されなかった時間は null であり、午前 0 時になることはありません。

意図的な拒否の 1 つを知っておく価値があります。Cronometer のエクスポートがこのサーバーが必要とする列を失った場合、パーサーはゼロ行を返すでしょう。これは、あなたが記録しなかった日とまったく同じに見えます。それをそのまま返す代わりに、呼び出しは失敗し、欠落している列を指名します。ここでの空の回答は、存在しない栄養素をゼロと読み取るのと同じ種類の誤りになります。

同じルールが、CSV を経由しないライブ読み取りにも適用されるようになりました。それらの 1 つがコネクタが認識しない形状で空で返された場合、結果には unverified: true が付きます — つまり「空であり、それを確認できなかった」という意味です。実際に失敗した呼び出しは代わりに例外を発生させるため、このフラグは本当に曖昧な 1 つのケース、つまりデータを指名したのにその後見つけられない応答のために予約されています。

その境界を正しくするには 2 回の試行が必要でした。最初はすべての空の結果を未検証としてフラグ付けし、要素型マーカーがないということはフォーマットが変更された可能性があると推論しました。実際の応答を確認すると逆であることがわかりました — 空のコレクションには要素がないため要素型がありません — そのため警告は正しい回答に対して発動しており、それが警告をノイズに変えていました。現在は、応答にパーサーが読み取れない何かが含まれている場合にのみ発動します。

ライブ呼び出しはまた、少なくとも 1 秒間隔でペース調整されます。回答を読んでいる間は知覚できませんが、会話とスクレイピングの違いになります。

ダイアリーを設定するときに避けるべきことが 1 つあります。ダイアリーグループに Total という名前を付けないでください。 Cronometer は独自の日次合計をグループ名と同じ列に書き込み、エクスポートでは両者を区別する方法がありません。その名前のグループは日次合計として読み取られ、合計から除外されるため、その食品はすべての摂取量の数値から黙って消えてしまいます。他の名前なら何でも問題ありません。

栄養素セルも厳密に読み取られます。セルは空であるか、単純な非負の小数でなければなりません。それ以外のもの — テキスト、桁区切り記号、負の数 — は、合計を黙って変える数値に強制変換されるのではなく、どの列と行かを示すメモとともに欠落として記録されます。

Windows セットアップ

PowerShell を開いて実行してください:

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

macOS では同等の sh scripts/setup-macos.sh があり、同じ順序で同じことを行います — そこで実証されていることとされていないことについては他のプラットフォームを参照してください。

セットアップは次のことを行います:

1. ロックされた Node 依存関係を再インストールします。

2. ハッシュ検証された 5 パッケージのロックファイルから、プライベートな Python 3.12 環境を作成または更新します (requests とその推移的依存 4 つ — プロトコルクライアントはベンダリングされており、インストールされません)。

3. サーバーをビルドし、すべてのオフラインテストを実行します。

4. Cronometer ダイアリーのタイムゾーンを尋ねます。このコンピュータでは America/New_York が推奨デフォルトです。

5. サポートされていないインターフェースの警告を表示し、ライブアクセスを有効にする前に正確な単語 ENABLE を要求します。

6. Cronometer のユーザー名とパスワードを要求します。Windows DPAPI は現在の Windows アカウントのパスワードを暗号化します。このリポジトリ、コマンドライン、Codex 設定、Claude 設定には書き込まれません。

7. インストールされている各クライアント — Codex、Claude Code、Claude Desktop — にサーバーを登録することを提案します。それぞれ個別に尋ね

• cronometer_add_biometric は 体重のみ を受け付けます。心拍数として 60 を要求すると、 60 lbs の 体重 エントリが作成されました。他の 3 つのメトリックのエンコーディングは 推測にすぎず、body_fat は weight のエンコーディングをバイト単位で共有しているため、 同じように誤って記録されます。誤ったメトリックでデータを静かに記録する書き込みは、 後で読む傾向を壊し、その兆候を示さないため、他のメトリックは拒否されます。 Cronometer アプリで記録してください。

• cronometer_set_day_complete は失敗します。Cronometer は setDayComplete メソッドを削除しました。findFoods を削除したのと同じ方法です。 ローカルでは修正できません。

ライブテスト後に修正されました。 cronometer_get_repeated_items は、food_source_id と measure_id を入れ替えて返し、曜日リストが常に空で、ダイアリーグループが 0 になることがありました。現在は、プロトコルが実際に書き込む方法 — 後ろから前へ — でレスポンスを読み取り、曜日を正しく報告します。

ダイアリーグループは null として報告されます。Cronometer がそれを返さないためです。異なる グループで作成された 2 つのルールは、ID、数量、曜日を除いて同一のレスポンスを返しました。ルール作成時に選択したグループは適用されますが、読み戻すことはできません。null はそれを示します。0 は実際のグループのように見えたでしょう。

一度も実行されていません。 copy_day (1日全体をコピーし、サービング ID がエクスポートから読み戻せないため、きれいに元に戻せません)、set_macro_targets と set_macro_schedule_day (Cronometer はプロフィールから推奨ターゲットを計算し、これらを設定するとその計算を上書きします — テストとして行うべきものではありません)、および 2 つのファスティングツール (create-fast ツールがないため、削除またはキャンセルするものがありません)。

書き込みの安全性

読み取りツールと書き込みツールは意図的に分離されています。アカウントを変更するすべてのツールは読み取り専用ではないとマークされ、破壊的とマークされたすべてのツールは、confirm: true が存在しない限り呼び出しを拒否します。

承認はクライアントごとに異なるため、各場所で得られるものを正確に示します。

Claude Code のケースが強力です。なぜなら、その要件は後で変更するかもしれない設定ファイルにではなく、ツール自体に付随するからです。他のものはクライアント設定に依存します。セットアップスクリプトは Codex の設定を設定し、できなかった場合は大声で知らせます。古い Claude Code バージョンはフラグを無視して通常の権限処理にフォールバックします。他の MCP クライアントも同様です。未知の _meta キーは無害なので、無条件に送信されます。

読み取りツールは意図的にそのようなフラグを持ちません。しつこく確認するステータスチェックは、プロンプトを読まずにクリックして通り過ぎることを教えるだけでしょう。

書き込みは自動的に再試行されることはありません。書き込みがタイムアウトした場合、サーバーはその結果が不明であると報告します。もう一度試すかどうかを決定する前に Cronometer アプリを調べてください。そうしないと、再試行によって食品、バイオメトリクス、テンプレート、または繰り返し項目が重複する可能性があります。

手動 MCP 登録

セットアップは通常これを実行するかどうかを尋ねます。スキップした場合、コマンドにはローカルランチャーのパスのみが含まれます — 資格情報は決して含まれません。

Codex:

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

次に、%USERPROFILE%\.codex\config.toml の新しい [mcp_servers.cronometer-personal] セクション内に次の行を追加します:

default_tools_approval_mode = "writes"

Claude Code (すべてのプロジェクトで Windows ユーザーが利用可能):

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

Claude Desktop には登録コマンドがありません。%APPDATA%\Claude\claude_desktop_config.json の mcpServers オブジェクトにこれを追加し、既存のサーバーを維持してから Desktop を再起動します:

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

このマシンの pwsh.exe への実際のパスを使用してください — (Get-Command pwsh).Source で表示されます。編集する前にファイルをバックアップしてください。サーバーリストだけでなく Claude Desktop 自身の設定も保持しており、編集を誤ると失われます。セットアップスクリプトはそのすべてを代行してくれるので、そちらの方が良い方法です。

登録を確認するには、codex mcp get cronometer-personal または claude mcp get cronometer-personal を使用します。Anthropic の現在の Claude Code MCP ガイド は、その設定スコープと、MCP ツールに適用される 権限ルール を説明しています。Codex は CLI と IDE 拡張機能で同じ MCP 設定を使用します。OpenAI の MCP ドキュメント を参照してください。

デスクトップ拡張機能 (.mcpb/.dxt) としてパッケージ化すれば手動編集の手順は不要になりますが、拡張機能バンドルには資格情報プロンプトと Python 環境も含める必要があります。それは構築されていません。上記のランチャーと設定のルートが、このリポジトリがサポートする方法です。

資格情報とネットワーク境界

• scripts/run-mcp.ps1 は DPAPI で保護されたパスワードを復号化し、環境変数を介してサーバーに渡します。その代償を明確にしてください。ランチャーは MCP セッションと同じだけ実行され、実行中は平文パスワードが 3 つのプロセス — ランチャー、Node、Python 子プロセス — の環境に存在します。平文でディスクに書き込まれることも、コマンドラインに置かれることも、MCP 設定ファイルに保存されることもありませんが、この Windows ユーザーとして実行されているプロセスはそれを読み取ることができます。設定ファイルにパスワードを入力しないためのトレードオフです。

• Python 子プロセスは、既存の実行可能 pickle セッションをサイズチェック済みの JSON に置き換え、プライベートなアプリケーションデータディレクトリに保存します。Windows では、そのディレクトリはセットアップスクリプトが適用する ACL によって保護されています。継承が切断され、自分のアカウントに対する単一のアクセスルールがあり、SYSTEM や administrators グループのエントリはありません。2 つの層がそれを保護し、それぞれ異なるものをチェックします。ランチャーは起動のたびに実際の ACL を読み取り、ディレクトリが継承可能になったり、他の ID が追加されたりした場合、実行を拒否します。Python ブリッジは追加パッケージなしでは Windows ACL を読み取れないため、CRONOMETER_DATA_DIR が未設定の場合にのみ実行を拒否します。これは、セッションクッキーが保護されていないホームディレクトリのデフォルトにフォールバックするのを防ぐには十分ですが、権限自体のチェックではありません。ランチャー以外の方法でサーバーを起動すると、2 つのうち弱い方になります。

• ネットワーキングセッションは、リダイレクトを含め、正確なホストが cronometer.com である HTTPS リクエストのみを受け付けます。プロキシと証明書の環境変数は子プロセスに渡されないため、マシン全体のプロキシが介在することはできません。

• 呼び出しは直列化され、日付と識別子は 2 回検証され、2 MB を超えるツール結果は黙って切り捨てられるのではなく拒否されます — より短い日付範囲を要求してください。

• 食品名、メモ、ウェブサイトのエラー、その他すべてのライブテキストは、明示的な非信頼データ境界内で返され、テキストがその境界の終わりを偽造できないように JSON エンコードされます。それらは決して命令として扱われてはなりません。

便利なツール

32 個の MCP ツールは概念的に次のようにグループ化されています:

• 接続: ステータスと接続チェック。

• ダウンロード済みエクスポート: 一覧表示し、1 つに対してカバレッジを考慮した栄養分析を実行します。これらはこのコンピューター上のフォルダーを読み取り、ネットワークには触れません。

• ダイアリー: 食事ログ、運動、バイオメトリクス履歴、メモ、カバレッジを考慮した栄養サマリー、生 CSV エクスポート、食品の追加/削除、日付のコピー、日付の完了マーク。

• 食品データベース: 検索と食品詳細。

• マクロ: ターゲット/スケジュールの読み取り、毎日のターゲット設定、テンプレートの一覧表示/作成/削除、およびテンプレートの曜日への割り当て。

• ファスティング: 履歴、統計、ファストの削除、およびシリーズを維持したままアクティブなファストのキャンセル。

• バイオメトリクス: 最近の値の読み取り、値の追加、値の削除。

• 繰り返し食品: ルールの一覧表示、追加、削除。

任意の GWT リクエストツール、ブラウザ自動化、生 SQL、シェル実行、自動バックグラウンド同期、またはリモート HTTP トランスポートは意図的にありません。

開発検証

すべてのテストはオフラインで、合成データを使用します:

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

これは 450 件の TypeScript テスト、45 件の Python、24 件のセットアップチェックです。個々の手順は npm run typecheck、npm test、npm run test:python、npm run test:setup です。最後のものは、PowerShell がない場合、チェック対象のコードとは無関係な理由で失敗するのではなく、大声で自分自身をスキップします。

npm test は最初にビルドし、レガシー MCP と最新の 2026-07-28 stdio ハンドシェイクの両方をチェックします。プロトコルスイートは、フェイクブリッジに対してすべてのツールを呼び出し、ツールの権限ラベルを検証し、破壊的ツールが確認なしの呼び出しを拒否することをチェックし、読み取りハンドラーが変更メソッドに到達できないことを保証し、悪意のある複数行テキストを成功パスとエラーパスの両方に通して、どちらも非信頼データ境界の終わりを偽造できないことを証明します。

これらのテストが示すことには、正直な 2 つの限界があります。一般的な出力スキーマは、ライブレスポンスの形状は Cronometer が決めるものなので、意図的に data を unknown として型付けしています。したがって、「出力スキーマに対する検証」が実際のチェックとなるのは、完全に指定された結果を持つ唯一のツールである栄養サマリーだけです。また、すべてのテストはオフラインです。つまり、ラッパーが動作することを証明するだけで、文書化されていないインターフェースがまだ機能することを証明するものではありません。

気軽に実行できる唯一のライブチェックは接続チェックです。意図したアカウント変更自体がテストである場合を除いて、実際のアカウントに対して書き込みツールをテストしないでください。

このリポジトリに含まれない 2 つのファイルについての注記

ソースとセキュリティ監査の一部は CLAUDE.md と AGENTS.md を参照しています。これらはこのプロジェクトの構築に使用された AI アシスタント用の作業ファイルであり、リポジトリではなくマシン上に置かれます。それらは読者ではなくアシスタント に 向けて書かれており、個人の文脈を含んでいるため、それを取り除くと読みにくくなります。

それによって重要なものが隠されているわけではありません。そこで述べられている設計ルールは、それが適用されている場所で確認できます。src/domain/nutrient.ts の欠落対ゼロ型、src/mcp/registry.ts の書き込み注釈、src/mcp/server.ts の非信頼データフェンス、python/live_bridge.py のネットワーク境界です。それらの背後にある推論は BUILD_PLAN.md、DATA_MODEL.md、およびセキュリティ監査にあり、すべて人に向けられています。存在しない 2 つのファイルへの参照は、削除するのではなく、書かれたまま残されています。特に監査は日付のある記録であり、引用を静かに書き換えると、より信頼できなくなるからです。

他のプラットフォーム

macOS も構築されています。scripts/setup-macos.sh と scripts/run-mcp.sh は Windows のペアをステップごとにミラーリングし、DPAPI の代わりにログイン Keychain にパスワードを保存し、ACL の代わりにモード 700 でデータディレクトリを保護します。その他はすべて同じコードです。

その状態について率直に述べます。なぜなら、それは主張よりも重要だからです：

macOS パスのうち通常のコードである部分 — Claude Desktop 設定書き込みプログラム、設定バリデーター、すべてのパーサー — は、プッシュのたびに CI で macOS 上で実行されるテストでカバーされています。Mac 上で一度も実行されたことがないのは、Mac を必要とする部分、つまり Keychain プロンプト、ディレクトリモードの拒否、そして実際の読み取りと書き込み 1 回分です。MACOS.md はこれら 4 つのチェックを明示的に列挙し、どれが最も違いを明らかにしやすいかを示しています。

Linux は、データディレクトリと権限チェックで non-Darwin ブランチを取るため、ランチャーを追加作業なしで利用できます。ただし、セットアップスクリプトはなく、誰も実行していません。

由来とライセンス

GWT-RPC プロトコルの実装は、Paul Hoskins の MIT ライセンスの cronometer-mcp 2.0.3 として始まりました。現在は PyPI からインストールされるのではなく、python/vendor/cronometer_client.py に ベンダリングされ修正されています。ライセンスが要求するとおり、彼の著作権表示は THIRD_PARTY_NOTICES.md に保持されています。

その変更は、特定の理由により 2026 年 8 月に行われました。アップストリームの最後のコミットは 2026 年 3 月 8 日でした。8 月の時点で、8 件のオープンな issue と 4 件のマージされていない pull request がありました。そのうち 2 件は、食品検索を完全に壊し、それとともに食品を記録する機能そのものを壊していた Cronometer の変更を修正するものでした。固定された依存関係にはパッチを当てることができません。ベンダリングはそれらの修正を適用できることを意味し、また、次に壊れた場合も、他の場所で報告するだけでなく、ここで修正できることを意味します。

オリジナルからの意図的な違いはすべて、ベンダリングされたファイルのヘッダーに列挙されています。そのうち 2 つは他の貢献者による公開 pull request から採用されたもので、通知にクレジットが記載されています。プロトコルのリバースエンジニアリング自体は Paul Hoskins の作業であり、このプロジェクトの最も困難な部分であり続けています。

requests は現在、このプロジェクトが所有していない唯一の実行時依存関係です。

このプロジェクト自身のコードは MIT ライセンスです。LICENSE を参照してください。