An automated shipping workflow server that integrates with Qianniu (Alibaba seller backend) and logistics providers to automate order processing, waybill creation, and shipping label generation.
This server has CRITICAL definitional quality issues. While tool names follow verb_noun conventions reasonably well, parameter descriptions are sparse or missing entirely, output schemas are undocumented, and error handling provides no recovery guidance. Most tools lack the detail needed for confident LLM selection and invocation. The server implements 8 tools across workflow and logistics automation, but definitions are minimal and descriptions generic. Average tool description length is ~80 chars (well below the 194-char baseline), and most parameter descriptions are perfunctory or absent. Output schemas are not documented anywhere in the visible code. This is a D-grade implementation.
MCP Tool: Creates a shipping waybill.
MCP Tool: Downloads a shipping label (potentially redundant if create_waybill downloads).
MCP Tool: Executes the full automated shipping workflow for an order.
MCP Tool: Gets details for a specific order from Qianniu.
MCP Tool: Gets a list of pending orders from Qianniu.
MCP Tool: Logs into the logistics provider website.
Output schemas undocumented. Zero tools have documented return types. LLMs cannot predict what fields to expect or plan downstream tool calls. This violates the pattern:tool and pattern:response-shaper guidelines.
Tool descriptions too brief and generic. Average length ~50 chars (vs. 194-char baseline). No guidance on WHEN to use each tool, dependencies, or failure modes. Examples: 'Logs into the Qianniu seller backend' (45 chars), 'Creates a shipping waybill' (27 chars). These lack context for confident selection.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | <=2025-11-25 | v2 |
MCP Tool: Logs into the Qianniu seller backend.
MCP Tool: Marks an order as shipped in Qianniu.
No error handling or recovery guidance. Tools raise generic exceptions ('RuntimeError', 'ValueError') with messages in Chinese, but tool definitions include no guidance on error classification, retry eligibility, or next steps. Example: 'login_qianniu' can fail silently (success=False) but LLM has no guidance to retry or investigate.
Stateful tool design not documented. Tools rely on shared state dict (state['qianniu_logged_in'], state['order_details'], state['waybills']) but tool definitions never mention these prerequisites. Example: create_waybill requires order_details in state but parameter schema is silent. This forces agent to reason about hidden dependencies.
Irreversible operation (execute_shipping_workflow) has IRREVERSIBLE risk but no confirmation/dry-run option and no tool-level warning. Agents can accidentally invoke this without user consent. Tool description includes no guidance on consequences or reversibility.
Chinese error messages in tool responses. Example: 'Error in login_logistics tool' followed by Chinese text '登录物流公司网站失败'. LLMs may not reliably parse or translate these in real-time, causing errors to be invisible to the chat interface.
Tool composition issues. 'download_shipping_label' is marked as potentially redundant (per code comment), yet still exposed. 'execute_shipping_workflow' attempts to encapsulate an entire multi-step process (login → create → mark shipped) but parameter schema doesn't document the sequence or dependencies. This violates the pattern:tool single-responsibility principle.
Parameter descriptions lacking actionable constraints. Example: 'limit' in get_pending_orders has no min/max. 'logistics_company' has no enum or format. 'tracking_number' has no format hint. LLMs may pass invalid values; tool must validate and return actionable errors, but these are not documented.
No pagination documented for list tools. 'get_pending_orders' accepts 'limit' but no offset, cursor, or total_count. If results can exceed limit, LLM cannot discover all available orders or iterate reliably.