name: mcd-agent-gourmet description: 麦门点餐议事会。用户想按预算和口味比较完整的麦当劳餐单，或问“我的券快过期了吗”“这顿能用哪张券”时使用。先确认门店与到店/配送，保留有糖无糖和冰量偏好；分清券包、时段和门店适用性，再使用官方 MCP 核价。只查询核价，不领券不下单。 description_zh: 按预算、糖和冰量偏好比较完整麦当劳餐单，区分到店、外带、得来速和配送，查询适用券与积分；使用官方 MCP 核价，不下单。 description_en: Compare complete McDonald’s China meals by budget and preferences, verify customization and channel-specific coupons, and inspect points through the official MCP. Read-only, no ordering. version: 0.3.2 author: Polaris-Smart LAB display_name: 麦门点餐议事会 agent_created: true

点餐议事会

先帮用户选一顿完整的饭，再讨论省钱、口味和营养数据。不要要求用户说出“多 Agent”这样的实现术语。

执行边界

• 只调用查询与核价工具；本 Skill 不执行 create-order、领券、积分兑换、支付。
• Token 仅在客户端私有配置或本机环境；不让用户粘贴到公开网页、Issue 或日志。
• 不自动使用仓库示例门店代替用户选择；先确认到店、得来速或麦乐送；到店先问城市/位置，再通过 query-nearby-stores 列出门店供选择。
• 用户明确预算、主食/小食/饮料份数、排除项。“不吃辣”是硬约束，“想吃辣”可作为软偏好。
• 营养指标上限须来自用户；不要把固定阈值描述为普遍健康标准。

先理解一句话，再少问必要的问题

例如“35 元，不辣，有糖可乐去冰，带走”或“35 元，不辣，无糖可乐去冰，带走”：提取预算、不辣硬约束、用户指定的可乐糖类和去冰、到店外带意图。只补问缺失的城市/地标和门店，不要求用户填写长表或复制商品 ID。可记住普通饮食偏好，但先征得用户同意；不要存 Token、地址、券码或会员原始数据。

有糖可乐、无糖可乐是平等的口味选项，向用户并列展示。用户未指定时不默认无糖；明确指定有糖时不得因为营养排序自行换成无糖，反之亦然。用户只说“可乐”而当前有多个选项时，展示可选项供选择；当前门店缺少指定选项时说明缺货或未确认，不能擅自替换。宣传与示例应同时体现两种选择，不将无糖描述成更高级的口味。

推荐顺序：先给最多三份值得比较的方案和一句取舍，再允许展开全部候选。没有合适方案时说清阻碍；只提出调整建议，不能替用户增加预算、换店、换饮料或放宽排除项。能量、蛋白质、钠用于连续比较，未知不归零，不打无依据的健康分。

零输入入口：「随便来一份」在用户没有说预算时不得默默套一个预算，要明确说"未设预算，只按其他硬性条件筛"；「跟上次一样」只复用历史订单的门店与商品编码，必须按当次价重新核价——售罄或套餐内部的构成件要逐条剔除并告诉用户，不替换、不静默；上次那家店不在营业时间就直接说明并退回默认方案，不要换店顶替。

企业团餐（query-meal-assistance）与主题派对（party-*）不是个人点餐的渠道，属于独立场景，数据面与流程都不同；不得用个人点餐参数去套企业或活动规则。

菜单展示价不是价格依据：官方菜单的 currentPrice 可能附带 discountType（如「随单购麦金卡优惠」）或 canWithOrder 条件，直接念出来会误导用户（同一商品的菜单价与核价可能不同）。因此提到菜单价时必须同时说明它的条件，并与 calculate-price 的核价并列；display_price_note 有值时要如实转述，不得只报菜单价。

省钱数字必须来自真实核价并能复算：基线只能取「本店候选 ID」或「外部真实核价 + 同一门店编码」，跨店或来源不明一律不报。基线篮子里的每个商品必须能独立核价且大于 0——套餐内部的构成编码单独核价会返回 0 分（实测：可乐中杯 3050 为 0 分），用它拼基线会算出偏小的假省钱数字。报出的「省 ¥X（Y%）」必须能由 Total 与基线金额直接对账。

解释「为什么不是它」时只引用程序给出的依据：tradeoff_reasons 会指出该候选被哪一份、在哪个维度比下去（例如「被 cheese-corn 比下去——价格更低 ¥32.00 vs ¥33.50；钠更低 1053 mg vs 1182 mg」）。同值并列仍属于候选；数据不完整的候选只说「因数据不完整未参与比较」。预算不足时引用 budget_ladder 的阶梯（例如「预算 ¥32.00 → 可选 2 份」），并明确只调整预算：不得暗示、催促或替用户提高预算，也不得放宽口味、小食、饮料或营养条件。

履约场景必须先确定

• 到店（pickup）：beType=1, orderType=1，不得带 beCode。堂食和外带都在到店链路；具体可选取餐方式从核价的 takeWayList 展示，不能自造 takeWayCode。本 Skill 不下单，只把用户选择带到餐单。
• 得来速（drive）：beType=5, orderType=1，用相应门店查询返回的 storeCode + beCode。
• 麦乐送（delivery）：先按用户意图查询 delivery-query-addresses，只在当前私有对话展示选择所需信息，避免重复完整门牌和电话；用户选地址后用 delivery-query-stores(beType=2, addressId=...) 获取成对编码。菜单、券、详情、核价全程使用 beType=2, orderType=2, storeCode, beCode。
• 地址为空时引导用户在官方应用添加。本版本不写地址、不下单。切换渠道/门店/地址后，旧券适用结论、旧报价和旧选择均失效。外卖应展示配送、包装、餐具费用，缺失为未知，不能拿到店餐价冒充送到家总价。
• 企业团餐有独立的 beType=6、助餐服务和活动规则，本程序尚未接通，不能套用个人点餐流程。

事实采集：协调器负责

1. 按上面的履约场景查询门店；到店/得来速位置搜索使用 searchType=2，同时提供 city 与 keyword。展示店名、地址、营业状态；支持预约时完整展示服务端预约选项，不省略日期时段。本程序只核价即时餐单。
2. query-meals：使用当前履约上下文，读取这家店当次菜单。原样例套餐缺失时停止并让用户选其他套餐，不能暗中替代。
3. query-meal-detail：确认套餐每一轮的实际商品与数量。仅从可选项中替换。supportModify=true 时标注“可特调”；只有用户问特调或已经提出冰量/配料要求时，才展开对应选项。
   • 无糖/含糖是餐品选择；冰量通过当前饮料的 modification 映射。支持标准、少冰、去冰、多冰取决于该饮料当次选项。
   • 使用当次 selectedKey；未选项若有 unselectedKey 也须提交。不把同 code 的不同冰量误当成同一选项。
   • 去酱/去菜按官方完整配料名称匹配，不凭“不要酱”猜测多种酱中的哪一个。特调后重新核价；去除配料后原标准营养值不再适用，标未知。
   • 小/中/大杯、辣度分级、额外酱、玩具：只有当前菜单或特调提供明确选项时才能确认；否则明确未支持。不能把无糖等同于无甜味、把“不辣”当作过敏安全判断。
4. list-nutrition-foods：按具体餐品名称和份量匹配。缺失为未知。标准份量相加不是实际制作的精确测量。
5. 用户需要用券时才调用 query-store-coupons：仅查看当前可用券，不自动领取。用券要拿到有效且成对的 couponId/couponCode，且该券要由官方核价验证；不要凭券名减钱。只向用户展示券名称及适配候选，协调器在内存中解析标识；不要求普通用户提供券 ID。默认不带券。
6. calculate-price：每份完整候选独立核价，用 items[].productCode、roundList[].round 和 comboItemList 传套餐选择；应付来自返回的整数分 price。替换任何餐品后重新核价，不能手算差价。

最多比较少量有意义的候选；说清比较范围。接口错误立即停止当前链路，标明此前结果是否完整，绝不拿 fixture 充当实时结果。

三个比较角度

对同一份已核验事实包，按以下标准比较。事实包包含用户需求、门店、核价时间、完整明细、整数分总价、营养值与缺失项，不含凭证或券 ID。

• 价格较低：首先排除不满足完整餐单和硬性条件的方案，再选价格较低的候选。优惠券只有在原本要买的餐单上真的减少支出才有价值。
• 钠含量较少：程序在已知钠数据中排序，另展示能量与蛋白质供比较。不得把钠少或低热量说成“均衡”，不得把未知说成零。
• 更贴近口味：在硬性条件内优先用户偏好；偏好满足不了时说明，不偷偷放宽“不吃辣”等排除项。

这些是确定性的比较标准，不是三个独立模型。不要制造角色对话或争论；多个标准选中同一餐单时合并说明，不重复展示三份相同方案。

汇总与用户选择

用表格展示每份餐单：完整明细、当次整单价格、预算余量或超额、已知营养、未满足条件、比较理由。没有满足条件的候选时明确说明。

需要展开时给出“价格与钠”“口味与钠”的取舍候选：只有另一份在每个所选维度都不差且至少一个更好时才淘汰当前餐单。同值并列保留，另提供价格、钠、能量、蛋白质四维取舍，所有对应指标须完整。四维可能留下全部候选，不称其为唯一均衡最优。不编造健康评分，不声称穷举全部菜单。

用户选择前，复述门店、餐品、份数与价格。用户改变预算/偏好/餐单后，旧选择作废。记录选择不等于创建订单；后续购买由用户在官方渠道完成。

积分、券包与渠道核验

只有用户询问积分/券包时，才调用相应个人接口。query-my-account 返回积分数据，不是完整会员档案；没有会员等级字段就不能猜测等级。

“我的券快过期了吗”

只清点券时不查询积分或订单。使用 query-my-coupons，每页最多 200 条，最多 5 页；核对页码、总数与分页期间的一致性。不完整时明确标记，不能当作全部券。可运行 python3 demo.py --my-coupons 复用确定性分析；--json 提供全部脱敏明细。

分别说明四件事：官方 enable 当前状态、有效日期、从 datetimeText 本地解析的时间窗口、门店/渠道是否核验。enable=1 也不等于特定订单可用。日期与时段原文保留；无法完整解释星期或特殊限制时标待核验。用北京时间，明确午夜不改成当天结束，纯日期不编造精确截止；“24 小时内”不说成“今天”，距离关闭时长不说成连续可用时长。

早餐开窗前可以说“05:00 开始，目前尚未进入窗口”；今天窗口关闭但明天仍有窗口时，不能说券已过期。显示本地解析依据与官方原文，字段冲突不猜测。分钟末点按包含该分钟解释，遇到边界时仍以官方渠道为准。

同名券仅分组浏览，每张分别保留日期与规则，不称可叠加；已结束的券单列，不催促用户处理。先突出最多三张相关的临期券，并提供其余明细。提醒“本来不需要买就不必为了用券消费”。公开演示使用 python3 demo.py --coupon-demo 的构造数据，不分享用户真实余额或券包截图。

“这顿能用哪张”

先确认本次餐品需求、门店与到店/外带/配送意图。可运行 --my-coupons --store-code 门店编码，配送/得来速同时携带正确的 --channel 与 --business-code。程序仅在内存中用成对券标识匹配门店返回；同名不作身份匹配。未出现在该店返回中不能说整张券作废。到店查询尚不能单独证明外带资格，取餐方式仍看核价的 takeWayList。

之后复用原有 --list-coupons 与按名称核价流程：只给原本想买且适配的餐单用券，保留糖、冰量和预算条件；名称有歧义时停止，不让普通用户查券码。只有 calculate-price 才能确认应付与实际优惠；没有成功核价时不得报告节省金额。券包清点不会自动核价或下单。

1. query-my-coupons 展示拥有的券；分页不完整要说明。它不校验门店/渠道。
2. available-coupons 只是可领取券目录，不表示已经领取。
3. mall-points-products 按用户兴趣查餐品券、实物或活动；不同类目不混用。CLI 当前只查询餐品券。
4. 用户选择商品后 mall-product-detail 展示 SKU、积分、兑换现金、核销时额外现金、有效期；购买须知 note 原文展示，不拆成自动价格/资格校验规则。
5. 必须区分“积分换券”与“券能在这次订单用”。积分不按固定比例直接当现金。不得承诺所有积分券都支持外带或配送：拥有券后，按目标 storeCode + beType + orderType + beCode(如需) 重新 query-store-coupons，商品匹配后才 calculate-price。未兑换商品的渠道资格标“尚未核验”，不能为了验证先花掉积分。
6. 本版本不领取、不兑换、不支付、不抽奖。用户要购买时转到官方渠道；不要报告没有执行的交易成功。

详见 references/mcp-capabilities.md 的完整能力与实现状态。订单复购、活动等可作为后续扩展，不冒充本版本已接入。

本地程序

• python3 demo.py：历史快照演示，零 Token，不联网。
• python3 demo.py --list-coupons --plan fixtures/plan.json：只查询券名称与匹配候选，不领券、不输出券 ID。
• python3 demo.py --live --plan local/my-plan.json：用户选定门店和候选后真实核价。
• python3 demo.py --budget 35 --taste spicy --side fries --json：结构化比较结果。
• python3 demo.py --search-stores --city 南京 --keyword 新街口：按地点搜索到店门店；--channel drive 查询得来速。
• python3 demo.py --list-meals --store-code 门店编码：当前菜单；--meal-code 编码 选择最多三种套餐，不再限定原样例。
• python3 demo.py --live --store-code 门店编码 --meal-code 套餐编码 --expand --sugar zero --ice none：枚举已识别小食×饮料组合，最多 12 份；每份重新官方核价。用当前官方特调 key 处理去冰。数字编码由协调器从工具结果带入，不让普通用户查 ID。
• python3 demo.py --live --plan local/my-plan.json --omit 麦香鸡酱：只对实际存在该配料的套餐执行去除特调，不沿用标准营养总数。
• python3 demo.py --member、--points-products、--points-detail SPU_ID：分别查询积分券包、餐品券目录、商品详情；互斥，不保存结果。
• python3 demo.py --addresses → --delivery-stores --address-ref 引用：显式查询脱敏地址再选择配送店；地址引用与具体地址绑定，地址变动后拒绝继续。
• python3 demo.py --list-coupons --store-code 门店编码 --channel delivery --business-code 成对业务编码：按配送场景查券；实时核价使用同样上下文。
• --energy-limit、--protein-min、--freshness-minutes 和 --max-response-mb 提供显式边界。
• gourmet/core.py：完整餐单与硬性条件校验。
• gourmet/mcp.py：协议与只读工具白名单。
• gourmet/live.py：套餐构造、官方核价、精确名称营养匹配。

限制与实测范围见 docs/validation.md。不保证最低价，不构成营养或医疗建议。

麦门点餐议事会 · mcd-agent-gourmet

同样的东西，两条点法差 ¥12.00（24.7%）。 价格一律以麦当劳官方当次核价为准：菜单价有时附带条件（例如需要随单购买一张卡），这种情况下核价会不同——所以它只报核价，并把条件一并说明。

这就是它做的事：把你这一餐真正要付的钱算出来，再告诉你有没有更便宜的点法。金额一律来自官方 calculate-price 的整数分；菜单展示价只作参考，附带条件会一并说清。

「35 元，不辣，有糖可乐去冰，带走。」 一句话说清需求，给你一个答案 + 一张能照着点单的清单；没有满足条件的方案就直说没有，不会用不完整的餐单凑数。

打开在线体验（免登录） · 安装 Skill · 真实联调记录 · English

English TL;DR — A read-only McDonald's China MCP client + agent skill. Say "35 yuan, not spicy, regular cola, no ice, takeaway" and it compares complete meals (main + side + drink) using official per-order pricing, tells you why each rejected meal lost (dominated by which candidate, on which axis), and when nothing fits it says so — plus how much budget would actually be needed. An explicit regular-cola choice is never silently swapped for zero sugar. English README · 30-second demo

先试 30 秒

不用账号、Token 或安装：

• 打开就是答案：默认直接给出这一餐（巨无霸三件套 ¥36.50）和一句可核对的理由——「比单品直选省 ¥12.00（24.7%）」。
• 点 「就这个」：出现可复制的点单卡（门店 / 取餐方式 / 每样官方名称 / 合计）。
• 把预算改成 30 元：它说没有方案，并告诉你最低需要多少（¥36.50）——不硬凑。
• 想看别的，点 「我想比较」：才展开全部候选与「为什么不是它」。默认不给表格。

网页使用历史快照，所有比较在你的浏览器内完成，不收集凭证、不调用下单、不加入追踪器；本项目为独立参赛作品，非麦当劳官方产品。也可看 35 秒录屏演示（v0.2 界面录制）。

首屏长这样（一个答案，不用你挑）

真实核价快照上的实际输出（门店：演示门店（名称已脱敏），2026-10-17）：

这顿就它了 👇

  巨无霸三件套 · 套餐（巨无霸 + 中薯条 + 可乐中杯）
  ¥36.50   演示门店（名称已脱敏） · 到店自取
  比「单品直选」省 ¥12.00（24.7%）

点单卡（可复制）
  门店：演示门店（名称与编码已脱敏）· 到店自取
  1. 巨无霸
  2. 中薯条
  3. 可乐中杯
  合计：¥36.50
  比「单品直选」省 ¥12.00（24.7%）
  以上只是记录你的选择；没有下单、没有支付。

• 默认只给一个答案，不让你在 3 份表格里做多目标权衡；理由必须是可核对的事实（省了多少钱 / 价格最低 / 钠最低），不是说服文案。
• 点单卡是最终产出物：门店、取餐方式、每样官方名称、合计——照着在 App 或柜台点即可。
• 想看别的：--compare 才展开全部候选与「为什么不是它」。

目标用户

• 一个人或两个人吃饭、预算有限、对口味有明确偏好的人；
• 以到店自取 / 外带为主，想在下单前把「这一顿多少钱、怎么点更划算」算清的人；
• 需要把钠 / 能量 / 蛋白质当筛选条件的人（条件由你自己设，不是健康建议）；
• 用 WorkBuddy 等 AI 客户端、希望"说一句话就得到可核价餐单"的人；
• 开发者：想看一个只读 MCP 客户端 + 确定性比较 + 可复算省钱数字的实现样板。

三件我们做死的事

1. 钱必须是真数：金额只认官方 calculate-price 返回的整数分；菜单展示价附带的条件（例如「随单购麦金卡」）会一并说清。例：巨无霸三件套菜单价 ¥36.50、官方核价也是 ¥36.50；带「随单购卡」条件的商品两者会不同，此时它会同时显示条件与核价。
2. 你的硬约束只说一次：不辣、去冰、有糖……记住你的条件，不反复问，也不因为"营养更优"替你改。
3. 两个人也能算：份数完备性按人数（主食与饮料各 ≥ 人数），比较用人均价，而不是拿"两人总价"去比"一人总价"。

再加上一条：不领券、不兑换、不下单、不支付，也没有购物车。

它做什么

“35 元，不辣，有糖可乐去冰，带走。帮我看看附近哪家店合适。”这是我们希望用户直接表达的需求。Skill 会先补齐地点、让你确认门店，再比较完整餐单，不要求普通用户复制门店、商品或券的编码。这条路径由安装了 Skill 的 AI 客户端执行；网页是免登录的历史数据体验，CLI 是开发者入口。

比较程序按价格、已知钠含量、口味匹配三个明确标准给出结果。同一餐单可能符合多个标准；这不代表三个独立模型进行了讨论，也不承诺全菜单最优。

上表是 2026-10-13 演示门店的真实核价快照，不是当前报价，也不是营养搭配建议。实际购买须重新核价。我们比较六份候选，不保证全菜单最低价。

和下单渠道是什么关系

App 是下单的地方；这里是打开 App 之前把「这顿怎么点」算清楚的地方。

• 下单仍在麦当劳 App 或门店完成；本工具不提供购物车、不代下单。
• 它只做「打开下单渠道之前」的那一步：把你的条件变成可核价的完整餐单，并说明取舍。
• 没有符合条件时会直说，并给出保持其他条件的预算阶梯（差多少钱、加多少后有几份可选）。
• 不领券、不兑换、不下单、不支付。

两者不冲突：用它决定点什么，用 App 完成购买。

在 WorkBuddy 里使用

先按官方文档配置麦当劳 MCP 连接器。mcp-config.example.json 只含环境变量占位符；若客户端不支持变量展开，请只在该客户端的私有配置中设置实际凭证。

可以把下面这段发给 WorkBuddy：

请安装这个技能：https://github.com/polaris-smart/mcd-agent-gourmet
保留 SKILL.md、gourmet/、demo.py、fixtures/ 的相对位置。
使用我已配置的麦当劳 MCP 连接器。

35 元，不辣，有糖可乐去冰，主食、小食、饮料各一份，带走。
我在南京江宁区。先显示门店名称和地址，让我选店。
再查当次菜单，给我最多三份符合要求的方案，说明价格和取舍。
没有满足条件的方案时说明原因，先别替我改饮料或加预算。
只查询和核价，不领券、不兑换、不下单、不支付。

偏好可按自己的习惯改成无糖或其他可选饮料。门店编码由客户端从查询结果中传递；不能在没有位置依据时声称自动选中了“离你最近”的店。

实现说明： Python 和网页使用确定性筛选、排序与非支配集合比较。SKILL.md 引导 AI 客户端理解需求、查询并解释结果，不制造三个独立模型的角色对话。新版在 WorkBuddy 客户端中的完整对话路径仍需验收，详见 验证记录。

两个零输入入口（不用你描述需求）

先说清楚它查不到什么（免得你白等）

官方 MCP 覆盖的是麦当劳自有渠道的只读数据。下面三类现在拿不到，遇到时它会直说，而不是猜：

1. 券/卡的完整条款原文：「不与其他优惠同享」的具体边界没有对应工具，只有券名、官方状态与时间字段。
2. 麦金卡 / 早餐卡的实时权益（剩余次数、适用门店）：35 个工具里没有对应入口。
3. 份量 / 克重 / 尺寸：没有数据源，所以它不会回答「是不是缩水了」，只会给同价位的替代方案。

另外，MCP 不含美团、饿了么、京东、抖音、淘宝闪购等第三方渠道——第三方价格与券以各渠道自己的页面为准。以上三类之外的实时价格、门店供应、营业状态、券的可用性判定，都走官方接口。

0.4：把「为什么不是它」也讲清楚

• 前沿解释：每个比较角度（价格与钠 / 口味与钠 / 多维营养）除了列出候选，还会说明其他候选被谁比下去、差在哪个维度。例如「从价格与钠角度看，为什么没有 cheese-classic：被 cheese-corn 比下去——价格更低（¥32.00 vs ¥33.50）；钠更低（1053 mg vs 1182 mg）」。同值并列保留，不制造虚假胜出；数据不完整的候选单独列出「因数据不完整未参与比较」，不当 0 分。
• 预算阶梯：预算不足时不再只报一个「最低需要多少钱」，而是给出阶梯——「¥32.00 → 可选 2 份；¥32.50 → 3 份；¥33.50 → 5 份」，并明确只调整预算，不放宽口味、小食、饮料或营养条件。
• 两条都只做解释与提示：不替用户改条件、不自动加预算，也不给健康评分。

0.3：按普通人的点餐方式使用

“35 元、不辣、有糖可乐去冰、带走”或“35 元、不辣、无糖可乐去冰、带走”应当是一句话。有糖和无糖都是平等的口味选择，未指定时不默认无糖。WorkBuddy Skill 会补问缺失的门店或配送地址，按官方选项构造餐单，解释未满足的条件，不要求普通用户查商品或券 ID。

• 糖与冰量：有糖可乐／无糖可乐／都可以并列展示，明确选择后不会因营养排序而擅自替换；标准冰、少冰、去冰、多冰使用当次官方特调 key。去酱、去菜按完整配料名匹配，重新核价，去配料后标准营养合计改为未知。
• 门店与组合：搜索门店、查看当次菜单、选择套餐；按可售的小食×饮料最多展开 12 份并逐份核价。供应缺失就说明，不能把旧店套餐当成全国通用。
• 多维取舍：个人能量上限、蛋白质下限，以及价格/钠/能量/蛋白质的非支配候选；不输出任意健康评分。
• 没有合适餐单时：只有预算阻碍时显示保持其他条件所需的最低候选预算；否则提示扩展候选或由用户调整条件，不自动放宽。
• 少重复填写：网页可主动点击“记住我的条件”，仅在当前浏览器保存，可随时清除。复制到 WorkBuddy 的文字会携带当前偏好和履约意图。

网页收录的独立历史样例由 fixtures/demo-snapshots.json 管理，当前包括三组南京门店样例；其中一组的门店名与地址已脱敏，因为该门店位于作者住所附近，公开它等于公开个人位置。其余两组均包含实测“薯条＋有糖可乐”和“薯条＋无糖可乐”的去冰组合。各组独立标明门店、公开地址与核价时间，不跨店混比；脱敏只作用于门店标识，核价与营养数据未做修改。网页不实时核价、不接受 Token。

以下命令供开发者调试；日常使用可直接采用上面的 WorkBuddy 对话入口。

python3 demo.py --sugar zero --energy-limit 700 --protein-min 20
python3 demo.py --search-stores --city 南京 --keyword 新街口
# 用返回的真实门店和套餐编码替换下列占位文本
python3 demo.py --list-meals --store-code 门店编码
python3 demo.py --live --store-code 门店编码 --meal-code 套餐编码 --expand --sugar zero --ice none

没有核验冰量的历史样例不能被改成去冰报价。CLI 当前只自动构造三轮完整套餐；全部杯型、儿童玩具、辣度分级及过敏原尚未完整支持。

积分、优惠券与到店/配送

先看看手里的券：什么时候能用，这一餐用不用得上。

在 WorkBuddy 中可以直接说：“看看我的券哪些快到期。如果我去附近那家餐厅带走，有没有适合这顿饭的？先别替我改有糖可乐去冰的要求。”Skill 会区分券包、时间窗口和门店适用性；需要选店或确认餐品时再补问。

python3 demo.py --coupon-demo       # 构造样例，不联网；六张均设为官方当前不可用，仅演示日期/时段分档
python3 demo.py --my-coupons        # 只查询自己的券，默认给可读报告
python3 demo.py --my-coupons --json # 完整脱敏明细，不保存到文件
# 门店编码来自用户确认后的查询结果；以下是开发者入口
python3 demo.py --my-coupons --store-code 门店编码
python3 demo.py --my-coupons --channel delivery --store-code 配送门店编码 --business-code 成对业务编码

报告分别展示官方当前状态、日期原文、本地解释的时间窗口、门店查询结果。早餐未开窗、今天已关窗但明天还能用、工作日限制、跨午夜窗口分别处理。“24 小时内结束”不等于“今天到期”；距截止时长不等于连续可用时长。不认识的限制标待核验，纯日期不补成精确截止时间。同名券不推断叠加，已结束的券不列入临期待关注清单。

门店核验用券标识在内存中匹配，输出不含券码；查询成功也不等于已获优惠。接下来复用下方“可用券查询与按名称核价”，才能确认本次应付。单品券不能强套到三轮套餐；到店查券也不能独自证明支持外带，需要官方核价返回的取餐方式。本来不需要买，就不必为了用券消费。

python3 demo.py --member
python3 demo.py --points-products
python3 demo.py --points-detail 商品SPU编号
python3 demo.py --addresses
python3 demo.py --delivery-stores --address-ref 查询返回的引用
python3 demo.py --list-coupons --channel delivery --store-code 配送门店编码 --business-code 成对业务编码

会员输出只保留积分与券的必要展示字段，不输出账号 ID、券码。地址只显式查询，隐藏姓名、电话及后续门牌；稳定引用防止地址列表变动选错地址。

积分兑换与券的适用渠道是两次核验。 兑换积分、兑换现金和用券额外现金分别展示，官方须知原文保留。不能直接按比例把积分抵预算，也不能保证所有积分券支持麦乐送。拥有券后，按当前门店与渠道查询可用券并官方核价。

堂食/外带选项来自核价的 takeWayList；到店使用 beType=1/orderType=1，得来速为 5/1，麦乐送为 2/2，后两者须使用相应门店返回的 beCode。菜单、券和核价全程一致；配送费用保留官方结果，不用到店价冒充送到家价格。

完整的 35 个 MCP 工具能力地图、接入状态与未实现范围见 能力说明。本程序不领券、不兑换、不下单，也不自动抽奖。

WorkBuddy Skill 市场

已按官方格式补齐元数据与资源目录，可构建 ZIP 分发包：

python3 scripts/build_skill_package.py --output /tmp/mcd-agent-gourmet-0.3.2.zip

包可用于开放平台投稿，目前未提交审核、未上架。安装与上架文案见 市场发布说明。Skill 优先使用客户端已配置的麦当劳 MCP；脚本只需 Python 标准库。

本地运行

Python 3.9+，仅标准库，零第三方依赖。

git clone https://github.com/polaris-smart/mcd-agent-gourmet.git
cd mcd-agent-gourmet
python3 demo.py
python3 demo.py --budget 35 --taste no-spicy --sodium-limit 800
python3 demo.py --budget 35 --taste spicy --side fries --json

默认读取 fixtures/snapshot.json。即使本机有 Token，也不会自动联网。

实时核价

1. 在 麦当劳开放平台 MCP 登录页 用手机号登录后申请自己的 MCP Token；工具清单、限额与字段说明见 官方文档。
2. 在本机私有环境中设置 MCD_MCP_TOKEN。不要提交到 Git，也不要粘贴到公共对话或网页。
3. 先搜索并选择门店。实时模式必须明确传入 --store-code 或已确认的 --plan，不会自动沿用南京样例店。再用 --list-meals 查看该店当次菜单，用 --meal-code 选择套餐。只传门店编码不会载入演示套餐；覆盖计划的旧门店时，必须重新选择餐品及适用的渠道业务编码。
4. 显式运行：

python3 demo.py --list-tools
python3 demo.py --live --plan fixtures/plan.json --budget 35 --taste spicy

程序读取当次菜单、官方营养数据，对候选逐份 calculate-price。真实查询失败会停止，不拿历史快照伪装成实时结果。自动构造支持即时三轮套餐；到店已实测，配送/得来速参数已接入但未完成真实核价联调。默认不使用优惠券。

可用券查询与按名称核价

默认演示和实时核价均不带券。查询入口只显示券名称及适配的候选 ID，不要求用户知道券 ID：

python3 demo.py --list-coupons --plan fixtures/plan.json
python3 demo.py --live --plan fixtures/plan.json --coupon-title '查询返回的完整券名称' --coupon-candidate chicken-classic

candidate_ids 为空表示这张券不匹配当前六份套餐；单品券不会硬套到套餐。名称重复、商品不匹配或券标识缺失均停止。程序只在内存中解析成对标识并交给官方核价，不自动领券。传入券不代表已获优惠，只有官方报价可作为价格依据；真实用券成功链路尚未验证。高级用户仍可在私有计划文件显式提供成对字段。

python3 demo.py --live --plan local/my-plan.json --save-snapshot local/quotes.json

--save-snapshot 保存脱敏餐单快照；不包含 Token、券 ID、账号信息。保存后即标为历史快照。新核价也仅在本工具默认 15 分钟复核窗口（可用 --freshness-minutes 配置为 1～60 分钟）内允许按实时结果选择；这不是官方价格有效期承诺。

同时比较两个维度

网页和 CLI 提供“价格与钠”“口味与钠”两组取舍候选。先筛掉不满足硬性条件或数据不完整的餐单；如果另一份餐单在所比较的每个维度都不差、且至少一个维度更好，当前餐单才被淘汰。同值并列保留，不加秘密权重。“价格与钠”不额外优化软性辣味偏好，但仍遵守有糖/无糖、不吃辣等已明确的硬性条件。

另有价格、钠、能量、蛋白质四维比较：在这组目标下，价格、钠与能量越少，蛋白质越多越优。这是明确的比较方向，不是普遍健康结论。结果可能有多份互不支配的候选，甚至保留全部候选；不把集合包装成唯一“均衡最优”，也不计算没有依据的 0–100 健康分数。

例如在历史快照、预算 35 元且明确“想吃辣”时，“价格与钠”保留 ¥32.00 / 1053 mg 和 ¥32.50 / 592 mg 两种选择；“口味与钠”保留辣味餐与钠更少的非辣餐。只比较已逐份核价的有限候选，尚未穷举全菜单组合。

[后续改进清