Loading ToolBench
MCP server that provides tools for querying and exploring data sources via JDBC, with support for Azure Data Lake Storage and other SQL-compatible databases
This Azure Data Lake Storage MCP server defines 3 tools with basic structure but significant gaps in parameter descriptions, output documentation, and error handling. Tool names follow a clear verb_noun pattern (get_*, run_*), which is good. However, parameter descriptions are minimal ('The catalog name', 'The schema name'), and output schemas are completely undocumented, the description states 'output will be returned in CSV format' but there is no formal output schema definition. Error handling is absent: exceptions are caught and re-thrown as generic RuntimeExceptions with no guidance for recovery. The server uses STDIO transport only, which is a hard cap at 50. Schemas are present but incomplete: GetTablesTool and GetColumnsTool have optional parameters defined, but RunQueryTool has only a single 'sql' parameter with no constraints or format guidance. No pagination support, no rate limiting, no permission checks, and no idempotence guarantees. The code quality is functional but production-grade servers require richer documentation and defensive error handling.
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 completely undocumented for all three tools. Descriptions state 'CSV format' but provide no field names, types, or structure. LLMs cannot plan downstream calls or extract data without knowing what fields are returned.
Error handling is absent. Exceptions are caught and re-thrown as generic RuntimeExceptions ('ERROR: ' + message). No guidance for recovery, no distinction between retryable and fatal errors, no suggestion of alternative tools if a lookup fails.
Parameter descriptions are generic and non-actionable. 'The catalog name', 'The schema name', 'The table name' do not explain format constraints, valid ranges, or when they are required vs optional. For run_query, 'The SELECT statement' buries critical dialect and clause information that should be structured constraints.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 38 | - | v1 |
No pagination, result limiting, or validation. GetTablesTool and GetColumnsTool can return unlimited rows. RunQueryTool accepts any SQL SELECT but has no timeout, row limit, or complexity constraint. Large result sets will blow context windows.
RunQueryTool does not validate that only SELECT statements are executed. If an attacker (or confused agent) passes UPDATE, DELETE, or DROP, the tool will execute it. Missing input validation and destructive operation guard.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Clients cannot infer which tools are safe to call speculatively or which require confirmation. All three tools appear to be read-only but are not explicitly marked as such.
STDIO-only transport. The server cannot be accessed remotely or by hosted MCP clients (e.g., Claude.dev, LangChain Cloud). Limited to local process communication only.