Loading ToolBench
A Model Context Protocol server that exposes JDBC data sources as tools for querying tables, retrieving columns, and executing SQL SELECT statements.
The CData JDBC MCP server provides 3 tools with clear READ_ONLY semantics and basic schema definitions. However, quality gaps are significant: (1) All tool descriptions lack critical guidance on WHEN to use each tool vs alternatives and what each returns structurally; (2) Parameter descriptions are minimal (1-3 words) with no constraints, ranges, or examples of valid input; (3) Output format is mentioned (CSV) but no structured schema is documented, LLMs must parse free-text CSV, which is error-prone; (4) Tool naming is clear (verb_noun pattern) but descriptions do not explain chaining relationships (e.g., get_tables output feeds into get_columns and run_query); (5) Error handling is present but generic (RuntimeException wrapping) with no actionable recovery guidance. Schema objects are visible and properly typed, but descriptions fall short of production quality. This server is functional but would benefit from richer documentation and structured output schemas.
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.
Output schemas not documented. All three tools return CSV text, but LLMs receive no structured schema definition describing the output format, fields, or expected column names. This forces LLMs to parse unstructured strings, increasing hallucination risk.
Parameter descriptions are trivial (1-3 words: 'The catalog name', 'The schema name', 'The table name', 'The SELECT statement to execute'). No guidance on format, constraints, valid values, or mutual exclusivity.
No guidance on tool chaining or dependencies. Descriptions mention '(use {prefix}_get_columns tool)' and '(use {prefix}_get_tables tool)' but do not explain when to call get_tables first, or what catalog/schema combinations are valid. LLMs cannot infer call sequencing.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 33 | 0.8.1+ | v1 |
Error handling is generic (RuntimeException wrapping with 'ERROR: ' prefix). No recovery guidance, error categorization, or actionable next steps. Try get_tables() first' vs bare 'ERROR: table not found'.
SQL dialect constraints mentioned in run_query description ('SQL-92', 'valid clauses: FROM, INNER JOIN, LEFT JOIN, GROUP BY, ORDER BY, LIMIT/OFFSET') but not enforced or validated. LLMs will attempt unsupported syntax. No input validation with clear error messages guiding correction.