dbx-mcp

Manage pipelines

manage_pipeline

Destructive

Create, inspect, update, clone, or delete Lakeflow Spark Declarative Pipelines (DLT) in Databricks, including listing, pagination, and safe destructive confirmations.

Instructions

Create, inspect, change, clone and delete Lakeflow Spark Declarative Pipelines (DLT).

create: spec = pipeline settings (name, catalog, schema, libraries [{notebook:{path}} | {file:{path}} | {glob:{include}}], root_path, serverless, clusters, configuration, continuous, development, channel, edition, photon, notifications, tags, trigger, environment, event_log, run_as, ...).
get (pipeline_id), list (name_contains or filter; paginated).
update (pipeline_id, spec): the given top-level fields are merged onto the current settings (set a field to null to remove it); uses expected_last_modified to avoid overwriting concurrent edits.
delete (pipeline_id[, cascade, force]): DESTRUCTIVE, needs confirm. By default tables are deleted too.
clone (pipeline_id, spec: catalog, schema/target, clone_mode='MIGRATE_TO_UC', ...): HMS -> UC copy. Run/monitor updates with manage_pipeline_run. Specs with run_as are SECURITY_SENSITIVE.

Safety classification: depends on input (DESTRUCTIVE, EXECUTION, READ_ONLY, SECURITY_SENSITIVE, WRITE).

Input Schema

TableJSON Schema

Name	Required	Description
`spec`	No	Request body fields for create/update, using the Databricks REST API field names (snake_case). Unknown fields are rejected.
`force`	No	delete: proceed even if resource cleanup fails.
`action`	Yes	create: new pipeline from spec; get: full definition and state; list: pipelines; update: change settings (merged onto the current spec); delete: delete pipeline; clone: copy a Hive-metastore pipeline to Unity Catalog (starts an update on the clone).
`filter`	No	list: raw server filter, e.g. "notebook='/Users/me/nb'" or "name LIKE '%sales%'".
`cascade`	No	delete: false keeps the pipeline's tables/views (server default true deletes them).
`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.
`pipeline_id`	No	Pipeline id (get/update/delete/clone).
`name_contains`	No	list: only pipelines whose name contains this text (server-side LIKE).

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

Behavior5/5

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

Annotations already flag destructiveHint=true, readOnlyHint=false, and openWorldHint=true, but the description adds substantial behavioral context beyond them: delete is DESTRUCTIVE and needs confirm; tables are deleted by default unless cascade=false; update merges top-level fields and uses expected_last_modified to avoid concurrent edits; run_as specs are SECURITY_SENSITIVE; and safety classification depends on input.

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 front-loaded with the overall purpose, then uses concise action bullets for create/get/list/update/delete/clone, followed by routing and safety notes. Every sentence earns its place for a multi-action, 11-parameter tool with complex semantics.

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?

Given the tool's complexity—six actions, 11 parameters, a nested spec object, and destructive/security-sensitive behaviors—the description covers action semantics, destructive safeguards, update merging, clone migration, and the manage_pipeline_run alternative. With an output schema present, it need not explain return values, so nothing essential is missing.

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, but the description adds meaning beyond the schema: update merges top-level fields onto current settings and setting a field to null removes it; delete's cascade default is true (deletes tables) while false keeps them; clone is HMS-to-UC with clone_mode='MIGRATE_TO_UC'; and spec uses Databricks REST API snake_case names with unknown fields rejected.

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 opens with a specific verb set and resource: 'Create, inspect, change, clone and delete Lakeflow Spark Declarative Pipelines (DLT).' It then enumerates each action, making clear what the tool does and distinguishing it from manage_pipeline_run, which is explicitly named for run/monitor operations.

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?

The description gives clear action-level context (e.g., 'get (pipeline_id)', 'list (name_contains or filter; paginated)', 'update (pipeline_id, spec)') and routes run/monitor work to manage_pipeline_run. It does not explicitly state when not to use this tool versus other pipeline-adjacent siblings, so it falls short of full when/when-not guidance.

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

Deploy Server