This is a read-only MCP server for browsing Licha's Tea (李茶的茶) stores, menus, and order previews; optionally enables real ordering when LICHA_ENABLE_ORDERING=1 is set.
find_store: Search stores by name, mall, or city; returns storeId, business status, and hours (when unique match).
get_menu: View a store's menu categories (no keyword) or product list (with keyword, e.g., item or category name).
get_item_detail: Get item ordering details: SKU specs, preparation options (temperature/sugar), add-ons, and availability (估清).
preview_order: Build an order and compute estimated total price (local sum; actual amount at store). Validates same-group practices and blocks sold-out items.
Default is read-only: No write tools are registered unless LICHA_ENABLE_ORDERING=1; then additional tools (bind_member, prepare_order, place_order, get_order_status, my_orders) become available, with strict safety constraints (two-phase confirmation, order limits, no payment delegation).
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@licha-order-mcp find me a Licas Tea store"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Li Cha's Tea · Qimai Ordering MCP Server. Lets AI find stores, browse menus, and build orders with pricing in conversation; when ordering is enabled it can also place real orders for customers, with payment always completed by the customer themselves in the Li Cha mini program.
Default install = read-only: without the switch, it behaves exactly like phase one — no orders are created, no money is touched, and no business data is read.
Say to your AI:
I want Li Cha's Tea, pull it from GitHub: lichadecha/licha-order-mcp
Once installed, just ask "what milk teas do you have" or "which store is closest to me". Currently only dine-in (in-store / takeout) is supported.
First time drinking and don't know what to pick? Just ask "any recommendations". If you want the AI to figure out which store is closest, you can also give it an AMap MCP (optional).
Related MCP server: @striderlabs/mcp-chipotle
Merge the following into your MCP config (mcpServers):
"licha-order-mcp": {
"command": "npx",
"args": ["-y", "github:lichadecha/licha-order-mcp#v0.5.1"]
}Install the SKILL.md from the repo root into your skills/instructions directory (when the client supports skills).
Restart or reload MCP as required by your client.
Tell the user it's installed, and start serving per the rules in SKILL.md (first sentence states: dine-in only, in-store/takeout).
Requires Node ≥ 18; auto-builds on first run (prepare → tsc). If npx isn't found, use the absolute path under the Node installation directory.
Tool | Purpose |
find_store | Find stores by name/mall/city, returns storeId, business status, business hours |
get_menu | View menu: no keyword returns categories, with keyword returns product list |
get_item_detail | Order card: specs, preparation (temperature/sugar), add-ons, whether sold out |
preview_order | Build an order and estimate total price (local accumulation; actual amount per store register/order) |
Setting the environment variable LICHA_ENABLE_ORDERING=1 additionally registers 5 ordering tools (bind_member / prepare_order / place_order / get_order_status / my_orders); security constraints are in the "Security boundary" section below.
mcpServers config:
{
"mcpServers": {
"licha-order-mcp": {
"command": "npx",
"args": ["-y", "github:lichadecha/licha-order-mcp#v0.5.1"]
}
}
}The install command is pinned to a version tag (#v0.5.1) and does not track the latest commit; when upgrading, use the tag given in the new README.
Requires Node ≥ 18; auto-builds on first install (prepare hook runs tsc).
This service reads Qimai Open Platform credentials from the local machine; credentials never enter this repo, config, or logs:
macOS keychain: the openKey of the qmai-cli entry (auto-unsealed)
~/.config/qmai/config.yaml: openId / grantCode of the active profile
Environment variable overrides are also supported: QMAI_OPEN_KEY / QMAI_OPEN_ID / QMAI_GRANT_CODE. When credentials are missing, tool calls report "incomplete credentials"; the service itself starts normally.
No write tools are registered by default (only with LICHA_ENABLE_ORDERING=1); when disabled, tools/list shows only the 4 read-only tools and the write path is physically unreachable.
When enabled, the write whitelist is hardcoded to exactly 1 entry (create order); anything outside the whitelist is physically cut off.
Ordering requires two-phase confirmation: the AI reads the pending order to the customer → customer confirms → then it is submitted; order parameters are assembled and registered server-side, and the AI only holds a 5-minute one-time token and cannot alter the order contents.
Hard guardrails: single order ≤¥100, per-customer ≤5 orders/day, global ≤10 orders/day; never pays on behalf of the customer — payment is always completed by the customer in the Li Cha mini program.
Three separate audit logs (read/write/access), with only the last digits of identifying values retained.
Outputs only project public fields (store name/address/business status/product price); business fields such as store manager contact info and costs are never output.
npm install
npm run smoke:mcp
npm run smokeThe smoke series also includes smoke:store / smoke:menu / smoke:detail / smoke:order. Smoke tests hit real read-only interfaces (base tier ¥0.1 per 100 calls, within the 100k calls/month free quota; a single re-verification uses no more than 30 calls).
The code portions (src/, scripts/, test/, config files) are licensed under Apache-2.0; the text portions (SKILL.md, README, and other documentation) are licensed under CC BY-ND 4.0. The "Li Cha's Tea" name and logo belong to the brand owner and are not covered by any license. See LICENSE for details.
按店名、商场名或城市找李茶的茶门店，返回 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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for AI dialogue using various LLM models via AceDataCloud
Hosted MCP server for live public-data APIs and Skills for AI agents.
Hosted MCP for e-commerce: live product catalog, stock, and pricing for AI agents.
MCP server providing access to the Scorecard API to evaluate and optimize LLM systems.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lichadecha/licha-order-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
