mise-en-place

Ein MCP-Server, der vertrauenswürdige Makronährstoffdaten für eine benannte Zutat in einer benannten Menge liefert, bezogen von USDA FoodData Central.

Er hat eine einzige Aufgabe: Wenn ein LLM eine Mahlzeit plant oder ein Rezept erstellt, soll er echte Kalorien/Protein/Kohlenhydrate/Fett für ein echtes Lebensmittel in einer echten Menge liefern, niemals eine plausibel klingende Schätzung. Zusammensetzung, Rezeptdesign und Arithmetik bleiben das Problem des aufrufenden Modells. Korrekte Eingaben sind das einzige Problem dieses Servers.

Was es ist

mise-en-place ist keine eigene Nährstoffdatenbank. Es ist eine Nachschlage-Ebene vor USDA FoodData Central, die so gebaut ist, dass ein LLM nach einem Lebensmittel suchen, eine Menge („1 mittlere Zwiebel“, „2 Esslöffel“, „6 oz“) in Gramm auflösen und echte, belegte Makros zurückbekommen kann, statt sich welche auszudenken. Es läuft über MCP (stdio), sodass jeder MCP-fähige Client (Claude Code, Claude Desktop oder alles andere, das das Protokoll spricht) sich direkt verbinden kann.

Acht Tools: search_foods, get_nutrition, get_nutrition_batch, save_override, save_recipe, get_recipe, get_recipe_history, list_recipes. Vollständige Signaturen und Schemas finden Sie in INTERFACES.md.

Related MCP server: Food Data Central MCP Server

So verwenden Sie es

Anforderungen: Python 3.11+, ein kostenloser USDA FoodData Central API-Schlüssel (sofortige Anmeldung).

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

Registrieren Sie es bei einem MCP-Client, z. B. 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

Starten Sie den Client neu, damit er die neue Verbindung übernimmt, und fragen Sie dann einfach nach dem, was Sie kochen. Die eigenen instructions des Servers (sichtbar in server.py's _SERVER_INSTRUCTIONS) reisen mit der Verbindung und sagen dem Modell, wie es die Tools richtig verwendet, sodass nichts von Hand in den Chat eingefügt werden muss. Wenn Sie wiederkehrende Mahlzeitenplanungs-Sitzungen mit eigenen Makro-Zielen durchführen, siehe MEAL_PLANNING_PROMPT.md. Ziele sind pro Person und pro Mahlzeit, der Server speichert sie also nie; in dieser einen Datei leben sie.

Persönliche Korrekturen und gespeicherte Rezepte liegen in ~/.mise-en-place/ (MISE_HOME), niemals committet. masses.toml im Repository-Root ist die mitgelieferte, eingecheckte Standardtabelle für übliche Haushaltsmaß-Gewichte (eine mittlere Zwiebel, ein großes Ei): von Menschen geschrieben, zitiert, und es ist sicher, ihr durch Bearbeiten zu widersprechen.

Warum es verwenden

Viele „Gib mir die Kalorien“-Tools beantworten eine Frage, deren Antwort sie eigentlich nicht kennen. Dieses hier nicht:

• Erfindet niemals einen Nährwert. Wenn USDA die Zahl nicht hat, löst das Tool eine Ausnahme aus oder meldet sie explizit als fehlend, niemals eine Null und niemals eine Schätzung, die für eine Tatsache steht.

• Fällt niemals auf eine runde Zahl zurück. Eine Menge, die nicht in eine Masse aufgelöst werden kann (über USDas eigene Portionsdaten, Ihre eigenen gespeicherten Korrekturen oder die mitgelieferten masses.toml-Standardwerte), löst eine Ausnahme aus, statt auf 100g zurückzufallen oder eine Dichte zu raten.

• Jeder unsichere Wert sagt es laut. Ein Treffer mit geringer Konfidenz, ein Kandidat, bei dem das Tool nicht sicher war, eine angenommene Masse: Alles reist als strukturierter Vorbehalt zurück zum aufrufenden Modell, nicht als Zahl, die genauso selbstbewusst aussieht wie eine verifizierte.

• Korrekturen machen das Tool dauerhaft besser. save_override und save_recipe bedeuten, dass ein Fehler einmal behoben wird, nicht bei jedem zukünftigen Nachschlagen derselben Zutat neu geraten wird.

• Messbar genauer als ein Modell, das selbst rät. Ein Benchmark mit 10 Rezepten gegen handverifizierte Etikettendaten ergab einen mittleren Fehler von 4,99 % für dieses Tool, gegenüber 8,26 % für dasselbe Modell ohne Tool-Zugriff. Methodik und die aktuelle Zahl finden Sie unten.

Wie wir testen, dass das tatsächlich stimmt

Die Regel „niemals einen Wert erfinden“ ist leicht zu behaupten und leicht still zu verletzen. Zwei Dinge untermauern sie.

Live, erneut verifizierte Testdaten. Jede USDA-ID, die dieses Projekt zitiert, in masses.toml und in den Golden Values der Testsuite, wird bei jedem Lauf erneut von der echten API abgerufen und gegen das geprüft, was sie sein soll (tests/test_golden_values.py, tests/test_masses_toml.py). Ein Zitat, das veraltet ist, schlägt laut fehl, statt autoritativ dazusitzen.

Genauigkeit validiert gegen echte Produktdaten, nicht gegen die Meinung einer anderen Rezeptseite. Ein früher Genauigkeitsdurchlauf verglich die Ausgabe dieses Tools mit den veröffentlichten Nährwertangaben einer beliebten Gesundheits-Rezeptseite und stellte fest, dass das Tool bei einigen Rezepten stark abwich. Ein genauerer Blick zeigte, dass die Abweichung in die andere Richtung lief: Eine manuelle Überprüfung der schlimmsten Fälle gegen tatsächliche Produktnährwertetiketten zeigte, dass die Zahlen dieses Tools diejenigen waren, die nahe an der Realität lagen, und die der Drittanbieter-Seite die Ausreißer waren. Der Vergleich mit einer beliebigen Rezeptseite erwies sich als der falsche Test, da deren eigene Methodik undurchsichtig ist und es keine Möglichkeit gibt zu wissen, welches Produkt sie bepreist hat, welche Portionsausbeute-Konvention sie verwendet hat oder welche Nährstoffdatenbank dahintersteckt.

Der echte Genauigkeits-Benchmark, auf den dies hindeutet (tests/golden_recipes/), ist aus zwei bewusst getrennten Quellen aufgebaut: USDA-Daten für echte Rohstoffzutaten (eine Kartoffel, Kristallzucker: nichts mit einer nennenswerten Marke) und echte Produktnährwertetiketten für alles, was ein bestimmtes kommerzielles Produkt plausibel bedeutet (eine Marke von Tortillas, ein verpackter Tofu). USDA-Daten zu verwenden, um die generischen Treffer eines USDA-gestützten Tools zu validieren, wäre nur ein Check, ob es mit sich selbst übereinstimmt; Etikettendaten sind der einzige unabhängige Check, der für markenförmige Zutaten tatsächlich etwas bedeutet. Mehrere der Rezepte tragen bewusst dieselbe Zutat in zwei Formulierungen: einen generischen Namen („Tortilla-Chips“) und einen spezifischen („Mission Tortilla-Chips“), sodass der Benchmark sowohl den standardmäßigen generischen Treffer des Tools prüft als auch, ob es ein benanntes Produkt korrekt findet und bevorzugt, wenn das Rezept es beim Namen nennt.

Neuestes Ergebnis (10 Rezepte, Agent mit Tool vs. Agent mit bloßem LLM-Abruf, beide gegen dieselben handverifizierten Etikettendaten bewertet, 2026-08-21): Der mittlere absolute Fehler des Agents mit Tool über Kalorien/Protein/Kohlenhydrate/Fett betrug 4,99 %, gegenüber 8,26 % für denselben Agenten ohne Tool-Zugriff. Das Tool gewinnt bei 7 von 10 Rezepten eindeutig, entscheidend bei Rezepten mit einer wirklich schwierigen markengebundenen Zutat oder einem Fleischstück, dessen Fettgehalt leicht falsch erinnert wird (Hähnchenschenkel, Flanksteak). Die drei Rezepte, bei denen bloßes Abrufen genauso gut oder besser abschnitt, sind kein Beweis dafür, dass das eigene Matching des Tools schwach ist. Es sind Fälle, in denen das Rezept selbst eine Menge nicht zählbar ließ (eine Garnitur ohne angegebenes Gewicht), was beide Bedingungen zwang, unabhängig zu raten, und Rauschen hinzufügte, das nichts mit dem zu tun hat, was der Benchmark messen will. Siehe note_on_TC10 in tests/golden_recipes/eval_prompts.json für den einen Fall, der es wert ist, behoben zu werden, bevor man seiner Punktzahl vertraut. Diese Zahl wird sich ändern, da sich sowohl die Fixture als auch das Tool weiter verändern; behandeln Sie sie als die aktuellste Messung, nicht als dauerhaften Anspruch.

Wo Sie mehr lesen können