Loading ToolBench
MCP server for executing SQL queries and exploring metadata in Databricks Unity Catalog
This server implements 7 read-only tools for Databricks SQL with basic functionality but significant definition quality gaps. Tool naming follows verb_noun convention adequately (e.g., execute_sql, list_tables, describe_table), which is positive. However, descriptions are inconsistent in depth and quality. Most tools lack comprehensive parameter documentation, several parameters have minimal or missing descriptions. Input schemas are present but sparse: most tools accept simple string parameters with minimal constraint documentation. Error handling returns plain strings rather than structured error objects with recovery guidance. The server lacks pagination support on tools that could return large result sets (list_databases, list_tables, list_schemas, list_catalogs). Output is returned as free-form text strings rather than structured JSON, forcing LLMs to parse unstructured data. The wesley_farms-specific logic in execute_sql and get_table_relationships suggests domain customization but this is not well documented or abstracted.
Get schema information for a specific table.
Execute a SQL query on Databricks. When working with wesley_farms catalog tables, consider using get_table_relationships first to understand proper join logic.
Get predefined table join relationships from wesley_farms.gold.table_relationships. Use this when querying tables in the wesley_farms catalog to understand how tables should be joined together.
List all catalogs in the Unity Catalog metastore
List all databases/schemas in the Databricks workspace
List all schemas/databases in a specific catalog.
get_table_relationships has NO input schema definition, tool is registered with empty input dict {} but provides no parameters or constraints. Per HARD SCORING RULE, schema score MUST be 0.
list_databases and list_catalogs have NO input schema definitions (empty input dicts). Neither tool documents pagination, limit, or filter parameters, yet both could return large result sets. Schema score MUST be 0.
All tools return free-form text strings instead of structured JSON objects with typed fields. LLM must parse unstructured output to extract catalogs, schemas, tables, columns, and relationships. Violates pattern:response-shaper and wastes tokens.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
List all tables in a specific database.
Parameter descriptions are minimal or missing. 'database' param in list_tables and describe_table lacks context (is it case-sensitive? Does it accept paths like catalog.schema?). 'warehouse_id' in execute_sql says 'uses default if not provided' but does not document the environment variable name or failure mode if no default exists.
No pagination, limit, or offset parameters on tools returning lists. list_databases, list_catalogs, list_schemas, list_tables can return hundreds of items but offer no way to paginate. Large result sets blow context windows and degrade LLM reasoning.
Error handling is weak. All tools return plain string errors like 'Error: ...' instead of structured responses with recovery guidance. Pattern:recovery-guide expects LLM to know next steps, but errors are bare messages.
execute_sql accepts raw SQL input with no validation or injection safeguards. Parameter description says 'SQL query to execute' but does not warn about SQL injection risks or document allowed query types (SELECT only vs DDL/DML). LLM could be tricked into executing DELETE or ALTER statements.
Domain-specific logic (wesley_farms catalog references) is hardcoded in tool descriptions but not abstracted or configurable. 'Consider using get_table_relationships first' is a suggestion, not a requirement, and the table path is hardcoded in get_table_relationships source. This limits reusability.
Tool descriptions under 20 chars or too generic receive low scores. 'List all databases/schemas in the Databricks workspace' (50 chars) is borderline; 'List all catalogs in the Unity Catalog metastore' (50 chars) is better. But descriptions should explain WHEN to call each tool and HOW they differ from similar tools (list_databases vs list_catalogs vs list_schemas).