Loading ToolBench
Expose phone calling as tools for AI agents. Give your AI agent the ability to make phone calls. The 'browser-use' for phones.
Server has 4 tools with basic schemas and descriptions, but significant gaps in parameter documentation and error guidance. Tool names are action-oriented (dial, status, cancel, result) and descriptions exist, but many parameters lack type constraints and descriptions are generic. The 'dial' tool description is notably verbose (>200 chars) and includes implementation details (MCP mode limitation) rather than user-facing guidance. No output schemas documented. Error handling is minimal, no recovery guidance or categorization. Parameter validation rules are mentioned in code but not exposed in schemas.
Cancel an active phone call.
Dispatch an outbound phone call via AI agent. Returns immediately with a task_id. The call runs asynchronously. Use 'status' to poll progress, 'cancel' to abort, and 'result' to retrieve the final outcome once the call completes. Note: Pre-call approval is not available in MCP mode because MCP tools are non-interactive (no stdin for approval prompts). If you need approval before dialing, use the call-use SDK or REST API instead.
Retrieve final CallOutcome from room metadata.
Check the current state of a phone call.
Parameter descriptions are minimal or missing. 'task_id' appears in 3 tools with identical 1-line descriptions; 'phone' lacks format validation guidance; 'voice_id' lists options but no description of what voice_id controls. LLMs cannot infer parameter semantics from names alone.
No output schemas documented. Tools return JSON but structure is not specified. 'dial' returns task_id; 'status' returns state; 'result' returns CallOutcome, but field names, types, and required fields are not declared. LLMs cannot plan downstream calls without knowing response structure.
Error handling lacks recovery guidance. Code validates inputs (MAX_INSTRUCTIONS_LENGTH, VALID_VOICES, timeout bounds) but returns generic error dicts without actionable next steps. E.g., 'Invalid voice_id' should suggest valid options; missing env vars should link to setup docs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
Parameter 'user_info' accepts 'optional JSON string' but no schema or validation rules are exposed. LLMs cannot know what fields are valid, required, or expected. Should either accept a structured object or document the JSON schema inline.
Tool descriptions conflate implementation details with user intent. 'dial' description mentions 'MCP mode' and 'non-interactive', these are server concerns, not user-facing. Description should focus on WHAT the tool does (make a call) and WHEN to use it (when you need to reach someone by phone).