mise-en-place

一个 MCP 服务器，为指定名称和数量的食材返回可信的大量营养素数据，数据来源于 USDA FoodData Central。

它只有一个职责：当 LLM 在规划膳食或构建食谱时，为真实食物、真实数量提供真实的卡路里/蛋白质/碳水化合物/脂肪数据，绝不给出看似合理的猜测。成分构成、食谱设计和算术运算由调用模型自行处理。正确的输入是此服务器唯一关心的问题。

它是什么

mise-en-place 本身并不是营养数据库。它是 USDA FoodData Central 之上的一个查询层，旨在让 LLM 能够搜索食物、将数量（“1 个中等洋葱”、“2 汤匙”、“6 盎司”）解析为克数，并获得真实、有来源的宏量营养素数据，而不是凭空捏造。它通过 MCP（stdio）运行，因此任何支持 MCP 的客户端（Claude Code、Claude Desktop 或任何其他支持该协议的客户端）都可以直接连接。

八个工具：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。目标因人而异、因餐而异，因此服务器从不存储它们；该文件是它们的唯一存放位置。

个人修正和保存的食谱存放在 ~/.mise-en-place/（MISE_HOME）中，绝不会提交。仓库根目录下的 masses.toml 是随附的、已检入的默认常见家用计量重量表（一个中等洋葱、一个大鸡蛋）：由人工编写、附有引用来源，并且可以通过编辑它来安全地提出异议。

为什么使用它

很多“帮我查卡路里”的工具回答的是它们实际上并不知道答案的问题。这个工具不会：

• 绝不捏造营养素数值。 如果 USDA 没有该数据，工具会抛出错误或明确报告该数据缺失，绝不会用零或估算值来冒充事实。

• 绝不回退到整数。 无法解析为质量的数量（通过 USDA 自身的份量数据、你自己的保存修正或随附的 masses.toml 默认值）会抛出错误，而不会默认使用 100 克或猜测密度。

• 每个不确定的值都会明确说明。 低置信度匹配、工具不确定的候选结果、假设的质量：所有这些都会作为结构化警告返回给调用模型，而不是看起来与已验证数据一样可信的数字。

• 修正会让工具永久变得更好。 save_override 和 save_recipe 意味着错误只需修正一次，而不必在每次查询相同食材时重新猜测。

• 比模型自行猜测可衡量地更准确。 一个针对手工验证的标签数据的 10 个食谱基准测试显示，该工具的平均误差为 4.99%，而同一模型在无工具访问的情况下为 8.26%。方法和当前数据见下文。

我们如何验证这确实是真的

“绝不捏造数值”这条规则说起来容易，做起来也容易悄悄违反。有两件事为其提供支撑。

实时、重新验证的测试数据。 本项目引用的每个 USDA ID（在 masses.toml 和测试套件的黄金值中）都会在每次运行时从真实 API 重新获取，并对照其声称的内容进行检查（tests/test_golden_values.py、tests/test_masses_toml.py）。过时的引用会大声失败，而不是看起来权威地摆在那里。

准确性针对真实产品数据进行验证，而非另一个食谱网站的意见。 早期的一次准确性测试将该工具的输出与一个流行的健康食谱网站发布的营养数据进行了比较，发现该工具在某些食谱上存在较大偏差。进一步检查发现偏差方向相反：针对实际产品营养标签对手工检查最差的情况进行核对后，发现该工具的数据更接近现实，而第三方网站的数据才是异常值。与任何食谱网站进行比较最终被证明是错误的测试，因为其自身的方法不透明，无法知道它定价的是哪种产品、使用了哪种份量产出约定，或者背后是哪个营养数据库。

由此指向的真正准确性基准（tests/golden_recipes/）由两个刻意分开的来源构建：USDA 针对真正的商品食材的数据（土豆、白砂糖：没有品牌可言的东西），以及针对任何特定商业产品可能意味着的东西的真实产品营养标签（某个品牌的玉米片、包装豆腐）。使用 USDA 数据来验证一个 USDA 支持的工具的通用匹配，只是检查它是否与自己一致；标签数据是唯一对品牌形状食材真正有意义的独立检查。几个食谱刻意以两种方式表述相同的食材：通用名称（“玉米片”）和特定名称（“Mission 玉米片”），因此基准测试既检查工具的默认通用匹配，也检查当食谱明确要求某个命名产品时，它是否能正确找到并优先选择该产品。

最新结果（10 个食谱，配备工具的主体 vs. 仅靠 LLM 回忆的主体，两者均针对相同的手工验证标签数据评分，2026-08-21）：配备工具的主体在卡路里/蛋白质/碳水化合物/脂肪上的平均绝对误差为 4.99%，而同一主体在无工具访问的情况下为 8.26%。该工具在 10 个食谱中的 7 个上完胜，在含有真正难以处理的品牌食材或脂肪含量容易记错的肉类切块（鸡腿肉、侧腹牛排）的食谱上表现尤为突出。在裸回忆表现相当或更好的三个食谱中，这并不能证明工具自身的匹配能力弱。这些情况是食谱本身留下了无法计数的数量（没有规定重量的装饰物），迫使两种条件独立猜测，并增加了与基准测试试图衡量的内容无关的噪声。关于一个值得在信任其分数之前修复的案例，请参阅 tests/golden_recipes/eval_prompts.json 中的 note_on_TC10。这个数字会随着测试夹具和工具不断变化而漂移；请将其视为最新读数，而非永久声明。

更多阅读