爷爷不泡茶信息查询

解决的问题

给 AI 装一个「爷爷不泡茶」的知识入口很容易，难的是让它回答时不编。门店营业状态、当天活动、单品糖度与加料、会员积分与优惠券都是强时效数据，模型脑子里的版本要么过期要么压根没有。这个 skill 要解决的是：把「我不知道」变成一次确定的 MCP 调用，而不是一次流畅的想象。

工作方式

核心是一条固定的查询链路：

• 几乎一切查询都从 search_stores 开始，拿到 shopId / shopCode 之后才进入细节。品牌简介与茶知识词条是唯二不需要门店上下文的工具。
• 找店参数按用户输入的粒度选：具体地点、POI、小区名走 address，由服务端做 LBS 解析；只有城市名才传 city；门店招牌名走 keyword。半径也有讲究：附近 给 2-3 公里，同城 给 30 公里，郊区地址放宽到 10-15 公里。
• 细节查询覆盖菜单与做法（practices 里的甜度、温度，attaches 里的加料与加价）、场景化推荐、单品横向对比、实时排队、当前活动。
• 下单不做「AI 直接下单」。prepare_wx_handoff 只生成一个 24 小时有效的 https 中转链接，按设备跳进小程序，由用户自己完成下单与支付。
• 会员能力（get_my_member_info / get_my_coupons / get_my_orders）需要 OAuth 授权，走完一次登录后才能拿真实数据。

边界与注意点

宁少勿错是第一原则。MCP 失败时，动态信息（菜单、价格、排队、活动、营业状态）一律不编，直接说明「暂时拿不到」；静态信息（品牌简介、词条）可以转述但要标注「以小程序为准」。

几个容易踩的坑：

• 不要把 北京回龙观 拆成 city=北京 + keyword=回龙观，门店名里不会有片区名，必须整体交给 address。
• OAuth 有两条路径：host 已注册 MCP 走 PKCE，只能用 Bash + curl 直打端点的走 device flow。不能默认走 PKCE，curl 模式下会让用户白登一次。
• 用户给手机号、验证码想让你代登录时必须拒绝，授权只能在浏览器完成，所有环境走真实短信、不设固定验证码。
• access_token、shopCode 等内部字段不回显给用户，只给最终链接。
• 过敏原、营养成分这类工具覆盖不到的信息，坦诚承认并指向小程序或门店，不要硬答。