dbx-mcp

Manage Lakebase synced tables

manage_lakebase_sync

Destructive

Create, list, trigger, or delete Lakebase synced tables to replicate Unity Catalog Delta data into Postgres for reverse ETL.

Instructions

Manage Lakebase synced tables (reverse ETL: Unity Catalog Delta table -> Lakebase Postgres table).

Actions: list (provisioned; instance_name), get, create (table_name + spec with source_table_full_name, primary_key_columns, scheduling_policy SNAPSHOT/TRIGGERED/CONTINUOUS), delete (purge_data=true also drops the Postgres table), trigger (starts the synced table's managed pipeline via pipelines.start_update; not for CONTINUOUS), get_operation (autoscaling). update is not supported by the Databricks API. kind='autoscaling' uses w.postgres synced tables (no list).

Safety classification: list, get, get_operation = READ_ONLY; create, update = WRITE; delete = DESTRUCTIVE; trigger = EXECUTION.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`kind`	No	provisioned: Lakebase database instances (w.database). autoscaling: Lakebase autoscaling projects/branches/endpoints (w.postgres).	provisioned
`spec`	No	create: synced table spec, e.g. {"source_table_full_name": "main.sales.orders", "primary_key_columns": ["order_id"], "scheduling_policy": "TRIGGERED"} (SNAPSHOT \| TRIGGERED \| CONTINUOUS; optional new_pipeline_spec / existing_pipeline_id, timeseries_key, create_database_objects_if_missing). Autoscaling specs also take branch and postgres_database. Unknown fields are rejected.
`action`	Yes	Synced table operation. trigger starts a sync for TRIGGERED/SNAPSHOT policies.
`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.
`page_size`	No	Max items to return (server caps this).
`page_token`	No	next_page_token from a previous response.
`purge_data`	No	provisioned delete: also DROP the Postgres table.
`table_name`	No	Full Unity Catalog name of the synced table: catalog.schema.table.
`wait_seconds`	No	Seconds to wait for a long-running create/update/delete to finish. 0 (default) returns immediately with status 'pending'. Capped by DBX_MCP_MAX_WAIT_SECONDS and the tool timeout.
`instance_name`	No	provisioned: database instance (required for list; for create unless the target catalog is a registered database catalog).
`operation_name`	No	Autoscaling operation name returned by a previous call (for action='get_operation').
`logical_database_name`	No	provisioned create: target Postgres database name.

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.8/5.0

Behavior5/5

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

Annotations only supply coarse tool-level flags (destructiveHint=true, openWorldHint=true); the description refines them with a per-action safety classification (READ_ONLY/WRITE/DESTRUCTIVE/EXECUTION) and discloses that purge_data drops the Postgres table and that confirm is required after a 'confirmation_required' status. This is real behavioral context beyond the annotations and does not contradict them.

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?

Front-loads the resource and reverse-ETL framing, then breaks actions and safety into scannable segments. Dense but efficient; a few items (scheduling policy names, purge_data) duplicate the schema, costing a point.

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?

With an output schema present, the description need not describe returns, and it covers the remaining essentials: action prerequisites, the unsupported update, kind branching, destructive scope, and the confirmation/dry-run workflow for a 13-parameter tool.

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 coverage is already 100%, so the baseline is 3, but the description adds cross-parameter semantics: which params each action needs, that trigger drives pipelines.start_update, and the SNAPSHOT/TRIGGERED/CONTINUOUS scheduling policies. It largely echoes the schema for individual fields, so it stops short of a 5.

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?

Names a specific resource (Lakebase synced tables) and clarifies the domain with the parenthetical 'reverse ETL: Unity Catalog Delta table -> Lakebase Postgres table'. The enumerated action list makes it unmistakably distinct from siblings like manage_lakebase_branch and manage_lakebase_database.

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

Usage Guidelines5/5

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

Gives per-action selection criteria: list requires instance_name, create requires table_name + spec, trigger is 'not for CONTINUOUS', update 'is not supported by the Databricks API', and kind='autoscaling' has 'no list'. Explicit when-to-use and when-not guidance for every mode.

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

Deploy Server