Loading ToolBench
Critical failures across all dimensions. All 6 tools have descriptions that are HTTP method + path only (e.g., 'POST /pet'), far below the 10-character minimum for meaningful descriptions. No parameter descriptions exist, all 'description': null in schemas. Tools lack semantic naming (add_pet vs create_pet); naming does not convey intent clearly. No output schemas documented. Error handling is minimal (raw HTTP status + text). This is a code-generation artifact, not a production-ready MCP server.
POST /pet
GET /pet/findByStatus
GET /pet/findByTags
GET /pet/{petId}
PUT /pet
POST /pet/{petId}
All tool descriptions are HTTP method + path only (e.g., 'POST /pet'). No semantic description of what the tool does, when to use it, or what it returns. Violates pattern:tool-description baseline of 10 - 1024 chars with meaningful content.
All parameter descriptions are null. LLMs cannot infer parameter meaning from names alone (e.g., 'status' could mean HTTP status, pet status, or boolean). Violates pattern:tool-description requirement that every input parameter have a non-empty description.
No output schemas documented. LLMs cannot plan downstream tool calls or extract required fields. Violates pattern:tool baseline that 100% of A+ tools have documented return types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 33 | 2026-07-28+ | v2 |
Error handling returns raw HTTP status + response text. No guidance on what to do next, whether to retry, or how to self-correct. Violates pattern:recovery-guide requirement that errors tell the LLM what to do next.
Naming inconsistency: 'add_pet' and 'update_pet' lack clear verb-noun structure; 'update_pet_with_form' is verbose and unclear. 'find_pets_by_*' uses 'find' instead of canonical 'search' or 'list'. Violates pattern:tool baseline that 90% of A+ tools start with action verbs.