ARTICLE · 1284592
麦当劳把 33 个点餐接口接给了 AI:1318 份作业里,登上榜单的只有 102 个
麦当劳有官方 MCP 服务。
不是第三方套壳，是它自己挂在 mcp.mcd.cn、文档齐备、还带版本日志的那一个。
我把它的工具表逐条数了一遍，又把 GitHub 上的 1318 份参赛作业全拉了回来。
数完之后有三件事，跟「厉害」这个第一印象对不上。
01 先把「厉害」那部分说清楚
MCP 是一套让模型统一接入外部数据和工具的开放协议。
麦当劳这一套，入口在 open.mcd.cn/mcp，服务地址是 mcp.mcd.cn，走 Streamable HTTP，请求头里带一个 Bearer Token。
官方文档写得很干脆：每个 Token 每分钟最多 600 次请求，超了返回 429。免费。
它铺开的地方比想象中多。麦乐送、到店取餐、得来速车道都覆盖了，再往后还有团餐、主题派对、积分商城和抽奖。
优惠券和餐品营养，也都在里面。
一个卖汉堡的公司，把三件事连成了一条线：读你的会员数据、替你写好订单、最后把支付链接递回来。
中间任何一环，过去都得你自己在 App 里点。
这在消费品牌里并不常见。
最容易被忽略的是最后半句：订单可以帮你建，钱必须你自己付。
支付环节一律回官方渠道，MCP 只负责把链接递过来。这条边界写在服务规则里，也写在每一位参赛者的 README 里。
还有一条更硬的：Token 与个人会员账号强绑定，官方明确禁止代下单、代领券牟利，也禁止批量高频自动化调用。
02 那个「33」，我一条一条数了
「33 个工具」这个数字，我在好几篇实测文里都见过。
于是我把官方 MCP Server 仓库的 README 拉下来，按表格结构逐条解析了一遍。
结果是 33 条，一条不多，一条不少。
这 33 条不是平均铺开的，按业务场景拆开是这样：
11 条压在「点餐与门店」上，说明官方最认真做的，就是这条主链路。
顺带一个口径问题。官方 README 的工具表是 33 条，有开发者握手之后列出的是 35 个，另一个聚合站上只列了 19 个。
三个数字对不上，不是谁在说谎——工具在上线、文档在更新、第三方站在抄。想拿准数字，只能回官方那张表上数。
03 它不是「突然开放」，是 10 个月长出来的
多数报道给人的印象是：麦当劳最近把接口开出来了。
我把官方版本日志完整拉了一遍，是 10 个版本、跨 10 个月。
一眼就能看出顺序：先给「今天有什么券」，最后才给「怎么取消订单」。
中间隔了 9 个版本。
它一开始想的是把人拉进来（券 + 日历），后来才补齐服务闭环（取消、备注、取餐柜）。
这是我读版本日志得出的推断，不是官方说法。
这是推断，不是官方说法。但版本日志的时间差摆在那里。
还有一个口径差要说明。官方日志把 1.0.0 记在 2025-12-09，而公开报道多写作「2025 年 12 月正式上线」，也有文章写 12 月 25 日。
以官方日志为准。这点误差不影响它已经跑了 10 个月这个事实。
04 1318 份作业，登上榜单的是 102 个
我用 GitHub 的公开接口，把赛事仓库的报名 Issue 全量拉了一遍。
总数 1318 份，其中还开着 1207 份、已关闭 111 份；独立作者 1062 人，人均交了 1.24 份。
提交节奏并不均匀。开赛两天就涌进 378 份，10-10 单日冲到峰值 227；中间 10-17 跌到单日 15 份；最后三天又反弹到 319 份（10-22 是 78、10-23 是 102、10-24 是 139）。
按小时看，最热的是 10-24 中午 12 点，一小时 15 份；凌晨两点到五点，也各自有人在交。
榜单又是另一回事。官方榜单文件逐小时自动更新，我取到的是 10-25 早上 6 点那一版：
102 个项目上榜，第 1 名 1566 star，末位 58 star，全部加起来 20614 star，中位数 95。star 上千的只有 7 个。
也就是说，1318 份报名里，登上榜单的是 102 个，7.74%。
更集中的是分布：前 10 名合计 10670 star，占全部 51.8%，平均下来是全体中位数的 11.2 倍。
热度是真的，集中也是真的。而榜单只认 star，所以「作品好不好」和「排第几」之间，隔着一个拉票动作。
两位参赛者的文章里都在公开请读者去点 star。这不是黑幕，是机制的必然。
05 大家在做同一件事
我把这 1318 条报名标题做了一次词频统计。
「点餐」出现 174 次、「营养」84 次、「预算」60 次、「券」58 次、「积分」53 次、「热量」35 次、「人格」31 次。
光是「点餐」一个词，就出现在 13.2% 的标题里。
另一位参赛者把当时上榜的 106 个作品按赛道拆过一遍：
趣味／人格 26 个 省钱／优惠券／比价 24 个 综合助手 16 个 营养／健身 10 个 团餐 5 个、门店地图 5 个、积分商城 4 个
他数到 106，我数到 102——榜单条目会进出，隔几天就差几个，不必纠结哪个对。
两个数据放在一起看，结论很清楚：最挤的地方，恰好是官方最早开放的那两个能力（活动日历 + 领券）。
如果你也想做一个自己的 MCP 小工具，这条比工具清单更有用：功能撞车最严重的赛道，往往就是官方文档示例最详细的那条。
06 真正稀缺的不是接口，是「用哪些、按什么顺序用」
官方给了 33 个工具，不等于你该全接上。
一位做多人配餐的参赛者写得很清楚：33 个里他实际只编排了 15 个，剩下 18 个（积分商城、抽奖、主题活动预约、团餐对接）明确不用。
理由一句话就够了：工具面越宽，Agent 误触发的概率越高。
这跟我自己的体感一致——不是接口不够用，是「这一刻该调哪一个」没人替你决定。
具体坑也很实在。优惠券要查四处：已到账的、可领但需要先绑定的、门店券、其他。
只查一处，必然漏掉最优组合。
部分门店券只能自取，做外卖方案时必须把它们筛掉。
新账号的订单历史会返回空列表，所有依赖它的功能都得先写兜底。
还有一个特别妙的。菜名关键词识别一定会误判——「吉士」其实是牛肉饼。
纯靠字符串匹配，会把「培根蔬萃双层牛堡」判成猪肉。
所以凡是识别不出成分的餐品，都必须回查详情。
接口是官方给的，顺序是你自己排的。
07 我自己踩到的三条边界
先说清一件事：我没有申请 Token，也没有真的让 AI 帮我点一份麦当劳。下面三条是只读探测和文档核对的结果，不是下单实录。
第一条，没带 Token 访问，会得到一个挺吓人的回应。我直接请求 mcp.mcd.cn，GET 和 POST 都是 403，返回体是这样：
{"code":"0001","msg":"系统错误","data":null}它给的不是标准的 401，也没有一句「缺少鉴权」，而是一句「系统错误」。第一次接入的人看到这个，多半会以为服务挂了。
第二条，限流码是 429，不是封禁。文档写明每分钟 600 次上限，超出返回 429——这是可以退避重试的，不用慌。
第三条，Token 属于个人，不属于团队。它和你的会员账号强绑定，规则里明确禁止转让与共享。拿它去做多人共用的服务，从一开始就走在规则外。
下面两条建议很短，但都是我接之前会先确认的：
先申请 Token，只接一个最小场景跑通（查券、查营养这类只读的），别一上来把 33 个全配上； 把「写操作」和只读工具分开确认——能改数据的那几个（下单、领券、兑换、抽奖），每次都要有人点头。
📌 本周金句
「真正稀缺的不是协议层，是编排层。」
原话出自一位参赛者的实测长文。数完这些数据之后，我最想说的也是这一句——接口是别人给的，顺序是自己排的。
💬 互动问题
麦当劳之后，下一家把接口开出来的是谁？要是这 33 个工具摆在你面前，你第一件想做的事是什么？
📋 一页带走清单
接一个品牌 MCP，先问完这五个问题再动手：
关注爱创见，每天替你把 AI 这摊事翻一遍。觉得哪家的接口早晚也得开出来，留言说一个，我挑有意思的去翻。
有用就点个❤️，顺手转给那个天天点外卖的同事。
