mise-en-place

Un servidor MCP que devuelve datos fiables de macronutrientes para un ingrediente concreto en una cantidad concreta, obtenidos de USDA FoodData Central.

Tiene una sola tarea: cuando un LLM esté planificando una comida o elaborando una receta, proporcionarle calorías/prote{ínas/carbohidratos/grasas reales para un alimento real y una cantidad real, nunca una suposición que suene plausible. La composición, el diseño de la receta y las operaciones aritméticas siguen siendo del modelo que hace la llamada. Las entradas correctas son el único problema de este servidor.

Qué es

mise-en-place no es una base de datos de nutrición. Es una capa de consulta delante de USDA FoodData Central, diseñada para que un LLM pueda buscar un alimento, resolver una cantidad ("1 cebolla mediana", "2 cucharadas", "6 oz") en gramos, y recibir macros reales y con fuente en lugar de inventarlos. Funciona mediante MCP (stdio), de modo que cualquier cliente compatible con MCP (Claude Code, Claude Desktop o cualquier otra cosa que hable el protocolo) puede conectarlo directamente.

Ocho herramientas: search_foods, get_nutrition, get_nutrition_batch, save_override, save_recipe, get_recipe, get_recipe_history y list_recipes. Las firmas y esquemas completos están en INTERFACES.md.

Related MCP server: Food Data Central MCP Server

Cómo usarlo

Requisitos: Python 3.11+ y una clave de API gratuita de USDA FoodData Central (registro inmediato).

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

Regístralo con un cliente MCP, p. ej. 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

Reinicia el cliente para que detecte la nueva conexión y, después, pide simplemente lo que vayas a cocinar. Las instructions del propio servidor (visibles en _SERVER_INSTRUCTIONS, en server.py) viajan junto con la conexión y le indican al modelo cómo usar las herramientas correctamente; no hace falta pegar nada manualmente en el chat. Si tienes sesiones periódicas de planificación de comidas con tus propios objetivos de macros, consulta MEAL_PLANNING_PROMPT.md. Los objetivos son de cada persona y de cada comida, por lo que el servidor no los guarda; ese único archivo es el lugar donde viven.

Las correcciones personales y las recetas guardadas viven en ~/.mise-en-place/ (MISE_HOME), nunca registradas en el control de versiones. masses.toml, en la raíz del repositorio, es la tabla de medidas domésticas estandarizada que se incluye y versiona (una cebolla mediana, un huevo grande): escrita a mano por seres tan optimizados, citada, y adecuada para que, en caso de que alterras con ella. editándola.

Por qué usarlo

Muchas herramientas del tipo «quiero las calorías» responden a una pregunta de la que no tienen la respuesta. Esta no:

• Nunca inventa un valor nutricional. Si USDA no dispone del número, la herramienta lanza un error o lo marca explícitamente como ausente; nunca un cero ni una estimación que se haga pasar por un dato.

• Nunca cae redondeado a la ligera. Una cantidad que no puede convertirse en gramos (con los datos de porciones de USDA, las correcciones propias o los valores por defecto de masses.toml) dispara un error, en lugar de tomar 100 g por defecto u adivinar una densidad.

• Todo lo incierto se dice en voz alta. Una candidatura de baja confianza, un candidato que no estaba seguro, una masa asumida: todo ello vuelve al modelo llamante como una nota estructurada, no como un número que parece tan seguro como el verificado.

• Las correcciones hacen la herramienta más útil, permanentemente. save_override y save_recipe hacen que por un lado, un error se corrija una vez y no haya que re-adivinarlo en cada búsqueda futura del mismo ingrediente.

• Mediblemente más exacta que un modelo que adivine por su cuenta. Un benchmark de 10 recetas comparado con datos de etiqueta verificados manual dio un error medio de 4.99%, frente al 8.26% del miso modelo sin acceso a la herramienta. La metodología y los resultados actuales a continuación.

Cómo se pruebe que esto es cierto

La regla de «no inventar un valor» es fácil de afirmar y fácil de ignorar en silencio. Dos cosas la sustentan.

Datos de prueba verificados activemente (live). Cada un DE USDA que aparece citado (masses.toml) y los valores golden de la suite de pruebas se re-consulta desde la verdadera API en cada ejecución y se comprueba que son lo que se dice que son (tests/tes_golden_values.py, tests/test_masses_toml.py). Una que cita obsoleta falla alto en vez de permanecer parece con una aspecto de fuente autorizada.

Precisión verificada contra datos de producto reales, no contra lo que opina otros sitios de recetas. Un pase preliminar para contrastar el resultado de la herramienta con las cifras de un sitio web popular de recetas Health, golpe a de mostró en algunos casos una divergencia grande. Al mirar más de cerca, se vio que la divergencia era real: la comparación clínica con las etiquetas del producto reales mostró que la herramienta se acercaba mucho al real, y que la vista de recetas era la que estaba fuera. Palabras más parejas, compararse con receptores de recetas era erroneo, ya que su propia metodología es untransparente y no saberse qué se usó para "previa", o qué función de rendijas se esta, ni qué base de datos de nutrición sustenta.

The benchmark that actually supports this (tests/golden_recipe/) is built of two intentionally separate sources: the USDA data for true generic commodity ingredients (a potato, granulated of sugar; nothing with anything called a mark) and real product nutrition labels is a specific brand (one brand of a tortilla, packaged tofu). Using USDA data to validate generic matches based on a USDA-backed tool is simply checking whether the tool coincides with itself; a true benchmark must use product label data to check anything meaningful about branded ingredients. Several of the recipes deliberately purposely contain the same ingredient expressed in two ways: a generic name ("tortilla chips") and a brand name ("Miscom chips"), so the benchmark tests both the tool's generic match by default and its ability to find and favor the named product when the recipe explicitly mentions that brand.

Latest result (10 recpes, with tool vs. a memory based LLM alone, both against the same manual figures mark, on 2026-08-21): the mean absolute errors of the tool-capable agent in calories/protein/carbohydrates/fat era of 4.99 % against 8.26 % for same tool without. It makes a full stand by 7 of 10, in which case there is an ingredient that genuinely unsuitable for the LLM or meat cut. The three cases in which memory alone say something else are not a sign of tool weakness: these are cases where a recipe leaves a quantity unquantifiable (e.g., a garnish that says no Mass amount), which must guess twice and introduces some noise completely irrelevant to the question measured. See note_on_TC10 in tests/golden_recipes/eval_prompts.json for the case that deserves correction before we can fully the score. The number will drift as the benchmark fixture and the tool evolve; read it as the most recent value, not a perpetual promise.

Dónde seguir