Loading ToolBench
MCP server for querying Cloudant databases via JDBC. Provides tools to list tables, retrieve column metadata, and execute SQL queries.
Three read-only SQL/metadata tools with basic but incomplete definitions. Tool names follow verb_noun pattern correctly (get_tables, get_columns, run_query). Descriptions exist but are generic and lack LLM-optimization guidance. Parameter schemas are present with type declarations and descriptions, but several critical quality gaps: (1) no output schema documentation despite returning CSV data; (2) parameter descriptions do not specify format constraints, enums, or error recovery paths; (3) descriptions under 200 chars lack depth on WHEN to use each tool and what prerequisite discovery steps are needed; (4) no error handling guidance or recovery patterns; (5) composition assumes LLM knows internal discover-then-query flow but doesn't document it. The tool for run_query accepts free-form SQL, which invites injection risk without explicit validation guidance. Overall, these are functional discovery/query tools but lack the polish needed for production agent integration.
Retrieves a list of fields, dimensions, or measures (as columns) for an object, entity or collection (table). Use the `{prefix}_get_tables` tool to get a list of available tables. The output of the tool will be returned in CSV format, with the first line containing column headers.
Retrieves a list of objects, entities, collections, etc. (as tables) available in the data source. Use the `{prefix}_get_columns` tool to list available columns on a table. Both `catalog` and `schema` are optional parameters. The output of the tool will be returned in CSV format, with the first line containing column headers.
Execute a SQL SELECT statement.
No output schema documentation. All three tools return CSV but no structured schema is documented for LLM planning or field extraction.
Parameter descriptions lack formal constraints and format guidance. E.g., 'schema' parameter has no enum, regex pattern, or length limit documented. LLMs cannot parse JSON Schema constraints in code, they rely on description text.
No error handling or recovery guidance. Tools throw RuntimeException on failure with generic 'ERROR: ' prefix. Descriptions do not explain what could go wrong (e.g., 'If table not found, call get_tables() first') or how to recover.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 36 | - | v1 |
SQL injection risk not addressed. run_query accepts free-form 'sql' parameter. Description mentions 'SELECT' scope but does not explicitly warn against injection or document input validation. No sanitization guidance in parameters or error section.
Composition and discovery flow not documented. LLM must infer that get_tables → get_columns → run_query is the intended workflow. No 'Call this first' or dependency hints in descriptions.
Parameter optionality not clearly signaled in descriptions. Code shows catalog/schema are optional for get_tables and get_columns, but descriptions do not use language like '[optional]' or 'omit if not applicable' that LLMs reliably parse.