Loading ToolBench
MCP server for querying and introspecting a vehicle compliance database using SQL, with schema exploration and caching capabilities
Two read-only database tools with solid parameter schemas and reasonable descriptions. Both tools have explicit Zod-based input schemas with proper types and descriptions. However, descriptions are functional but not LLM-optimized per the rubric baseline (194 char average for A-tier tools). No output schema documentation is visible. Error handling returns JSON with error fields but lacks actionable recovery guidance. Tool composition is appropriate (one tool per concern), but naming could be more verb-forward ('query' is action-neutral; 'execute_sql_query' would be clearer). Schema completeness is good but output structure is undocumented.
Query compliance database. This tool allows querying the compliance database with SQL. Input should include a valid SQL query string and an optional 'noCache' flag. Results are returned in JSON format.
Retrieve database schema information, including tables, columns, data types, and relationships. Optionally, specify a table name to get details for a specific table.
Tool 'schema-introspection' uses a hyphenated name. While valid, the name is not action-forward. Compare 'get_table_schema' or 'describe_schema', these start with verbs and are clearer about intent.
Output schema is not documented. The 'query' tool returns JSON with 'source', 'result' fields; 'schema-introspection' returns 'table', 'columns', 'foreignKeys' structure. LLMs cannot plan downstream calls or extract fields without knowing the output contract. Add explicit output schema documentation (e.g., in JSDoc or a schema field).
Error responses lack actionable recovery guidance. When a query fails, the tool returns {error: true, message: '...'} but does not tell the agent what to do next. Per the rubric, errors should guide recovery: 'Invalid SQL syntax. Check the schema-introspection tool first to see available tables.'
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 57 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
The 'query' tool accepts raw SQL input with no injection protection documented. While the tool is read-only, the description should note constraints: 'Only SELECT queries are allowed; UPDATE/DELETE/INSERT will fail.' This prevents agents from attempting destructive queries.
Parameter descriptions are functional but brief (avg ~70 chars, rubric baseline 72 chars, but on the lower end). 'A valid SQL query string to execute against the compliance database' is clear but could be more prescriptive: 'A SELECT query against the compliance database. Supports standard SQL; mutations (UPDATE/DELETE/INSERT) are rejected. Max query length: 8000 characters.'
No pagination or result limiting is visible. If the compliance database is large, 'schema-introspection' without a table name could return thousands of columns/tables, exhausting the context window. Add a limit parameter (e.g., max 50 tables per response) and document it.