리차의 차 · 치메이 주문 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 | 주문 구성 및 예상 총액 계산(로컬 합산, 실제 금액은 매장 POS/주문 기준) |
환경 변수 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 keychain: qmai-cli 항목의 openKey(자동 복호화)
~/.config/qmai/config.yaml: active profile의 openId / grantCode
환경 변수로도 덮어쓸 수 있습니다: QMAI_OPEN_KEY / QMAI_OPEN_ID / QMAI_GRANT_CODE. 자격 증명이 없으면 도구 호출 시 '자격 증명 불완전' 오류가 발생하며, 서비스 자체는 정상적으로 시작됩니다.
기본적으로 쓰기 도구는 등록되지 않습니다(LICHA_ENABLE_ORDERING=1일 때만 등록). 미활성화 시 tools/list에는 읽기 전용 도구 4개만 있으며, 쓰기 채널은 물리적으로 접근 불가능합니다.
활성화 후 쓰기 화이트리스트는 하드코딩으로 1개(주문 생성)만 있으며, 화이트리스트 외에는 모두 물리적으로 차단됩니다.
주문은 반드시 2단계 확인을 거칩니다: AI가 먼저 확인 대기 주문을 고객에게 읽어주기 → 고객 확인 → 제출. 주문 파라미터는 서버 측에서 조립·등록하며, AI는 5분 일회용 토큰만 보유하므로 주문 내용을 변경할 수 없습니다.
건당 ≤¥100, 일일 고객당 ≤5건 / 전체 ≤10건 하드 가드레일; 절대 대신 결제하지 않음 — 결제는 항상 고객이 리차 미니프로그램에서 완료합니다.
3개의 감사 로그(읽기/쓰기/접근)가 분리되어 있으며, 식별 값은 끝자리만 남깁니다.
출력 파라미터는 공개 필드(매장명/주소/영업 상태/상품 가격)만 표시하며, 점장 연락처, 원가 등 영업 필드는 출력하지 않습니다.
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.
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
