dbx-mcp

Data quality monitors (Lakehouse Monitoring)

manage_uc_monitors

Destructive

Create, update, refresh, and delete Unity Catalog data quality monitors, then inspect profile and drift metrics to track table or schema health.

Instructions

Manage Unity Catalog data quality monitors (Lakehouse Monitoring) via the Data Quality API.

Actions (full_name identifies the table, or schema with object_type=schema):

create(spec): table monitors take DataProfilingConfig fields - output_schema_name (catalog.schema, or output_schema_id), exactly one of snapshot {} | time_series {timestamp_column, granularities: ["AGGREGATION_GRANULARITY_1_DAY", ...]} | inference_log {...}, plus optional schedule {quartz_cron_expression, timezone_id}, slicing_exprs, custom_metrics, baseline_table_name, assets_dir, warehouse_id, notification_settings, skip_builtin_dashboard. Schema monitors take AnomalyDetectionConfig fields (excluded_table_full_names).
get, update(spec: only the fields to change), delete (metric tables/dashboard are kept).
refresh (starts compute), list_refreshes, get_refresh(refresh_id), cancel_refresh(refresh_id).
metrics: profile_metrics_table_name, drift_metrics_table_name, dashboard_id - query them with SQL.
query_metrics(metrics_table=profile|drift, sample_rows, warehouse_id?): sample rows of a metric table. Listing all monitors is not available (the SDK marks list_monitor as unimplemented).

Safety classification: create, update, cancel_refresh = WRITE; get, list_refreshes, get_refresh, metrics = READ_ONLY; delete = DESTRUCTIVE+WRITE; refresh = EXECUTION; query_metrics = EXECUTION+READ_ONLY.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`spec`	No	Request body fields for create/update, using the Databricks REST API field names (snake_case). Unknown fields are rejected.
`action`	Yes	create/get/update/delete a monitor; refresh: start a metrics refresh; list_refreshes/get_refresh/cancel_refresh; metrics: names of the profile/drift metric tables and dashboard; query_metrics: sample rows from a metric table via a SQL warehouse.
`confirm`	No	Set to true ONLY after the user has reviewed the plan returned by a previous call with status 'confirmation_required'. Required for destructive/security-sensitive actions.
`dry_run`	No	If true, validate and return the planned change without executing it.
`full_name`	No	Monitored object: table catalog.schema.table (or catalog.schema when object_type=schema).
`page_size`	No	Max items to return (server caps this).
`page_token`	No	next_page_token from a previous response.
`refresh_id`	No	Refresh id for get_refresh / cancel_refresh.
`object_type`	No	table: data profiling monitor; schema: anomaly detection monitor.	table
`sample_rows`	No	query_metrics: rows to return.
`warehouse_id`	No	SQL warehouse for query_metrics.
`metrics_table`	No	query_metrics: which metric table to sample.	profile

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	No
`page`	No
`plan`	No
`tool`	Yes
`action`	No
`safety`	No
`status`	No		success
`summary`	Yes
`warnings`	No
`next_steps`	No	Suggested follow-up calls.
`request_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 3, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations only give coarse flags (readOnlyHint=false, destructiveHint=true, openWorldHint=true), while the description supplies a far richer per-action safety classification (create/update/cancel_refresh=WRITE, delete=DESTRUCTIVE+WRITE, refresh=EXECUTION, etc.) and discloses a non-obvious side effect: 'delete (metric tables/dashboard are kept)'.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and action list are front-loaded, with actions and safety classes grouped into scannable bullets. It is dense and long, but nearly every line carries actionable detail, so little is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 12-parameter, 10-action tool with an output schema present, the description covers the mutating actions, the refresh lifecycle, where metrics live, and the confirmation/dry-run flow, leaving no obvious gap an agent would need to guess at.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3; the description earns above that by documenting the shape of the free-form spec argument per action (DataProfilingConfig fields, the mutually exclusive snapshot/time_series/inference_log variants, AnomalyDetectionConfig for schema monitors) and clarifying that update takes only the fields to change.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb+resource ('Manage Unity Catalog data quality monitors (Lakehouse Monitoring) via the Data Quality API') and then enumerates the exact action surface, so an agent can tell it apart from siblings like manage_metric_views or manage_uc_objects. Scope is further pinned by noting that full_name identifies a table or schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear per-action context (create/get/update/delete, refresh lifecycle, metrics/query_metrics) and even states a when-not: 'Listing all monitors is not available (the SDK marks list_monitor as unimplemented)'. What it lacks is any explicit routing against sibling tools, so it stops short of the 5 bar.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server