Loading ToolBench
Single tool with minimal schema, vague output documentation, and poor error handling. The verify_email tool has a basic input parameter but lacks output schema documentation, parameter descriptions, and proper error guidance. The tool description states returns 'true' or 'false' but actual code returns error strings like 'Error: Unable to verify email', creating a contract mismatch. No input validation, no recovery guidance for failures, and no structured error classification.
Verify an email address using the 2ip.me API. Args: email (str): The email address to verify Returns: str: "true" or "false" indicating if the email is valid
Output schema completely undocumented. Tool description claims returns 'true' or 'false' string, but implementation can return 'Error: Unable to verify email', contracts don't match. LLM cannot plan downstream handling or parse response structure.
Parameter description is generic and incomplete. 'The email address to verify' lacks format specification, validation rules, or examples of valid input. Does not state if it validates formatting before API call, or if the 2ip.me API handles that.
Error handling provides no recovery guidance. When API fails, tool returns 'Error: Unable to verify email', tells LLM nothing about whether to retry, contact support, or try a different validation approach. No error classification (retryable vs fatal).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 37 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 28 | - | v1 |
Tool description contradicts implementation. Claims returns 'true' or 'false' but code returns error message on failure. This contract violation forces LLM to guess about actual response format and handle unexpected strings.
No input validation or constraint documentation. Tool accepts any string as email parameter. Should validate format, length, and character constraints before making external API call. No length bounds specified.
External API timeout handling is implicit (30.0s timeout set but not documented). LLM unaware of timeout behavior, may not know to retry or that operation timed out vs permanently failed.