Loading ToolBench
快递100推出了国内首个兼容MCP协议的物流信息服务平台—快递100 MCP Server。 快递100旗下百递云·API开放平台的核心API服务现已全面支持MCP协议。开发者简单配置即可快速接入快递查询、运费预估、智能时效预估（含全程与在途模式）等核心功能。
Server provides 5 tools for logistics/delivery tracking via kuaidi100 API. All tools have descriptions (though in Chinese) and visible input schemas with parameter types. However, critical gaps exist: (1) no English descriptions for LLM optimization; (2) parameter descriptions are verbose and include example values, which LLMs tend to reuse literally rather than adapt; (3) no documented output schemas (though VO model classes exist in source, their fields are not shown); (4) missing error handling guidance; (5) tool names lack clear action verbs (query_trace, auto_number are somewhat ambiguous); (6) no per-tool success/failure handling for batch operations. The schemas are present and typed, preventing a lower score, but lack maturity for production agent deployment.
根据快递单号，返回可能的快递公司列表
通过快递公司、收寄件地址和重量，预估快递公司运费
通过快递公司编码、收寄件地址、下单时间、业务/产品类型来预估快递可送达的时间，以及过程需要花费的时间；用于寄件前快递送达时间预估
通过快递公司编码、收寄件地址、下单时间、历史物流轨迹信息来预估快递送达的时间；用于在途快递的到达时间预估
根据快递单号，返回对应的实时物流轨迹信息
All tool descriptions are in Chinese; LLMs trained primarily on English will struggle to parse intent and selection rationale. For non-Chinese agents, descriptions are non-functional.
Parameter descriptions include example values (e.g., '例如：广东省深圳市南山区', '例如：2023-08-08 08:08:08'). LLMs tend to reuse example values literally rather than adapting to context, causing failures with real data.
No documented output schemas. While VO model classes (QueryTraceVO, EstimateTimeVO, etc.) exist, their fields are not visible in the source excerpt and not documented for the LLM. Agents cannot predict response structure or plan chaining.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 58 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 59 | - | v1 |
Enumerated values (kuaidi_com, supported carriers) are embedded in parameter descriptions as free-form text rather than formal enum constraints. This invites hallucinated values and wastes the LLM's reasoning on parsing.
Tool names lack clear action verbs. 'query_trace' (should be 'get_trace'), 'auto_number' (should be 'detect_carriers'), 'estimate_time_with_logistic' (should be 'predict_arrival_with_history'). Vague names force LLM to read descriptions before understanding intent.
No error handling documentation. When an invalid kuaidi_com is passed, or API calls fail, the server response (from handle_json_response) is not shown. Agents have no recovery guidance.
estimate_time_with_logistic name contains 'and' conjunction ('time' AND 'logistic'), signaling mixed responsibilities. Should be split or renamed to 'predict_arrival_with_history' to avoid confusion with estimate_time.