只读 MCP + 确定性求解：我把点餐算成了一张可复制的点单卡

先说结论

麦当劳官方 MCP 的 calculate-price 返回的整数分，是这一餐唯一可信的价格。菜单里的展示价可能带条件（discountType 如「随单购麦金卡优惠」），条件不成立时两者会差很多。

我这个项目只做一件事：把「说一句预算和口味」变成「一个答案 + 一张能照着点的单子 + 一个能复算的省钱数字」。不领券、不下单、不支付。

一、价格为什么只认 calculate-price

官方 query-meals 返回的菜单项里有 currentPrice / originalPrice / discountType / canWithOrder。实测过一个真实例子：某套餐菜单展示价 ¥32.00，discountType 是「随单购麦金卡优惠」，calculate-price 给出的核价是 ¥58.50——因为那个价需要随单购买一张卡。

所以工程上的铁律是：

• 金额只用 calculate-price 的整数分，不做浮点运算；
• 展示价只作参考，且必须把条件一起输出（display_price_cents / display_price_condition / display_price_note）；
• 展示价与核价不一致时，明确说明差额来自条件未生效。

二、一次核价的完整数据流

query-nearby-stores   选门店（不做自动换店）
      ↓
query-meals           当次菜单：确认候选商品在售
      ↓
query-meal-detail     套餐三轮结构：主食 / 小食 / 饮料
      ↓
calculate-price       每个候选逐份核价 → 整数分
      ↓
list-nutrition-foods  营养（按单品加总；未知就是未知，不当 0）

三个约束我没有让步：

1. 门店必须由用户确认：门店关闭（官方业务码 600057）时直接停止，不自动换店、不用演示数据顶替。
2. 套餐结构不能猜：query-meal-detail 必须是已核对的三轮结构，选项变化就停止并提示重新检查。
3. 营养数据缺失按未知处理：不让"缺数据"变成"0 mg 钠"，否则排序会骗人。

三、决策：约束先于排序

决策不是"打分求和"，而是两步：

1. 硬约束筛选：完整一餐（主食 + 小食 + 饮料）、口味、糖/冰、预算、营养上限；
2. 在可行集里比较：输出谁在价格/钠/能量/蛋白上被谁"非支配"比下去——也就是"为什么不是它"。

这样能给出可核对的解释，而不是一个看不懂的分数。没有满足条件的候选时，不硬凑：直接说没有，并给出"保持其他条件不变，最低需要多少钱"的预算阶梯。

省钱数字也必须可复算：基线只能是同店的另一条点法（例如"单品直选"），且基线篮子里的每件商品都要能单独核价——否则不算。实测例子：同样的巨无霸 + 中薯条 + 可乐中杯，单品直选 ¥48.50，三件套 ¥36.50，省 ¥12.00（24.7%）。

四、工程纪律

• 只读白名单：calculate-price、query-*、list-nutrition-foods、order-list 等读工具可调；下单、领券、兑换、地址写入、抽奖一律拒绝。
• 失败即停：实时查询失败就停，不拿历史快照冒充实时价。
• 零第三方依赖：纯 Python 标准库。
• 跨语言契约：网页端 JS 与 Python 实现同一套决策规则，用 24,192 组场景做逐字一致性校验（含默认答案、理由文案、点单卡文本）。

五、产出长什么样

这顿就它了 👇
  巨无霸三件套 · 套餐（巨无霸 + 中薯条 + 可乐中杯）
  ¥36.50   （门店）· 到店自取
  比「单品直选」省 ¥12.00（24.7%）

点单卡（可复制）
  门店：… · 到店自取
  1. 巨无霸   2. 中薯条   3. 可乐中杯
  合计：¥36.50
  以上只是记录你的选择；没有下单、没有支付。

六、体验与代码

• 免登录体验（历史快照）：https://polaris-smart.github.io/mcd-agent-gourmet/
• 仓库（Python 零依赖 + WorkBuddy Skill）：https://github.com/polaris-smart/mcd-agent-gourmet

本作品为 M-CODE 2026 参赛作品，非麦当劳官方产品。所有金额来自麦当劳官方 MCP 的 calculate-price，示例为历史核价快照，实际购买请以当次核价为准。