QuickBooks Desktop MCP

Overview Schema Source Related Servers Discussions Admin

qb_revert_run

Destructive

Undo all QuickBooks bookings created by one server run: preview the changes first, then confirm to delete only the objects that run created.

Instructions

Undoes every booking of one of THIS server's own runs (run_id from a write tool's result or qb_list_runs), newest first. Only own bookings can be undone: the run log is looked up by id in this server's own run directory, records only what the run created, and revert deletes exactly those objects. Refused if QuickBooks has another company file open than the one the run was booked in, or if the run log is damaged. Two steps: without confirm_code it shows what would be undone. After a partial failure, calling it again skips the steps already undone; a booking that no longer exists in QuickBooks (removed by hand) counts as undone. A (partly) reverted run takes no new bookings.

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": {
      "run_id": "<run_id>"
    },
    "name": "qb_revert_run"
  }
}

Input Schema

Name	Required	Description	Default
`run_id`	Yes
`confirm_code`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Nov 1, 2026

TDQS

A4.9/5.0

Behavior5/5

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

While annotations mark it as destructive, the description goes far beyond this by explaining the 'how' and 'what' of the destruction. It details the lookup method (by ID in the run directory) and provides critical information on state recovery, such as skipping steps after a partial failure.

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?

The description is quite long due to the complexity of the operation (destructive, stateful, multi-step). However, its length is justified by the need to define all necessary operational constraints and failure modes. The structure is logical, moving from general function to specific constraints.

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 high complexity of undo operations (destructive, non-idempotent, state-dependent), the description covers virtually all critical operational aspects. It addresses refusal conditions, incremental execution, and partial failure handling, making it exceptionally complete.

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

Parameters5/5

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

Since schema coverage is 0%, the description is vital. It explains the source and context of the required run_id (from a write tool's result or qb_list_runs) and differentiates the functional intent of confirm_code (preview vs. execution).

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 tool clearly states its specific purpose: to undo bookings for runs created by 'this server.' It distinguishes itself by detailing that it only handles 'own bookings' and reverts objects created by the run log, a scope clearly different from standard write tools.

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?

It provides highly detailed constraints that define usage boundaries, specifically mentioning it is refused if QuickBooks has another company file open or if the run log is damaged. Furthermore, it explicitly guides usage based on the presence of the confirm_code (two steps).

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