Loading ToolBench
Two tools with basic schemas and minimal descriptions. Both tools lack parameter descriptions entirely, critical gap per pattern:tool-description. Naming is generic ('lookup', 'batch') without action verbs. No output schema documentation. No error handling guidance. Parameter 'fields' and 'lang' are undescribed, forcing LLMs to guess their purpose. The 'ip' parameter in lookup lacks a description explaining it defaults to caller IP. Batch tool requires 'ips' but other params are optional without clear defaults. No pagination, rate-limit, or result-limit guidance despite calling an external API.
Bulk lookup (max 100 IPs).
Geolocation for an IP (or caller if ip omitted).
All input parameters lack descriptions. 'fields', 'lang', and 'ip' have no explanation of what they control, expected format, or valid values. LLMs cannot infer parameter semantics from names alone.
Tool names do not start with action verbs. 'lookup' and 'batch' are generic nouns. Should be 'get_geolocation' or 'lookup_ip' and 'batch_lookup_ips' to signal intent clearly.
No output schema documented. LLMs do not know what fields to expect from ip-api.com responses (country, city, lat, lon, etc.). This prevents downstream tool chaining and forces LLMs to guess field names.
No error handling guidance. If ip-api.com returns 429 (rate limit), 400 (invalid IP), or 5xx, the LLM receives a raw error message with no recovery path. Should return actionable errors like 'Rate limited. Wait 60s before retry.' or 'Invalid IP format. Expected dotted-quad IPv4 or IPv6.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 37 | 2026-07-28+ | v2 |
Batch tool accepts unbounded array of IPs. Description says 'max 100 IPs' but schema does not enforce this constraint. LLMs may pass 500 IPs, causing API rejection. Schema should include maxItems: 100.