Loading ToolBench
MCP server for Databricks that provides SQL query execution and metadata discovery tools
This Databricks MCP server provides three well-named, read-only tools for querying a data source. Tool names follow verb_noun convention (get_tables, get_columns, run_query), which is excellent. However, the server suffers from several critical gaps: (1) Parameter descriptions are minimal and sometimes missing required context about format/constraints. (2) Output schemas are not explicitly documented, tools return CSV format but the structure is not formally declared in the response. (3) Error handling is generic (RuntimeException with message concatenation) and does not guide LLM recovery. (4) The tool descriptions lack actionable context about when to call each tool relative to others, dependencies, and expected formats. While the three tools are logically composed and cover a realistic query workflow (discover tables → inspect columns → execute query), the implementation falls short of production quality due to incomplete schema documentation and weak error messaging.
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 are not formally documented. All three tools return CSV format, but the response structure (column names, data types, pagination metadata) is not declared. LLMs cannot plan downstream tool calls or parse results reliably.
Error handling is generic and non-actionable. All tools throw RuntimeException with message concatenation (e.g., 'ERROR: ' + ex.getMessage()). Errors do not classify as retryable/user-fixable/fatal, do not suggest recovery steps, and do not provide the invalid input + constraint that was violated.
Parameter descriptions are sparse and lack actionable constraints. 'The catalog name' and 'The schema name' do not explain expected format, max length, case sensitivity, or what happens if the catalog/schema does not exist. For run_query, the sql parameter description lists valid clauses but does not mention query timeout, max result count, or SQL syntax dialect limitations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 34 | - | v1 |
Tool descriptions lack context about dependencies and ordering. The get_tables description says 'Use get_columns to list columns' but does not explain that you must call get_tables first to discover what tables exist. Agents without this sequencing guidance may call get_columns with invalid table names.
No pagination support documented. For get_tables and get_columns, there is no mention of limit, offset, page_size, or total_count in the response. If a catalog has thousands of tables, the agent receives all at once, potentially blowing context windows.
run_query lacks safety guardrails. There is no mention of SELECT-only enforcement, no dryrun capability, no query complexity limits, and no confirmation step for expensive operations. An agent could accidentally invoke a table scan on a 10GB dataset.