李茶的茶・企迈注文 MCP サーバー。AIが会話の中で店舗を探し、メニューを見て、注文を組み立てて価格を計算します。注文機能を有効にした場合は、実際の注文も代行できますが、支払いは常に李茶のミニアプリでお客様自身が行います。
デフォルトインストール = 読み取り専用：スイッチを入れなければフェーズ1と完全に同じで、注文は発生せず、お金に触れず、経営データも読み取りません。
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.1"]
}このリポジトリのルートにある 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.1"]
}
}
}インストールコマンドはバージョンタグ（#v0.5.1）に固定されており、最新コミットは追跡しません。アップグレード時は新しいREADMEに記載されたタグに従ってください。
Node は 18 以上が必要です。初回インストール時に自動ビルド（prepareフックでtsc実行）が行われます。
本サービスはローカルマシンから企迈オープンプラットフォームの認証情報を読み取ります。認証情報はこのリポジトリ、設定、ログには含まれません：
macOSキーチェーン：qmai-cliエントリのopenKey（自動で開封）
~/.config/qmai/config.yaml：アクティブプロファイルのopenId / grantCode
環境変数で上書きすることも可能：QMAI_OPEN_KEY / QMAI_OPEN_ID / QMAI_GRANT_CODE。 認証情報がない場合、ツール呼び出しは「認証情報が不完全」とエラーを返しますが、サービス自体は正常に起動します。
デフォルトでは書き込みツールは一切登録されません（LICHA_ENABLE_ORDERING=1 でのみ登録）。未有効時、tools/list は読み取り専用ツール4つのみで、書き込み経路は物理的に到達不能です。
有効後も書き込みホワイトリストはハードコードで1件のみ（注文作成）。ホワイトリスト外はすべて物理的に遮断されます。
注文は必ず2段階確認を経ます：AIがまず確認待ちの注文を顧客に読み上げ → 顧客が確認 → その後送信。注文パラメータはサーバー側で組み立て・登録され、AIが持つのは5分間の使い捨てトークンのみで、注文内容を変更できません。
1件あたり ≤¥100、1日あたり顧客ごと ≤5件 / 全体 ≤10件のハードガード。代行支払いは絶対にしません——支払いは常に顧客が李茶のミニアプリで行います。
3つの監査ログ（読み取り/書き込み/アクセス）は分離され、識別値は末尾数桁のみ残します。
出力は公開フィールドのみを投影します（店名/住所/営業状態/商品価格）。店長の連絡先、原価などの経営フィールドは出力しません。
npm install
npm run smoke:mcp
npm run smokesmokeシリーズには smoke:store / smoke:menu / smoke:detail / smoke:order もあります。 スモークテストは実際の読み取り専用インターフェースを経由します（基本クラスは0.1元/100回、月10万回の無料枠内、1回の再検証で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.
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
