Loading ToolBench
MCP server that dynamically generates tools from an OpenAPI specification, with support for authentication and session management
Single tool 'greet' with minimal definition. Tool has a basic description (18 chars, below 20-char threshold) and a simple input schema with one string parameter. No output schema documented. No error handling guidance. The tool is trivial and does not reflect production patterns. Definition quality is severely limited by incomplete schema documentation and lack of actionable descriptions.
Greet a person by name
Tool description is too short (18 chars). Descriptions under 20 chars cannot adequately explain when/why to use the tool. Minimum 10 - 1024 chars required; target 50 - 200 chars for LLM clarity.
Output schema not documented. LLMs cannot plan downstream calls or extract return values without knowing the response structure. Must document return type and fields.
No error handling or recovery guidance. Tool lacks documentation of failure modes, retryability, or actionable error messages. LLMs cannot self-correct on failures.
Tool name 'greet' lacks action verb clarity. While 'greet' is a verb, it does not follow verb_noun convention (e.g., 'send_greeting', 'create_greeting'). Ambiguous for LLM tool selection.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 36 | <=2025-11-25 | v2 |
Parameter 'name' description is generic. Does not specify format, constraints, or examples. LLMs need explicit guidance: 'Full name (first and last, 1 - 100 chars)' vs bare 'The name of the person to greet'.