Loading ToolBench
A Model Completion Protocol (MCP) server for Databricks that provides tools for interacting with Databricks APIs including cluster management, job execution, notebook operations, DBFS file management, and SQL execution
This server exhibits significant gaps in definition quality. All 11 tools have names following the verb_noun pattern (list_*, create_*, etc.), which is correct. However, parameter descriptions are extremely generic and do not explain constraints, formats, or dependencies. Output schemas are not documented at all, LLMs cannot infer what fields are returned or how to chain tool calls. Descriptions are present but lack the specificity needed for confident LLM selection (they mostly restate the tool name). Error handling guidance is absent, no recovery instructions, no classification of errors as retryable/user-fixable. The tools handle sensitive operations (cluster termination, SQL execution, credentials) without documented security gates or audit trails. According to the rubric baseline, 94% of A+ tools have docstrings with LLM-optimized length (50-200 chars); this server's descriptions are closer to 50-100 chars but lack actionable detail. Parameter validation rules are not visible in the definitions. The server is STDIO-only, which imposes a hard cap of 50 on protocol readiness; this assessment reflects that constraint.
Create a new Databricks cluster with parameters: cluster_name (required), spark_version (required), node_type_id (required), num_workers, autotermination_minutes
Execute a SQL statement with parameters: statement (required), warehouse_id (required), catalog (optional), schema (optional)
Export a notebook from the workspace with parameters: path (required), format (optional, one of: SOURCE, HTML, JUPYTER, DBC)
Get information about a specific Databricks cluster with parameter: cluster_id (required)
List all Databricks clusters
List files and directories in a DBFS path with parameter: dbfs_path (required)
No output schemas documented. LLMs cannot infer what fields tools return, preventing confident downstream tool chaining and data extraction.
Parameter descriptions lack constraint specification. No mention of valid ranges, enum values, formats, or dependencies. E.g., 'num_workers (optional)' does not state minimum/maximum, and 'notebook_params (optional)' does not explain the expected object structure.
Destructive/sensitive operations lack error handling guidance and confirmation patterns. terminate_cluster and execute_sql can cause data loss, but neither tool description mentions dry-run, confirmation, or recovery steps.
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 | 40 | 1.2.0+ | v1 |
List all Databricks jobs
List notebooks in a workspace directory with parameter: path (required)
Run a Databricks job with parameters: job_id (required), notebook_params (optional)
Start a terminated Databricks cluster with parameter: cluster_id (required)
Terminate a Databricks cluster with parameter: cluster_id (required)
No pagination parameters or result limits documented. list_clusters, list_jobs, list_notebooks, list_files could return hundreds of items, which wastes tokens and risks context window exhaustion. No mention of limit, offset, or result count caps.
Credentials and secrets appear to be handled via environment variables (DATABRICKS_HOST, DATABRICKS_TOKEN), but tool definitions do not document this. No explicit statement that credentials are server-injected, not passed as parameters. This is correct but undocumented.
Tool descriptions are generic and do not include actionable context for LLM selection. E.g., 'Create a new Databricks cluster' does not explain when to use this vs. start_cluster, what prerequisites exist, or what the typical workflow is.
No permission gates or audit trail documented. Tools that write, delete, or execute code should declare required permissions and log who called them. Current definitions are silent on this.