plate-cost

一个MCP 应用，用于计算食谱成本和菜单定价——一个交互式计算器，模型打开它而不是自己进行算术运算。

问 Claude "帮我给我的印尼炒饭定价"，你会得到一个可用的电子表格：食材行、采购价格、损耗百分比、份量产出、利润率滑块。改动一个数字，所有内容都会重新计算。按下 Use these numbers，模型会继续对话，使用你输入的数值，而不是它自己编造的数值。

基于 MCP Apps（ext-apps）构建。

运行在 ext-apps 的 basic-host 参考宿主中——不是 Claude。模型提出了食谱，组件加载了它，而 "Use these numbers" 将修正后的数值发送回对话中。

为什么这是应用而不是工具

成本计算是探索，不是提问。在你调整份量大小并观察利润率变化之前，你不会知道自己想要什么答案。聊天对此是一个糟糕的界面，而模型在脑子里做算术更糟——LLM 在多步数值计算上不可靠，但在听起来很确定这件事上却完全可靠。

所以分工是：组件捕获输入，服务器做数学计算，模型负责对话。

Related MCP server: TradingCalc MCP Server

有趣的部分：知道数字来自哪里

MCP Apps 有一个未解决的问题——ext-apps#746：来自组件的 tools/call 和模型决定发起的调用在服务器端无法区分。对大多数工具来说这无关紧要。但对成本计算工具来说，它决定了你是在做算术还是在洗白一个猜测。

mcp-app-attest 解决了这个问题——从本仓库中提取出来，本仓库是它的第一个使用者。服务器每次提供应用资源时都会铸造一个短期令牌并将其替换到文档中；组件在每次调用时通过 _meta 将其回显。模型永远不会看到资源主体，因此无法生成令牌。无论哪种方式，调用都会得到响应——响应会说明它收到的是哪一种：

{ "perPortion": 3300, "inputsFrom": "model" }

当数字来自模型时，文本回复会说明这一点：

注意：这些数字来自模型，而非计算器。在依赖这些数字之前，请与用户确认采购价格。

[provenance] inputsFrom=model  reason=missing  meta=null
[provenance] inputsFrom=app    meta={..."io.platecost/app-attestation":"XfqGVAiP…"}

这不是什么。 不是授权，也不是人类输入过任何内容的证明。它区分的是代码路径，而非身份。如果宿主将资源文本复制到模型上下文中，模型就能读取令牌——这里没有任何机制阻止这一点，这是宿主需要遵守的约定。被攻破的组件可以发送任何它想要的内容。把它视为"输入到我的表单中"和"由语言模型生成"之间的区别，这正是 #746 所要求的。

它后来被提取到 mcp-app-attest 中，该项目改用签名令牌而非存储令牌——原因见下面的"什么没起作用"说明。

这个领域搞错的两件事

两者都在 src/costing.ts 中，两者都有测试。

损耗意味着买更多，而不是用更多。 成本是 used / (1 - wastePct)，而不是 used * (1 + wastePct)。在 50% 损耗时你要买双倍，而不是一点五倍。天真的版本低估了你拥有的每一种需要修整的食材。

利润率（margin）和加价率（markup）是不同的数字。 利润率是 (price - cost) / price；加价率是 (price - cost) / cost。60% 的加价率是 37.5% 的利润率，而 60% 的利润率需要 150% 的加价率。priceForMargin 接受利润率——这就是厨房里"我们要 65%"的意思——并返回两者，这样差距是可见的而不是被假设的。

还处理了：质量和体积族内的单位转换，跨族转换会被拒绝（kg → l 需要你未提供的密度）、每种食材的成本占比，以及按份而非按批次分摊的间接费用。

试试看

npm install
npm run build      # bundles the widget to a single inlined HTML
npm test           # 21 tests
npm run dev        # widget standalone in a browser, no host

将 MCP 客户端指向 server.ts。在宿主之外，认证占位符永远不会被替换，因此调用会被标记为 model——这是诚实的答案。

什么没起作用

• 无状态的 HTTP 传输。 第一个版本为每个请求构建一个新的服务器，这对无状态工具没问题，但会悄悄破坏这个应用：认证令牌是由一个服务器实例铸造的，当组件回调时该实例已不存在，所以每次组件调用都被拒绝为 unknown。内存中的测试无法发现这一点——它们共享一个实例。只有针对真实宿主运行时才暴露了这个问题。

• 归咎于 SDK。 在发现上述问题之前，明显的嫌疑是 _meta 在传输中被剥离。事实并非如此：参考宿主通过沙箱代理完整地转发它。这值得知道，因为整个机制依赖于宿主这样做，而规范并不要求这一点。

状态

v0。两个工具（cost-recipe、price-portion），一个组件，21 个测试。

未构建：对话之间的持久化、多食谱比较，以及任何涉及 #753 / #745 中命名空间问题的事项——callServerTool 使用裸工具名，所以这在聚合器后面会出问题。这是下一个值得解决的问题，但这里没有解决。

MIT.