Loading ToolBench
Server has 4 tools with basic registration but significant quality gaps. All tools have descriptions (10-50 chars, below the 50-200 char baseline for LLM optimization) and input schemas, but schemas are minimal and lack parameter descriptions. execute_sql has a critical security issue: it accepts arbitrary SQL without validation or safeguards. No output schemas documented. Error handling is generic ('SQL execution failed: {error.message}') with no recovery guidance. Tool names follow verb_noun convention (good), but descriptions are too terse to guide LLM selection. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels (WRITE vs READ_ONLY).
Describe the structure of a specific table
Execute a SQL query on DaMeng database
Get information about the database schema
List all tables in the database
execute_sql accepts arbitrary SQL with no validation, sanitization, or injection protection. LLM can be tricked into SQL injection attacks. No dry-run or confirmation step for destructive operations.
Tool descriptions are 10-50 characters (baseline 50-200 chars). Too terse to guide LLM selection. E.g., 'List all tables in the database' lacks context on when to call it vs describe_table or get_schema_info.
Input schemas lack parameter descriptions. 'sql' parameter has no guidance on format, length limits, or allowed statement types. 'table_name' has no hint on case sensitivity or schema qualification.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
No output schemas documented. LLM cannot predict response structure (fields, types, pagination). Responses are JSON-stringified text blobs, not structured objects.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels. execute_sql is marked WRITE but has no destructiveHint. Agents cannot distinguish safe from unsafe tools.