Loading ToolBench
Provides tools to execute Databricks queries and compare table data.
Databricks MCP server has basic tool structure with adequate naming and descriptions, but lacks schema completeness, parameter validation guidance, and output documentation. Tools are well-named with action verbs (execute_, get_, compare_), and each has a non-empty description. However, input schemas are visible but minimal, most parameters lack type constraints, enums, or validation guidance. Output schemas are not documented. Error handling exists but provides generic responses without recovery guidance. The server implements 4 read-only tools with clear responsibilities, but falls short of production-grade quality due to incomplete schema documentation and missing parameter constraints.
Compare data between two Databricks tables.
Execute a SQL query on Databricks.
Get information about a Databricks table.
Quick metadata-only comparison between two Databricks tables.
No output schema documentation. Tools return dictionaries with 'success', 'error', 'data' fields, but LLMs cannot infer nested structure, field types, or downstream chaining requirements. Missing documented output schema violates tool-description pattern.
No input validation constraints. Numeric parameters (limit, diff_lines) lack min/max bounds. execute_query accepts any SQL string without validation guidance; LLMs may pass invalid SQL or injection payloads. Missing description of format, range, allowed values.
Table name parameters accept bare strings with no guidance on catalog.schema.table format. Optional catalog/schema parameters create ambiguity, description does not clarify how they combine or whether they are mutually exclusive with qualified names. Violates parameter-relationships pattern.
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 | 36 | - | v1 |
Error handling is generic. Code returns {'success': False, 'error': error_msg} with no guidance on whether error is retryable, what the LLM should do next, or what caused the failure. Missing error-classification and recovery-guide patterns.
Tool description for execute_query does not state that query is executed as-is on a remote Databricks service. Missing critical context: Is this read-only? Can it modify data? What happens if query fails? No mention of prerequisites (Databricks credentials must be configured).
compare_tables has similar tool quick_compare_tables with overlapping functionality. LLM must reason about which to call, descriptions do not clearly explain the difference ('Compare data between two tables' vs 'Quick metadata-only comparison'). Violates tool-chain clarity.