Loading ToolBench
A WebMCP snippet that lets an AI agent check a sales team's availability and get a rep on the phone with the visitor.
Two tools with minimal definitions. Tool 1 (callingly-check-sales-availability) has empty input schema {} and vague 18-char description. Tool 2 (callingly-request-sales-call) has a proper input schema with 6 parameters, but descriptions are inconsistent: some params lack descriptions entirely (fname, lname, email, company, comments show only type+optional flag, no guidance on format or purpose). Both tool descriptions are under 50 chars and lack context on when to use them, what they return, or error recovery paths. No output schemas documented. No error handling guidance visible in source.
read-only; hours + can they talk now
rings the team and bridges the visitor
Tool 1 has empty input schema ({}). No parameters documented means LLM cannot understand what data the tool accepts or requires.
Tool 1 description is 18 characters ('read-only; hours + can they talk now'). Lacks WHAT it does, WHEN to use it, and what it returns. LLM cannot determine when to select this tool.
Tool 2 parameters fname, lname, email, company, comments lack descriptions. LLM cannot infer whether 'fname' is required, what format it expects, or how it's used.
No output schemas documented for either tool. LLM cannot plan downstream actions or extract required fields. Tool 2 returns a 202 response with fields like 'accepted', 'team', 'phone_number', 'dialing_now', 'message' (visible in demo/server.js), but this structure is not declared in the tool definition.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 31 | 2026-07-28+ | v2 |
No error handling guidance. Demo server returns 422 with validation errors (invalid phone format), but tool definitions do not document error cases, recovery steps, or what the LLM should do if a call fails.