Loading ToolBench
Both tools have minimal descriptions (under 100 chars) and lack parameter descriptions entirely. Input schemas are present but extremely sparse, only a 'query' string with no type constraints, enums, or validation guidance. No output schemas documented. Error handling is ad-hoc (returns bool or string). The add_data tool accepts raw SQL input, creating SQL injection risk. fetch_data lacks pagination despite potentially returning large result sets. No tool annotations (readOnlyHint, destructiveHint). Naming is verb-based but descriptions are too terse to guide LLM selection.
Execute an INSERT query to add a record to the database.
Execute a SELECT query to return records. Pass 'all' or empty string to get everything.
SQL injection vulnerability: add_data accepts raw 'query' string parameter with no sanitization. LLMs can be tricked into passing malicious SQL. Parameter description missing entirely.
Parameter descriptions completely absent. 'query' parameter in both tools lacks explanation of expected format, constraints, or examples. LLMs cannot infer whether to pass SQL, natural language, or structured input.
No output schema documented. add_data returns bool or error string (inconsistent type). fetch_data returns list but no field structure specified. LLMs cannot plan downstream operations.
fetch_data lacks pagination. No limit, offset, or page parameters. Unbounded result sets can exhaust context window. Baseline: paginated tools accept limit (1 - 100) and return total_count.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 40 | 2026-07-28+ | v2 |
No tool annotations. add_data (destructive write) and fetch_data (read-only) lack destructiveHint and readOnlyHint. LLMs cannot distinguish safe from unsafe operations.