dbx-mcp

Vector Search indexes

manage_vs_index

Destructive

List, get, create, sync, or delete Databricks Vector Search indexes; validate changes with dry runs and confirm destructive deletions.

Instructions

Manage Vector Search indexes.

Actions:

list (endpoint_name) / get (index_name): type, primary key, status and readiness.
create: index_name + endpoint_name + spec {primary_key, index_type: DELTA_SYNC|DIRECT_ACCESS, index_subtype?, delta_sync_index_spec: {source_table, pipeline_type: TRIGGERED|CONTINUOUS, embedding_source_columns: [{name, embedding_model_endpoint_name}] or embedding_vector_columns, columns_to_sync?} | direct_access_index_spec: {embedding_vector_columns: [{name, embedding_dimension}], schema_json}}.
sync: trigger a Delta Sync index refresh. delete: delete the index (requires confirm).
update: not supported by the API (recreate the index instead).

Safety classification: list, get = READ_ONLY; create, update = WRITE; delete = DESTRUCTIVE; sync = EXECUTION+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.
`action`	Yes	Operation to perform.
`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).
`index_name`	No	Full index name catalog.schema.index (all actions except list).
`page_token`	No	next_page_token from a previous response.
`endpoint_name`	No	Vector Search endpoint (required for list and create).

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

Behavior5/5

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

Annotations only give coarse tool-level hints (readOnlyHint=false, destructiveHint=true), but the description adds a per-action safety classification (list/get=READ_ONLY, create/update=WRITE, delete=DESTRUCTIVE, sync=EXECUTION+WRITE) and notes delete requires confirm. This is meaningful context beyond what the structured fields carry.

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 action list and uses bullets, so it scans well. The create bullet is a dense run-on with nested braces, but nearly every element adds actionable detail and little is wasted.

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?

An output schema exists, so return values need not be documented. The description covers all eight parameters' roles, action requirements, and safety semantics across the tool's complexity. Minor gaps remain around pagination/return behavior, but these are handled by the schema.

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 100%, so baseline is 3, but the description adds real value by sketching the create spec shape (primary_key, index_type enum values, delta_sync vs direct_access specs, embedding columns) and by clarifying which parameters each action requires. It exceeds the schema without duplicating it.

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?

States a specific verb (manage) and resource (Vector Search indexes) and then enumerates every supported action (list, get, create, sync, delete), clearly separating this tool from siblings like manage_vs_endpoint, manage_vs_data, and query_vs_index. An agent can identify scope without opening the 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?

Gives per-action guidance: which parameters each action needs (list needs endpoint_name, create needs index_name+endpoint_name+spec), and explicitly notes that update is not supported and to recreate instead. It stops short of routing to sibling tools such as query_vs_index for queries, so it's clear but not exhaustive.

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

Deploy Server