> **一句话摘要**：麦当劳开放了 MCP，一口气给了 35 个工具——门店、菜单、营养、优惠券、算价、下单、查单……但工具多不等于好用，真正的活儿是**把它们串成一条链**。这篇讲我怎么把「想吃麦当劳」这个念头，一路串到「订单已创建」，以及中间踩过的四个坑。

---

## 一、先说个每天中午都要面对的问题

我的午休剧本常年是这样的：

想吃麦当劳。但同时有三件事卡着我——

1. **热量**：这餐想控制在 550 大卡左右；
2. **预算**：不想超过 28 块；
3. **脑子**：翻菜单算热量、比价格、查券、还要判断"套餐到底划不划算"，四件事凑一起，想想就算了。

然后我点了碗面。

问题不在于麦当劳贵或者不健康，**问题在于"算清楚"这件事太累了**。而"算清楚"恰好是机器最擅长的事。

所以当我看到麦当劳开放了 MCP，第一反应不是"真好玩"，而是：**这事终于有人替我算了。**

---

## 二、麦当劳 MCP：35 个工具，一个完整闭环

先交代背景。麦当劳中国在 [open.mcd.cn](https://open.mcd.cn) 开放了 MCP 服务，手机号登录后激活就能拿到 Token。配置也简单，在 WorkBuddy 的连接器里填一段配置就行：

```json
{
  "mcpServers": {
    "mcd-mcp": {
      "type": "streamablehttp",
      "url": "https://mcp.mcd.cn",
      "headers": {
        "Authorization": "Bearer ${MCD_MCP_TOKEN}"
      }
    }
  }
}
```

连上之后，我一共数出 **35 个工具**。粗看有点杂，但按职能归一下类，会发现它其实覆盖了一个完整闭环：

| 环节 | 工具 |
|---|---|
| 时间与门店 | `now-time-info`、`query-nearby-stores`、`delivery-query-stores` |
| 地址（外送） | `delivery-query-addresses`、`delivery-create-address` |
| 菜单与详情 | `query-meals`、`query-meal-detail` |
| 营养数据 | `list-nutrition-foods` |
| 优惠券 | `available-coupons`、`auto-bind-coupons`、`query-my-coupons`、`query-store-coupons` |
| 算价 | `calculate-price` |
| 下单与订单 | `create-order`、`query-order`、`cancel-order`、`order-list` |
| 积分与商城 | `query-my-account`、`mall-points-products`、`mall-product-detail`、`mall-create-order` |
| 抽奖与活动 | `query-lottery-info`、`draw-lottery`、`campaign-calendar`、`query-my-prizes` |
| 派对预订 | `query-party-city`、`query-party-store`、`query-party-store-session`、`party-order-create` |

看到这张表，我的判断是：**工具够了，缺的是编排。**

因为单看每个工具，它只能回答一个很窄的问题——"这家店有什么菜""这个券多少钱"。但用户真正想要的是那个**端到端的答案**："我该点什么，多少钱，怎么下单"。

从"工具集合"到"可用产品"，中间隔着一条链。这就是整件事的核心工作量。

---

## 三、串起来长什么样

先把链路画出来，后面挨个讲：

```
用户：想吃麦当劳，550 大卡以内，28 元以内，深圳科技园附近
  │
  ├─ 1. query-nearby-stores        选定门店，拿 storeCode
  ├─ 2. query-meals                拉当店菜单，拿每个餐品的 code / 价格
  ├─ 3. list-nutrition-foods       拉营养表，拿每项的热量
  ├─ 4. query-meal-detail          把套餐拆成组件，按组件求和算热量   ← 关键
  ├─ 5. 本地引擎                    双约束搜索，产出 3~5 档带标签方案
  ├─ 6. query-store-coupons        当前门店当前渠道真正可用的券
  ├─ 7. calculate-price            复价，含券终价 + takeWayCode
  ├─ 8. 用户确认
  ├─ 9. create-order               下单，返回订单号 + 支付链接
  └─ 10. query-order               用户支付后复核订单状态
```

一共十步。前九步是"替用户想清楚"，第十步是"把单下掉"。

下面挑四个最有意思的环节说。

---

## 四、四个坑，和它们背后的设计取舍

### 坑 1：套餐是个黑盒，官方营养表里查不到

这是整件事最先撞上的墙。

麦当劳的营养表里，你能查到"麦辣鸡腿汉堡"485 kcal、"中薯条"289 kcal、"可乐中杯"147 kcal。但你查不到"三件套"——**因为营养表只收录单品，组合餐没有独立条目。**

很多同类工具到这里就放弃了，直接把套餐从候选里剔除。

但这里有个反直觉的事实：**大多数情况下，套餐才是最省钱的选项。**

看这个对比（真实数据）：

| 方案 | 组合 | 热量 | 价格 |
|---|---|---|---|
| 最贴热量 | 人气经典随心配（套餐） | 576 kcal | **14.9 元** |
| 最省钱 | 精选超值随心配（套餐） | 502 kcal | **13.9 元** |
| 最平衡 | 麦辣鸡腿汉堡（单点） | 485 kcal | 22.5 元 |

两档最划算的答案都是套餐，而且只要 14 块左右。**如果你把套餐跳过了，你恰好跳过了最优解。**

所以反过来做：用 `query-meal-detail` 把套餐拆开。

这个接口会返回 `rounds[]`，每个 round 是一轮选配（比如"主食任意选 / 选择套餐内小食 / 选择套餐内饮料"），每轮里 `isDefault=1` 的那项就是默认选择。于是：

```
套餐热量 = 各轮默认组件的热量之和
```

拆完之后，"钱省在哪、热量花在哪"就一目了然了：

```
麦辣鸡腿汉堡三件套        33.5 元   921 kcal
├─ 麦辣鸡腿汉堡  485 kcal
├─ 中薯条        289 kcal
└─ 可乐中杯      147 kcal
单点合计 46 元 → 等于省了 12.5 元
```

**一行拆解，把"套餐值不值"这个玄学问题变成了算术题。**

### 坑 2：拆出来的组件，可能也查不到

更麻烦的情况来了。

实测中我遇到某个随心配套餐，默认组件里有"可乐麦炫酷"——**营养表里同样没有这一项。**

这时候有两条路：一是放弃这个套餐，二是**换一个组件**。我选了第二条，但换法有讲究。

换法不是"随便挑个有数据的饮料"，而是：**在同一选配轮次里，优先挑与默认项名称最像、且差价接近最低的组件。**

所以"可乐麦炫酷"会被换成"可乐中杯"，而不是柠檬茶——因为前者和它名字最近、差价也最小，最接近用户本来会点的那杯。

换完之后还要**如实标记**：输出里带上 `price_estimated=true` 和替换记录，提醒后续复价时按替换后的组合核对金额。

这一条我觉得是这类工具的分水岭：**猜一个热量糊弄过去，还是老实告诉用户"我换了、我标了"。** 前者用户永远不知道，后者用户能验证。

### 坑 3：价格单位是「分」，而且不同接口还不一样

这个是纯粹的实现细节，但第一次踩到会很懵。

MCP 返回的价格，单位是**分**。展示给用户前一律要 `/100` 转成元。

**但有个例外**：`query-meals` 返回的 `currentPrice` 直接就是元，不用转。

于是一条铁律：**先看清是哪个接口返回的价格，再决定要不要除以 100。** 统一处理会出错。

另外还有一个更隐蔽的坑：菜单里的 `currentPrice` **已经含了大部分活动价**，但它不等于含券终价。初筛可以用菜单价，**终价必须以 `calculate-price` 为准**。

### 坑 4：门店参数不能硬编码

`create-order` 里，到店场景必须传一个 `takeWayCode`（取餐方式码）。这个值从 `calculate-price` 返回的 `takeWayList[].code` 里取。

听起来很简单，但实测发现——**不同门店返回的值完全不一样。**

我见过的就有三种：`eat-in`（堂食）、`locker-out`（外带柜）、`take-in-store`（店内自提）。

所以千万别想当然写死一个"eat-in"，**一律以当次接口返回的为准。**

还有个配套的坑：**点套餐下单时，必须传 `roundList`。** 结构长这样：

```json
{
  "round": "1",
  "comboItemList": [{ "code": "1120", "quantity": 1 }]
}
```

其中 `round` 传 `query-meal-detail` 返回的轮次 id，**要用字符串形式**（`"1"` 而不是 `1`），组件 code 传该轮选中的那一项。

---

## 五、串完之后，它的分工是这样的

把链路跑通之后，我做了个重要的分工决定：

**MCP 只负责取数和算价，推荐逻辑全部放在本地。**

具体来说，`query-*` 系列接口负责把门店、菜单、营养、券这些**原始事实**拿回来；然后交给一个纯标准库、不联网的本地引擎 `optimize.py`，由它完成名称归一化匹配、餐品角色分类、套餐组件热量求和，以及"1 主食 + 0~1 小食 + 0~1 饮品"的组合搜索（约 2000 个候选方案）。

这么做有两个好处：

**一是快，二是可复现。** 推荐结果不依赖模型当场发挥，`tests/` 里存着真实 MCP 数据样本，跑一遍就能复现同样的输出。数据有问题、逻辑有 bug，能定位到具体哪一行。

实测回归的结果长这样：

| 目标 | 最贴热量 | 最省钱 | 套餐优选 |
|---|---|---|---|
| 550 kcal / 28 元 | 人气经典随心配 576kcal 14.9元 | 精选超值随心配 502kcal 13.9元 | — |
| 700 kcal / 30 元 | 麦香鸡+新地 651kcal 29元 | 人气经典随心配 576kcal 14.9元 | 精选超值随心配 502kcal 13.9元 |
| 200 kcal / 15 元 | 麦香鱼 325kcal（触发"凑不出来"分支） | 精选超值随心配 13.9元 | 人气经典随心配 14.9元 |
| 900 kcal / 40 元 | 巨无霸+那么大鸡排 898kcal 39.5元 | 麦香鸡+那么大鸡排 754kcal 31元 | 精选单人餐三件套 34.5元（省 11.5 元） |

还有一条我觉得必须写进文里：营养表里查不到的餐品（龙焰鸡腿堡、高达吉士双牛堡、蓝莓爆爆珠麦旋风等 12 项），**如实标注"营养表无匹配"，一个热量都没有编。**

---

## 六、下单前的那道闸

链路串到最后一步，会遇到一个必须想清楚的问题：

**`create-order` 是真花钱的动作。**

所以我在设计上设了一道硬闸：**未经用户明确确认，绝不调用它。**

具体是这么做的：

1. **先复价。** 用 `calculate-price` 算出含券终价，把「原价 / 优惠金额 / 实付 / 热量」四项摆成一张表；
2. **再问一句。** 把决定权交回去，等用户明确说"可以"；
3. **问清哪一档。** 如果前面给过多档对比，必须让用户自己选——不替用户挑；
4. **才开始下单。**

下单成功后返回订单号和支付链接，并且要提醒一句：**支付时限大约 15 分钟，过期作废。** 用户付完再调 `query-order` 复核状态；要取消就用 `cancel-order`，不追问原因。

这一步看着像"啰嗦"，但它是整条链路里最不能省的地方。**自动化的价值是替人算，不是替人花钱。**

---

## 七、还有一条我主动砍掉的功能

`calculate-price` 本身只接受 `couponId` / `couponCode`，**没有积分参数**。积分要抵现，只能走"积分商城兑换餐品券 → 券再用到订单上"这条很长的链路。

我最后决定**显式排除积分抵扣**，理由有三条：

1. 它和"控热量 + 省钱"这个主题关联度很低；
2. 会让主流程凭空长出好几步，体验变差；
3. 与其做一个半吊子，不如把**券 + 套餐拆解**这两件事做透。

用户如果问起积分，就一句话说清楚"这一步先按券算，积分可以在麦当劳 App 里另用"，**不做虚假承诺。**

范围控制也是同理：套餐只拆 **3~6 个**（优先拆预算附近、标签含"爆款/超值/立省"的），不追求全量。全拆会让单次对话的工具调用量爆炸，收益却很小。

**做产品的难处从来不是"能不能做"，而是"敢不敢不做"。**

---

## 八、写在最后

回头看，整个过程里最有价值的动作，不是接上了多少个工具，而是**把 35 个零散工具收敛成了一条十步流水线**：

```
门店 → 菜单 → 营养 → 拆套餐 → 求解 → 找券 → 复价 → 确认 → 下单 → 查单
```

每一步只回答一个问题，串起来就是一个完整答案。

而这条链路上最有意思的两个设计，其实都不是"功能"，而是**态度**：

- 组件查不到营养，不猜，换一个最近的并**标出来**；
- 下单前那一道闸，**永远把最后一下留给用户**。

---

## 关于这个项目

上面讲的这套流程，我做成了一个完整的开源项目：

> **麦麦卡路里省钱下单助手**
> 在「热量目标 + 预算上限」双约束下，帮你从麦当劳菜单里挑出一份热量合适、价格划算的组合，顺手把套餐拆开算清楚，确认后陪你把单下完。

项目里包含：六步工作流说明、纯标准库的组合优化引擎、MCP 字段与坑位手册、真实数据回归样本，以及本篇提到的全部实测记录。

**仓库地址：** https://github.com/winkychannn/mcd-calorie-order-saver

```
git clone https://github.com/winkychannn/mcd-calorie-order-saver.git \
  ~/.workbuddy/skills/mcd-calorie-order-saver
```

顺带说一句，仓库里的 `references/mcp-playbook.md` 记录了我在 MCP 上踩到的**全部字段级坑位**（包括本文没展开的那些），如果你也在接麦当劳 MCP，那份文档可能比这篇文章更省你时间。

---

*本文所有餐品、价格、券与订单数据均来自麦当劳 MCP 实时返回，采集门店为深圳同方信息港门店与广州华夏路餐厅。餐品信息、价格及供应状态请以麦当劳官方渠道的实时结果为准。*

*下单是真实消费动作，请确认后再操作。相关营养数据仅供参考，不构成任何医疗或营养建议。*

*（全文完）*


一句话摘要：麦当劳开放了 MCP，一口气给了 35 个工具——门店、菜单、营养、优惠券、算价、下单、查单……但工具多不等于好用，真正的活儿是把它们串成一条链。这篇讲我怎么把「想吃麦当劳」这个念头，一路串到「订单已创建」，以及中间踩过的四个坑。

麦当劳 MCP 实战：我把 35 个工具串成了一条点单流水线

产品砖家

编程语言

麦当劳MCP开放35个工具，核心不在工具数量，而在编排成链。本文展示如何将"想吃麦当劳"念头转化为下单闭环，覆盖门店选择、套餐热量拆解、优惠券匹配到订单创建，并揭示四个关键实施坑位：套餐营养黑盒、组件数据缺失、价格单位混乱及门店参数差异。附开源项目参考。

代码解释

WorkBuddy 

GitHub

2026上云采购 | AI焕新·智启新局

workbuddy

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

麦当劳 MCP 实战：我把 35 个工具串成了一条点单流水线-腾讯云开发者社区-腾讯云

麦当劳 MCP 实战：我把 35 个工具串成了一条点单流水线

麦当劳 MCP 实战：我把 35 个工具串成了一条点单流水线

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐