Loading ToolBench
MCP Server with tool registration, permission policies, audit logging, and human confirmation workflow for tool execution
Four tools with mixed quality. All have descriptions (positive), but descriptions are brief (avg ~50 chars, below 194-char baseline). Tool names follow verb_noun pattern (echo, get_confirmation_status, now, forecast) but lack clarity on when to use each. Input schemas present but minimal, parameters have types and descriptions, but no enums, ranges, or validation constraints. Output schemas not documented. No error handling guidance. Tool composition is reasonable (single responsibility), but parameter descriptions are terse and lack context. Overall: below-average community server quality.
回显收到的消息，作为网关连通性自检工具
查询指定城市的明日天气预报（演示用假数据）
Get the status of a pending confirmation
返回服务器当前时间（ISO-8601）
Descriptions are too brief (avg ~50 chars vs 194-char baseline). 'Get the status of a pending confirmation' and '返回服务器当前时间（ISO-8601）' lack context on WHEN to call, WHAT to expect, and HOW to use the result. LLMs cannot reliably select tools without richer guidance.
No output schemas documented. Callers cannot know what fields to expect from each tool's response. This forces LLMs to guess at downstream field names and risks broken tool chains.
Parameter 'offset' in 'now' tool lacks validation constraints. Description says 'optional, e.g. +08:00' but does not specify format (regex), range, or error handling for invalid timezones. LLMs may pass malformed values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | 2026-07-28+ | v2 |
Tool 'forecast' returns 'demo fake data' per description but does not document the response structure or warn that results are not real. Agents may treat mock data as authoritative.
No error handling guidance. Tools do not document what happens on invalid input (e.g. unknown city in forecast, invalid confirmationId). LLMs have no recovery path.