Loading ToolBench
Single tool 'query' has a basic description (67 chars) and minimal schema. Input schema present with type and description for 'sql' parameter, but output schema is undocumented, LLMs cannot predict return structure. No error handling guidance, no parameter constraints (e.g., max query length, timeout), and no security warnings about SQL injection risk. Tool name 'query' is generic and does not follow verb_noun convention (should be 'execute_query'). No pagination, no result limits documented, and no guidance on when to use this tool vs. alternatives. Lacks idempotency guarantees and confirmation patterns for destructive queries.
Execute a SQL query against the connected SQL Server database
Generic tool name 'query' does not follow verb_noun convention. Should be 'execute_query' or 'execute_sql_query' to clarify intent and enable LLM disambiguation.
Output schema is completely undocumented. LLMs cannot predict the structure of results (array of objects? raw JSON string? error object?). Must document return type: e.g., {type: 'array', items: {type: 'object'}, description: 'Array of result rows as objects with column names as keys'}.
No input validation or constraints. Parameter 'sql' accepts any string with no length limit, timeout, or SQL injection safeguards documented. Must add: max length (e.g., 10000 chars), timeout (e.g., 30s), and security note: 'Validate/sanitize user input to prevent SQL injection.'
No error handling guidance. Tool catches errors and returns them as plain text in response, but does not categorize as retryable/user-fixable/fatal or suggest recovery steps. E.g., 'Connection timeout, retry in 5s' vs bare 'Error executing query: ...'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 43 | 2026-07-28+ | v2 |
No result limits or pagination. Large result sets will blow context window. Must document: 'Results capped at 1000 rows. For larger datasets, use WHERE/LIMIT clauses or call multiple times with pagination logic.'