Loading ToolBench
Remote MCP server integrating Claude with Pancake POS API for managing shops, orders, warehouses, shipping, returns, conversations, and attachments across multiple channels (Facebook, Zalo, TikTok Shop, Website)
The server has 29 well-named tools with consistent verb_noun naming (get_, list_, create_, update_, search_, send_). All tools have descriptions (10-200+ chars). Input schemas are present and well-structured with type definitions and parameter descriptions. However, output schemas are not documented in the visible source code, and several parameter descriptions lack constraint details (enums, ranges, formats). Error handling guidance is minimal. Tool names follow established patterns well (e.g., 'search_orders', 'get_payment_methods', 'create_order'), and the tool set is well-composed with clear domain boundaries (shop management, orders, inventory, shipping, conversations, attachments). Parameter naming is consistent and descriptive (shop_id, order_id, customer_name). Most parameter descriptions are actionable ('The shop ID (get from get_shops tool).'), though some could be more explicit about constraints.
Prepare an order for shipping — hands off to a delivery carrier. Call this after confirming an order to create the shipment with the carrier.
Create a new order in Pancake POS.
Process a product return linked to an original order.
Create a new warehouse for a shop.
Download a specific attachment from a conversation message.
Generate page_access_token for sending messages. IMPORTANT: send_message requires page_access_token (not access_token). Call this tool first to get the token, then pass it to send_message.
Output schemas are not documented. The provided tool definitions show input schemas clearly but do not specify what fields and types the responses return. LLMs cannot plan downstream tool calls or extract data without knowing response structure (e.g., what does get_order return? Does it include order_id, customer_id, items? What are the field types?).
Enum constraints are missing for status and other enumerated fields. Tools like search_orders, update_order, update_conversation, and create_return_order accept 'status' parameters with examples ('new', 'confirmed', 'shipping', 'done', 'cancelled') but no formal enum constraint in the schema. This invites LLM hallucination of invalid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 55 | - | v1 |
Get currently active promotions applicable to a set of items.
List communes/wards within a district for address input.
Get full details of a single conversation including customer profile.
List districts within a province for address input. Use this to get district_id values needed for get_communes.
Get stock movement history (imports and exports) for a shop.
Get message history for a conversation.
Get full details of a single order including line items, customer, shipping.
List available order sources (e.g. Facebook, Zalo, Website, Phone). Use source_id when creating or filtering orders.
List all available order tags for a shop. Use tag names when filtering orders with search_orders.
List available bank payment methods configured for a shop.
List provinces/cities for address input. Use this to get province_id values needed for get_districts.
List all shops linked to the current Pancake account. Returns shop IDs, names, and linked channel pages. Use the returned shop_id values in other tools that require a shop_id parameter.
Get a tracking URL so the customer can monitor their delivery.
List conversations (inbox threads) for a connected channel page. Supports Facebook, Zalo, TikTok Shop, and Website channels. Use get_shops to find your shop's linked page_id values.
List all file attachments in a conversation or specific message.
List all connected pages/channels (Facebook, Zalo, TikTok Shop, Website). Use this tool to discover page_id values needed for other conversation tools. Only requires PANCAKE_ACCESS_TOKEN — no PANCAKE_API_KEY needed.
List return/exchange orders for a shop.
List all warehouses configured for a shop.
Search and filter orders for a shop.
Send a message or reply in a conversation. IMPORTANT: Requires page_access_token (NOT access_token). Call generate_page_access_token first to get the token.
Update a conversation — assign staff, add tags, change status.
Update fields on an existing order. Only provide the fields you want to change — unset fields are left unchanged.
Update warehouse details. Only provide fields to change.
Pagination limits are not formalized. search_orders, list_conversations, and list_message_attachments accept page and page_size parameters with examples and prose descriptions ('max 50', 'default 20') but no min/max constraints in schema. LLMs may pass invalid values (e.g., page_size=999).
Date format constraints are stated informally. Tools accepting 'from_date', 'to_date' describe them as 'YYYY-MM-DD' in prose but without a formal JSON Schema 'format' or 'pattern' field. LLMs may guess at timestamp formats instead of ISO 8601 strings.
Error recovery guidance is absent. Tools like create_order, create_warehouse, arrange_shipment, create_return_order, send_message define WRITE operations but provide no documented error handling or recovery instructions. If a call fails, the LLM has no guidance on whether to retry, ask the user, or escalate.
Parameter dependencies are not documented. create_order requires address + province_id + district_id + commune_id (a multi-step address tuple) but does not explicitly state that all four are required together. update_order suggests only some address fields may be updated, but it's unclear which combinations are valid.
JSON string parameters lack parsing guidance. create_order, get_active_promotions, and create_return_order accept 'items' as a JSON string (e.g., '[{"product_id": "123", "quantity": 2}]'). The description includes an example, but LLMs may struggle to construct valid JSON or may fail on escaping. Consider accepting a structured array parameter instead, or add explicit schema constraints on the JSON format.
Idempotency and retry semantics are not declared. WRITE tools like create_order, create_warehouse, send_message do not document whether repeated calls with the same input produce the same result or cause duplicate side effects. The absence of idempotentHint annotations leaves agents unsure about safe retry behavior.