dbx-mcp

Manage Lakebase databases

manage_lakebase_database

Destructive

Create, update, delete, and list Lakebase Postgres databases, including provisioned instances and autoscaling projects, and register them in Unity Catalog.

Instructions

Manage Lakebase (Postgres) databases.

kind='provisioned' manages database instances: list, get, create (spec = DatabaseInstance fields, e.g. {"capacity": "CU_1"}), update (spec = fields to change, e.g. {"stopped": true} or {"capacity": "CU_2"}), delete (force=true also removes point-in-time children). kind='autoscaling' manages projects: list, get, create (spec = Project fields, e.g. {"spec": {"display_name": "My app", "pg_version": 17}}), update (e.g. {"spec": {"display_name": "x"}}), delete (soft unless purge=true), undelete, get_operation. Catalog actions register a Postgres database in Unity Catalog: list_catalogs (provisioned, name = instance), get_catalog, create_catalog (catalog_name, database_name, name/branch), delete_catalog. Compute is billed; long-running work returns status 'pending' unless wait_seconds is set.

Safety classification: list, get, get_operation, list_catalogs, get_catalog = READ_ONLY; create, update, undelete, create_catalog = WRITE; delete, delete_catalog = DESTRUCTIVE.

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
`name`	No	provisioned: database instance name. autoscaling: project id or 'projects/<id>'.
`spec`	No	Request body fields for create/update, using the Databricks REST API field names (snake_case). Unknown fields are rejected.
`force`	No	provisioned delete: also delete descendant point-in-time instances (otherwise the delete is rejected if any exist).
`purge`	No	autoscaling delete: hard delete (irreversible). Default is a soft delete restorable with action='undelete'.
`action`	Yes	Operation to perform. *_catalog actions register/unregister a Lakebase Postgres database as a Unity Catalog catalog.
`branch`	No	autoscaling create_catalog: branch id or full branch name (default: the project's default branch).
`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.
`update_mask`	No	Comma-separated field paths to update. Default: derived from the keys of `spec` (autoscaling resources use 'spec.<field>' paths).
`catalog_name`	No	Unity Catalog catalog name for *_catalog actions.
`show_deleted`	No	autoscaling list: include soft-deleted projects.
`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.
`database_name`	No	create_catalog: Postgres database to register.
`operation_name`	No	Autoscaling operation name returned by a previous call (for action='get_operation').
`create_database_if_missing`	No	create_catalog: create the Postgres database if it does not exist.

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

Behavior5/5

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

Beyond the coarse annotations (destructiveHint=true, readOnlyHint=false), the description adds a per-action safety classification (READ_ONLY/WRITE/DESTRUCTIVE), explains that delete is soft unless purge=true, that force removes point-in-time children, and that long-running work returns 'pending' unless wait_seconds is set. This meaningfully deepens the agent's understanding of destructive and async behavior.

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

Conciseness5/5

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

The description is dense but well-structured: it front-loads the purpose, then groups details by kind and catalog actions, and ends with a compact safety table. Every sentence contributes to action/kind mapping, async behavior, or safety, and the length is justified by the tool's 11 actions and 18 parameters.

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

Completeness4/5

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

Given the rich input schema and an output schema, the description need not document every parameter or return value. It covers the essential conceptual model (kinds, actions, safety, async), but it omits any mention of the dry_run/confirm workflow for destructive actions and does not differentiate from sibling tools.

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?

The schema already documents all 18 parameters at 100% coverage, so baseline is 3. The description goes further by providing concrete spec examples for both kinds and clarifying how force, purge, and branch interact with specific actions. This adds useful cross-parameter semantics beyond the schema's per-parameter descriptions.

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

Purpose4/5

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

The description opens with a specific verb+resource ('Manage Lakebase (Postgres) databases') and then scopes the tool by kind ('provisioned' vs 'autoscaling') and catalog actions. It does not name sibling tools (e.g., manage_lakebase_branch), so an agent must infer scope rather than being told explicitly.

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 maps each action to a kind and gives concrete examples for create/update specs, plus notes on soft/hard delete and async wait behavior. However, it never states when to choose this tool over sibling tools like manage_lakebase_branch or generate_lakebase_credential, and gives no explicit exclusions.

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

Deploy Server