Loading ToolBench
MCP Server for exploring the Chinook SQLite database.
ChinookDBExplorer provides a single tool (run_sql_query) with minimal parameter documentation and no output schema specification. The tool name is verb-based (good), but the description lacks clarity about when to use it vs. other database tools, what the output format is, and error recovery guidance. The input parameter 'sql_query' has a basic description but no format constraints or examples of valid input beyond 'SELECT statements allowed.' No parameter describes error cases, retry behavior, or malformed query handling. The resource definitions (list_tables_schema, get_specific_table_schema) lack descriptions entirely in the MCP registration, forcing LLMs to guess their purpose. Prompts are defined but incomplete in the provided code (truncated). Overall: definitions exist but are sparse, inconsistent, and lack the LLM-optimization patterns expected in production tool interfaces.
Executes a read-only (SELECT) SQL query against the Chinook database. Only SELECT statements are allowed for safety.
Tool output schema not documented. The run_sql_query tool returns a formatted string (see line ~180 result_str += ...) but the MCP tool registration provides no schema documentation of the return value structure. LLMs cannot plan downstream operations or parse multi-line CSV-like output reliably without a documented return schema.
Parameter lacks format constraints and validation rules. The 'sql_query' parameter accepts any string but only validates at runtime (line ~172: 'if not sql_query.strip().upper().startswith("SELECT")). The description should state the format requirement explicitly: 'Must be a SELECT statement (case-insensitive). Dynamic values should be passed as bound parameters to prevent SQL injection.' No mention of max query length, complexity limits, or supported SQLite features.
Resource endpoints lack MCP descriptions. The @mcp_server.resource decorators for list_tables_schema and get_specific_table_schema have Python docstrings but those are NOT surfaced in the MCP resource schema (resource registration provides no description field in the shown code). LLMs cannot discover when to call these resources vs. the run_sql_query tool.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Error messages are generic and non-actionable. On SQL errors (line ~181: 'SQL Error: {e}'), the tool returns the raw SQLite error string. LLMs receive no guidance on how to fix the query, what types of queries are valid, or how to retry. Example: 'SQL Error: near "FORM": syntax error' tells the LLM nothing about valid syntax or alternative approaches. Should follow pattern: 'SQL syntax error in query: near "FORM". Verify table/column names exist (see resource://chinook/tables for schema) and use proper SQLite syntax.'
No pagination or result limits enforced. If a SELECT * from a large table is executed, the tool returns ALL rows formatted as a string (lines ~176-179). No limit parameter, no page/offset support, no cursor handling. A query returning 10,000 rows blows the context window. Should cap results (e.g., LIMIT 100) and document this in the description.
Parameter description is under 50 characters. 'The SQL SELECT query to execute.' lacks essential details: max length, required format, what errors look like, retry guidance, and when to use discovery resources first. Should be: 'A SELECT query against the Chinook SQLite database. Must start with SELECT (case-insensitive). Queries are read-only and safe. For schema discovery, use the resource://chinook/tables resource first. Errors indicate syntax or schema mismatches, see resource for valid table/column names.'