Loading ToolBench
A Model Context Protocol server for querying express/courier logistics information and comparing prices across multiple courier companies
Both tools have basic schemas and descriptions, but fall short of production quality. Descriptions are present but minimal (Chinese text, 10-20 chars when translated). Schemas are properly typed with required fields, but lack depth in parameter descriptions. No error handling guidance, no output schema documentation, and no indication of idempotency or side effects. Tool names lack clear action verbs in English context. Missing validation rules, ranges, and format constraints for numeric parameters (weight, length, width, height have no min/max). No pagination support despite potential for large result sets. Security: auth_key passed as CLI argument rather than environment variable.
查询多个快递公司快递价格
实时查询快递物流信息
Minimal parameter descriptions. 'com' described as '快递公司名称或快递编码' (company name or code) lacks format guidance. 'weight', 'length', 'width', 'height' have no units, ranges, or validation rules. LLMs cannot infer whether weight is in kg, lbs, or grams.
No output schema documented. Callers cannot predict response structure. Tool returns JSON.stringify(result) as plain text, not structured fields. LLMs cannot extract specific values for downstream tool calls.
Credentials exposed as CLI arguments. auth_key and customer passed via --auth_key=... and --customer=... flags, which appear in process listings and logs. Should use environment variables or vault injection.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 37 | 2026-07-28+ | v2 |
No error recovery guidance. Tool throws generic Error('请输入快递公司名称或编码') without suggesting next steps. LLM receives error but has no actionable path forward.
Numeric parameters unbounded. weight, length, width, height accept any number with no min/max constraints. LLM could pass negative values, zero, or absurdly large numbers (e.g. 999999 kg) without validation.