李茶的茶 · 企迈点单 MCP Server。让 AI 在对话里找店、看菜单、组单算价；开启下单能力后还能帮顾客真实下单，付款始终在李茶小程序由顾客自己完成。
默认安装 = 只读：不装开关就和一期完全一样，不产生任何订单、不碰钱、不读经营数据。
对你的 AI 说一句：
我要喝李茶的茶，去 GitHub 拉取一下：lichadecha/licha-order-mcp
装好后直接问「有什么奶茶」「哪家离我近」即可。目前仅支持到店（堂食/自取）。
第一次喝不知道选什么？直接问「有什么推荐」。想让 AI 帮你算哪家店近，可以再给它装一个高德地图 MCP（可选）。
Related MCP server: @striderlabs/mcp-chipotle
把下面这段合并进你的 MCP 配置（mcpServers）：
"licha-order-mcp": {
"command": "npx",
"args": ["-y", "github:lichadecha/licha-order-mcp#v0.5.3"]
}把本仓库根目录的 SKILL.md 装进你的技能/指令目录（客户端支持 skills 时）。
按你的客户端要求重启或重载 MCP。
告诉用户装好了，并按 SKILL.md 的规则开始服务（第一句先说明：仅到店堂食/自取）。
要求 Node ≥ 18；首次运行自动构建（prepare → tsc）。npx 找不到时换 Node 安装目录下的绝对路径。
工具 | 用途 |
find_store | 按店名/商场/城市找门店，返回 storeId、营业状态、营业时间 |
get_menu | 看菜单：无 keyword 返回分类，有 keyword 返回商品列表 |
get_item_detail | 点单卡片：规格、做法（温度/糖度）、加料、是否估清 |
preview_order | 组单算预估总价（本地累加，实际金额以门店收银台/订单为准） |
设置环境变量 LICHA_ENABLE_ORDERING=1 后另注册 5 个下单相关工具（bind_member / prepare_order / place_order / get_order_status / my_orders），安全约束见下方「安全边界」。
mcpServers 配置：
{
"mcpServers": {
"licha-order-mcp": {
"command": "npx",
"args": ["-y", "github:lichadecha/licha-order-mcp#v0.5.3"]
}
}
}安装命令固定指向版本标签（#v0.5.3），不追踪最新提交；升级时以新版 README 给出的标签为准。
要开下单相关的 5 个工具，在同一段配置里加 env（不加就是默认只读 4 工具；改装新标签时整段一起换，2026-09-08 曾漏掉这一行只见 4 个工具）：
"licha-order-mcp": {
"command": "npx",
"args": ["-y", "github:lichadecha/licha-order-mcp#v0.5.3"],
"env": { "LICHA_ENABLE_ORDERING": "1" }
}要求 Node 不低于 18；首次安装会自动构建（prepare 钩子跑 tsc）。
本服务从本机读取企迈开放平台凭证，凭证不进本仓库、不进配置、不进日志：
macOS keychain：qmai-cli 条目的 openKey（自动拆封）
~/.config/qmai/config.yaml：active profile 的 openId / grantCode
也可用环境变量覆盖：QMAI_OPEN_KEY / QMAI_OPEN_ID / QMAI_GRANT_CODE。 缺凭证时工具调用报「凭证不完整」，服务本身正常启动。
**身份边界：当前形态为单机单人。**MCP server 进程内只有一个会话身份，同一进程内多人共用会互相覆盖（后绑的人顶掉前一位，前一位的待确认单被作废）；远程化或开放多用户之前必须先接入传输层身份。
默认不注册任何写工具（LICHA_ENABLE_ORDERING=1 才注册），未开启时 tools/list 只有 4 个只读工具，写通道物理不可达。
开启后写白名单硬编码只有 1 条（创建订单），白名单外一律物理断路。
下单必经两阶段确认：AI 先把待确认单念给顾客 → 顾客确认 → 才提交；下单参数由服务端组装登记，AI 手里只有一个 5 分钟一次性令牌，改不了单的内容。
单笔 ≤¥100、单日每顾客 ≤5 单 / 全局 ≤10 单硬护栏；永不代付——付款一律由顾客在李茶小程序完成。
三本审计日志（读/写/访问）分离，识别值只留尾号。
出参只投影公开字段（店名/地址/营业状态/商品价格），不输出店长联系方式、成本等经营字段。
只改服务端行为与两条 SKILL 固定话术，工具入参不变；SKILL.md 同步升到 0.5.3。
get_menu 不再返回已下架（status=20）商品；有候选时提示「列表不含当日估清状态，以 get_item_detail 为准」。
find_store 营业状态与营业时间单独 10 分钟刷新，出参新增 statusSampledAt；取不到状态报「状态未知」而不是沿用一天前的旧值。
同一顾客重新组单后，前一版待确认单作废；旧 confirmToken 提交被拒并说明「已被更新的一版替代」，prepare_order 出参新增 supersededPendingOrders。
MCP 进程启动时在 access-audit 记一条 server_started（版本 | pid | 写开关），宿主回收进程后可直接数日志。
prepare_order 组单时查询本单可用券（5.1.7，只读），出参新增 coupons（可用券、预测系统默认会用的那张与券后实付）；place_order 读回新增 couponApplied，与预测比对并给出话术。查券失败不阻塞组单。
只改服务端行为，工具入参与话术不变；SKILL.md 同步升到 0.5.2。
结果未知的下单，只有拿到同一顾客、同一门店、时间对得上的那笔订单才解除未知，无关旧单和不完整的订单列表一律保持未知，额度不退还。
安全账本先落盘成功才发单：账本写不进去（盘满、被占位、行损坏）就拒绝发单，重启后每日计数、按顾客计数、未决记录和幂等键逐项恢复，不归零。
待确认单一律用本轮实读的最新价格与可售状态算钱，撞上单笔金额上限或商品估清/下架时直接拒签令牌，浏览缓存照旧可用。
必选做法（如温度）缺一项，确认门在签发令牌之前就拒绝并点名缺的那一组，不替顾客落 UI 默认值。
版本号单源自 package.json（不再有第二份硬编码），绑定会员的工具说明与「报新号即换绑、同一人再报幂等」的实际行为对齐，身份边界写进本文与 SKILL.md。
npm install
npm run smoke:mcp
npm run smokesmoke 系列还有 smoke:store / smoke:menu / smoke:detail / smoke:order。 冒烟走真实只读接口（基础类 0.1 元/百次，10 万次/月免费额度内，单次复验不超过 30 次调用）。
代码部分（src/、scripts/、test/、配置文件）采用 Apache-2.0；文字部分（SKILL.md、README 及其他文档）采用 CC BY-ND 4.0。「李茶的茶」名称与标识归品牌方所有，不在任何许可证授权范围内。详见 LICENSE。
按店名、商场名或城市找李茶的茶门店，返回 storeId（看菜单/点单都要用）、营业状态；唯一命中时附营业时间。点单第一步先找店。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 店名/商场/城市，如「深圳湾」「太古里」「北京」 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It clearly describes the tool's behavior: queries by name/mall/city, returns storeId and status, and optionally business hours. No side effects are mentioned but none are implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. First sentence covers functionality and return values; second sentence provides critical contextual guidance ('first step of ordering').
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is adequately complete. It covers the input, output, and usage context. Could be slightly more specific about multiple matches, but the '唯一命中' condition implies this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for the query parameter. The description adds value by providing concrete examples ('深圳湾', '太古里', '北京') and clarifying that the query can be a store name, mall, or city.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool finds stores by name, mall, or city, and returns storeId and status, with business hours on unique match. Distinct from siblings (get_menu, get_item_detail, preview_order) which serve later ordering steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says '点单第一步先找店' (first step of ordering is to find the store), establishing the tool as the entry point. Could more explicitly state when not to use, but the context and sibling list make the guidance clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
看商品点单详情：规格（SKU）、做法（温度/糖度等）、加料、是否估清。goodsId 从 get_menu 结果里取。
| Name | Required | Description | Default |
|---|---|---|---|
| goodsId | Yes | 商品 ID（get_menu 返回的 goodsId） | |
| storeId | Yes | 门店 ID（先用 find_store 查；如深圳湾万象城=503542） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description lists data fields but does not mention side effects, read-only nature, authentication needs, or rate limits. Assumed safe read but not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence packs key information efficiently. Front-loaded with purpose and details, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple retrieval tool with good parameter descriptions, but lacks output format and any limitations or prerequisites beyond sibling hint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. Description does not add new semantic meaning beyond what schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves order details (specifications, preparation, add-ons, sold-out status) and links to get_menu via goodsId. Distinguishes from siblings like get_menu and preview_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage from mentioning goodsId from get_menu, but no explicit when-to-use or when-not-to-use compared to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
组单算预估总价（本地累加；实际金额以门店收银台/订单为准）。同组做法（如温度）只能选一个，估清商品会拦截。
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | ||
| storeId | Yes | 门店 ID（先用 find_store 查；如深圳湾万象城=503542） |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behaviors: local accumulation (not final), actual amounts may differ, constraints on practices, and blocking of sold-out items. Since no annotations are provided, the description carries full burden and does so adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core purpose, and each sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and no output schema, the description covers purpose, constraints, and estimation nature. It is complete enough for an agent to understand usage and limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, and the description adds some context (e.g., practices constraint) but does not significantly expand on the schema's parameter descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates an estimated total price for an order ('算预估总价'), specifies local accumulation, and distinguishes from siblings by focusing on price calculation rather than store or item lookups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use (for total preview) and provides constraints (same group practices only one, sold-out items block). However, it does not explicitly state when not to use or list alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0find_storeget_item_detailget_menupreview_orderScored across 4 tools
Each tool has a clearly distinct purpose: finding stores, getting menu, item details, and order preview. No overlap.
All tool names follow a consistent verb_noun pattern in snake_case (find_store, get_menu, get_item_detail, preview_order).
4 tools is well-scoped for a tea ordering server, covering the core workflow without unnecessary complexity.
The tools cover the full user journey from finding a store to previewing an order with item details, leaving no dead ends for its stated purpose.
MCP server for local business availability: in-stock items, open appointment slots and shop hours
MCP server for AI dialogue using various LLM models via AceDataCloud
MCP server for OnceAsk, the AI-native current-address layer for people and agents.
MCP server that lets your AI assistant build and deploy apps, hosting each one at a live URL.
