dbx-mcp

Inspect or cancel a SQL statement

manage_sql_statement

Read-only

Poll a pending SQL statement for its status and results, or cancel it. Use after execute_sql returns 'pending' to retrieve finished results or stop execution.

Instructions

Poll a previously submitted SQL statement (status and, once finished, its results) or cancel it. Use after execute_sql returned status 'pending'.

Safety classification: get = READ_ONLY; cancel = EXECUTION.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "action": "<action>",
      "statement_id": "<statement_id>"
    },
    "name": "manage_sql_statement"
  }
}

Input Schema

Name	Required	Description	Default
`action`	Yes	get: status and results; cancel: stop it.
`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.
`max_rows`	No	Maximum rows to return (capped by DBX_MCP_SQL_MAX_ROWS).
`row_format`	No	'arrays' (compact, aligned with columns) or 'objects' (one dict per row).	arrays
`statement_id`	Yes	Statement id returned by execute_sql.

Output 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

A3.6/5.0

Behavior2/5

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

The description usefully discloses per-action safety ('get = READ_ONLY; cancel = EXECUTION'), which is genuinely more granular than the tool-level annotations. However, this conflicts with readOnlyHint=true and destructiveHint=false, which declare the whole tool non-mutating even though cancel stops a running statement — an agent trusting the annotation could treat a state-changing action as safe. The accurate disclosure softens the penalty, but the mismatch with the declared safety profile is a real defect.

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?

Three short sentences: the action first, then the workflow trigger, then the safety classification. Every sentence earns its place, nothing is repeated, and the most important routing information is front-loaded.

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?

With an output schema present and 100% parameter coverage, return-value explanation is not needed, and the description covers modes, trigger, and safety. The only thin spot is the confirmation/dry_run path implied by those parameters, which the description never touches and the agent must infer from the schema alone.

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

Parameters3/5

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

Schema description coverage is 100%, so action, confirm, dry_run, max_rows, row_format, and statement_id are all already documented in the schema. The description adds only the outcome of 'get' (status plus results once finished) and confirms 'cancel it', which does not go meaningfully beyond the schema. Baseline 3 applies.

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 states a specific verb and resource in both modes: 'Poll a previously submitted SQL statement (status and, once finished, its results) or cancel it.' It clearly positions itself relative to execute_sql as the follow-up step, so an agent can place it in the workflow. It does not explicitly distinguish itself from execute_sql_multi or other SQL siblings, which keeps it from a 5.

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 a precise, actionable trigger: 'Use after execute_sql returned status "pending".' That tells the agent exactly when to reach for this tool. There is no explicit when-not guidance or named alternative, but the trigger is unambiguous enough to route correctly.

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

Deploy Server