Loading ToolBench
An MCP server that provides tools for querying HDFS and other data sources via JDBC, enabling discovery and querying of tables and columns
This HDFS MCP server has 3 well-defined tools with proper schemas and descriptions, but exhibits moderate gaps in parameter descriptions, output schema documentation, and error handling guidance. Tool names follow verb_noun convention (get_*, run_query) which is good. Descriptions are present and exceed the 20-character minimum, but lack explicit guidance on error recovery and output structure. Schemas include proper types and required constraints, but output schemas are not formally documented. Error handling relies on generic RuntimeException rather than actionable recovery guidance. The server is STDIO-only, which applies a hard cap of 50 to protocol readiness but does not directly affect definition quality scoring.
Retrieves a list of fields, dimensions, or measures (as columns) for an object, entity or collection (table). Use the `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 `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 schema not formally documented. Tools return CSV format but LLMs cannot infer column structure, data types, or whether pagination is supported. This forces agents to parse unstructured responses.
Error handling uses generic RuntimeException without recovery guidance. Exception messages like 'ERROR: <message>' provide no actionable path for the LLM, no suggestion to retry, check parameters, or call a discovery tool first.
Parameter descriptions lack format/constraint details. 'catalog', 'schema' parameters have minimal guidance, e.g., are they case-sensitive? Do they support wildcards? Required? Optional but filters results? These ambiguities force LLMs to guess.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 36 | - | v1 |
run_query description references tools that may not exist ('run_query_get_tables', 'run_query_get_columns'). The description mentions using these tools, but they are not registered, only 'get_tables' and 'get_columns' exist. This creates a factual error in the description.
Result limiting not documented. If a query matches thousands of rows, the response size is unbounded and could exhaust context windows. Tool descriptions do not mention a result limit or pagination strategy.
SQL dialect constraints mentioned in run_query description but not enforced by schema. LLMs given incomplete info on which SQL clauses are supported (FROM, INNER JOIN, LEFT JOIN, GROUP BY, ORDER BY, LIMIT/OFFSET), will they try SELECT * FROM t1, t2 or will that fail silently?