Loading ToolBench
Parse and validate postal addresses -- country detection, component split, postal code verification. US/UK/FR/DE.
Single tool 'address_validate' has a complete input schema with proper type and description, and an output schema is defined. Tool description is detailed (400+ chars) and includes use cases and anti-patterns. However, the description violates the rubric by embedding example values ('123 Main St, New York, NY 10001') which LLMs tend to reuse literally. The tool name lacks a clear action verb (should be 'validate_address' or 'parse_address'). Output schema is present but lacks descriptions for nested 'components' object properties. No error handling guidance or recovery patterns documented. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite being a READ_ONLY operation.
Use this when you need to parse, validate, or normalize a postal address. Returns structured address components in JSON. Returns: 1. components (street, city, state, postalCode, country) 2. valid (boolean) 3. normalizedAddress (formatted string) 4. detectedCountry and countryCode 5. postalCodeValid (boolean) 6. confidence score (0-1). Example output: {"address":"123 Main St, New York, NY 10001","valid":true,"components":{"street":"123 Main St","city":"New York","state":"NY","postalCode":"10001","country":"United States"},"normalizedAddress":"123 Main St, New York, NY 10001, US","detectedCountry":"United States","postalCodeValid":true,"confidence":0.95} Use this FOR CRM data cleaning, e-commerce checkout validation, shipping address normalization, and KYC address verification. Do NOT use for phone validation -- use phone_validate_number instead. Do NOT use for email validation -- use email_verify_address instead. Do NOT use for PII detection in text -- use compliance_detect_pii instead.
Tool name 'address_validate' lacks action verb prefix. Should be 'validate_address' or 'parse_address' to match verb_noun convention and improve LLM intent inference.
Description embeds concrete example values ('123 Main St, New York, NY 10001') which LLMs reuse literally instead of adapting to context. Replace with format constraints and enums.
Output schema 'components' object properties (street, city, state, postalCode, country) lack descriptions. LLMs cannot infer field semantics from names alone.
No error handling guidance. Tool description does not explain what happens on invalid input, malformed addresses, or unsupported countries. No recovery patterns documented.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | 2025-06-18+ | v2 |
Tool marked READ_ONLY but no tool annotations (readOnlyHint) present in schema. Annotations enable agents to reason about side effects and retry safety.