mise-en-place

USDA FoodData Central を情報源とし、指定された食材・指定された分量に対して、信頼できるマクロ栄養素データを返す MCP サーバーです。

このサーバーの仕事はただ一つです。LLM が食事を計画したりレシピを組み立てたりするとき、実在の食品・実在の分量に対する、実際のカロリー・タンパク質・炭水化物・脂質を返します。もっともらしい推測を返すことは絶対にありません。食材の構成やレシピ設計、計算処理は、呼び出し元のモデルの問題です。正しい入力を返すことが、このサーバーの唯一の存在意義です。

これは何か

mise-en-place は、独自の栄養データベースではありません。USDA FoodData Central の前面に位置するルックアップ・レイヤーで、LLM が食品を検索し、「中玉ねぎ1個」「大さじ2」「6オンス」といった数量をグラムに解決して、でっち上げではなく出典のある本当のマクロ栄養素データを取得できるように設計されています。MCP（stdio）上で動作するため、MCP 対応クライアント（Claude Code、Claude Desktop、その他プロトコルを話せるクライアント）ならどれからでも直接接続できます。

ツールは8つあります：search_foods、get_nutrition、get_nutrition_batch、save_override、save_recipe、get_recipe、get_recipe_history、list_recipes。完全なシグネチャとスキーマは INTERFACES.md にあります。

Related MCP server: Food Data Central MCP Server

使い方

要件： Python 3.11+、無料の USDA FoodData Central API キー（登録後にすぐ取得できます）。

git clone <this repo>
cd mise-en-place
uv sync   # or: pip install -e .
export USDA_API_KEY=<your key>

MCP クライアント（例：Claude Code）に登録します：

claude mcp add mise-en-place -s local -e USDA_API_KEY=<your key> -- \
  uv run --directory /path/to/mise-en-place mise-en-place

クライアントを再起動して新しい接続を認識させたら、あとは作りたいものを尋ねるだけです。サーバー自身の instructions（server.py の _SERVER_INSTRUCTIONS で確認できます）は接続とともに配信され、モデルにツールの正しい使い方を指示します。したがって、チャットに手動で貼り付ける必要は一切ありません。自分のマクロ栄養素ターゲットを使って定期的な食事計画セッションを行う場合は、MEAL_PLANNING_PROMPT.md を参照してください。ターゲットは人ごと・食事ごとに異なるため、サーバーが保存することはありません。そのファイルにのみ存在します。

個人の perg修正・調整や保存済みレシピは ~/.mise-en-place/（MISE_HOME）に置かれ、コミットされることはありません。リポジトリのルートにある masses.toml は、出荷時に同梱されチェックインされている既定のキッチン計量重量表（中玉ねぎ1個、卵1個など）です。人間が書き、出典が明示され、編集することで異議を唱えられる内容になっています。

使う理由

「カロリーを教えて」系のツールは、実際には答えを知らない質問に対して答えを返すことがよくあります。この サーバーはそうではありません：

• 栄養値をでっち上げることは絶対にありません。 USDA がその数値を持っていない場合、ツールはエラーを出すか、明示的に「存在しない」と報告します。ゼロをごまかしとして返すことも、事実の代わりに推定値を返すこともありません。

• 丸め数にフォールバックすることはありません。 分量をグラムに解決できない場合（USDA 自身のポーション用データ、自分で保存した修正、同梱の masses.toml の既定値のいずれでも駄目な場合）は、100g を控えめに適用したり密度を推測するのではなく、エラーを発生させます。

• 不確かな値は、その都度はっきりと伝えられます。 低い信頼度のマッチ、確信が持てなかった候補、推定された質量 — これらはすべて、検証済みの値と同じ程度に自信ありげに見える数値としてではなく、構造化された注意書きとして呼び出し元モデルに返されます。

• 修正はツールを恒久的に改善します。 save_override と save_recipe は、同じ食材の将来のすべての検索で再推測するのでなく、失敗を一度だけ修正すれば済むようにします。

• モデルが単独で推量するよりも測定可能なかぎり正確です。 手で検証したラベルデータに対する10レシピ atベンチマークでは、Tool の平均誤差は 4.99%: 一方同じ モデルでツールを使わない場合の 8.26% となりました。方法論と現状数値は下記のとおりです。

それが実際に本当であることをどうテストしているか

「値をでっち上げない」というルールは、主張するのもかんたん、静かに破るのもかんたんです。それを支えるものが2つあります。

ライブで再検証されるテストデータ。 masses.toml とテストスイートのゴールデン値の中でこのプロジェクトが引用するすべての USDA ID は、実行のたびに毎回実際の API から再取得され、その ID が主張したものと一致を検証します（tests/test_golden_values.py、tests/test_masses_toml.py）。古くなってしまった引用は、権威し出してそのまま残るのではなく、大きなエラーとして明示的に失敗します。

単なる別のレシピサイトの意見ではなく、実際の製品データと照合して精度を検証しています。 初期の精度確認パスでは、このツールの出力を、人気のある健康レシピサイトの公開栄養数値と比較しました。すると、いくつかのレシピで大きなずれが見つかりました。よ适 して詳しく調べてみると、ずれは逆向きでした。最悪のケースを実際の商品栄養ラベルと手作業で照合すると、このツールの数値が実際に近く、サードパーティのサイトの値が異常値だったのです。つまり、レシピサイトとの比較はそもそも間違ったテストでした。そのサイトの方法論は不透明で、どの商品を対象にしたのか、どんな出来上がり量の制約を採用したのか、背後にどんな栄養データベースがあるのかを知る術がなかったからです。

その結果として構築した本当の精度ベンチマーク（tests/golden_recipes/）は、意図的に分離した2つのソースから作られています。真正のコモディティ食材に対する USDA データ（ジャガイモ、グラニュー糖など、ブランドと呼べるものがないもの）、そして特定の商業商品が plausible に意味があるものに対する実際の商品栄養ラベルデータ（あるブランドのトルティーヤ、パッケージ入り豆腐など）です。USDA をバックにしたツールの一般的な一致を USDA データで検証しても、それは自分自身と一致しているか確認しているだけです。ラベルデータだけが、ブランド化された食材に対して実際に意味のある独立した検証です。このテストのいくつかのレシピには同じ食材が意図的に二つの言い方で含まれています：一般的な名前（"tortilla chips"）と特定の名前（"Mission tortilla chips"）。これにより、ベンチマークはツールの既定の汎用一致と、レシピが名前で商品を要求したときに正しく検索して優先するか、その両方をチェックします。

最新の結果（レシピ10件、ツール装備エージェント vs ツールなしLLM記憶エージェント。両者同じ人為検証済みラベルデータでスコアした、2026-08-21）： ツール装備エージェントのカロリー/タンパク質/炭水化物/脂質の平均絶対誤差は 4.99% に対して、ツールなしの同じエージェントは 8.26% でした。ツールは10レシピ中7個で優勢で、特にブランド名を調べるのが本当に難しい食材や、脂肪分を間違えて覚えやすい肉cut（鶏もも肉、スカートステーキなど）を含むレシピでは明らかに強いです。無粋な記憶法が同じくらいかそれ以上に優れていた3つレシピは、ツール自体のマッチングが弱いという証拠ではありません。これらは、レシピそのものが「はっきりと数えることができない」数量（重量が指定されていない飾りなど）を殊更に残していて、結果として両条件が余計な推測を強いられベンチマーク全体に無関係なノイズが混入したケースです。そのスコアを当てにする前に注意をすべき1件は、tests/golden_recipes/eval_prompts.json の note_on_TC10 を参照してください。この数値は、フィクスチャとツールの両方が変化し続けるため drift します。恒久的な主張ではなく、現時点での「値」としてください。

さらに詳しく読むには