MCP server for executing SQL queries against Databricks and exploring Unity Catalog metadata
This server provides 8 tools for querying and exploring Databricks metadata. Strengths: all tools have descriptions and clear naming following verb-noun conventions (execute_, list_, describe_). All inputs have type definitions. Weaknesses: descriptions lack guidance on WHEN to use each tool vs others, parameters lack detailed constraints or format specifications, no output schemas are documented, error handling is minimal (generic try-catch blocks returning plain strings), and tools are read-only with no confirmation patterns despite catalog operations. Parameter descriptions are sparse, most are single-line (e.g., 'The catalog name to list schemas from'). Output is unstructured text, making downstream chaining impossible. No pagination support despite potential for large result sets. The include_lineage parameter on describe_uc_table has meaningful guidance, but this is an exception.
Describe a table's schema.
Get a summary of a specific Unity Catalog, listing all its schemas. Use this tool when you know the catalog name and need to discover the schemas within it. This is often a precursor to describing a specific schema or table.
Get detailed information about a specific schema within a Unity Catalog. Use this tool to understand the contents of a schema, primarily its tables. Set `include_columns=True` to get column information, which is crucial for query construction but makes the output longer.
Get detailed description of a specific Unity Catalog table. Use this tool to understand the structure (columns, data types, partitioning) of a single table. This is essential before constructing SQL queries. Optionally includes comprehensive lineage information: - Upstream tables (tables this table reads from) - Downstream tables (tables that read from this table) - Notebooks that read from or write to this table with job details
Execute a SQL query on Databricks and return the results.
Output is unstructured text strings, not JSON/structured objects. Functions like _format_sql_result return f-strings. Agents cannot extract typed fields or chain results to downstream tools. Missing documented output schemas entirely.
Parameter descriptions are minimal and lack constraint guidance. Example: 'The schema name to list tables from', does not specify format, length, case sensitivity, or allowed characters. Missing format specifications and validation hints force LLMs to guess.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 61 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 60 | - | v1 |
List all available schemas in a Databricks catalog.
List all tables in a specific schema.
List all available Unity Catalogs with their names, descriptions, and types. Use this tool as a starting point to discover available data sources when you don't know specific catalog names. It provides a high-level overview of all accessible catalogs in the workspace.
No pagination support on list operations (list_schemas_in_databricks, list_tables_in_databricks, list_uc_catalogs). If a catalog has hundreds of schemas, the entire list is returned, potentially overflowing context. Missing limit/offset/cursor parameters and row_count in responses.
Error handling is generic and non-actionable. All exceptions return plain strings like 'Error listing schemas: {e!s}'. No guidance on what the agent should do next, no categorization (retryable vs fatal), no suggestion of alternative tools.
Tool descriptions lack WHEN-to-use guidance and differentiation. list_schemas_in_databricks and list_uc_catalogs both list metadata but it's unclear when to call one vs the other. describe_uc_schema says 'Use this tool to understand the contents of a schema' but doesn't explain when to call it instead of describe_uc_catalog.
No type constraints or enums on string parameters. Parameters like 'catalog', 'schema_name', 'table_name' accept arbitrary strings. No validation of identifier format (e.g., 'catalog.schema.table' must be three dot-separated parts).
No tool-level documentation of return types. Descriptions mention 'returns the results' but never document the field names or structure. A downstream tool that needs a schema_name from describe_uc_schema cannot know what field to extract.