Skip to main content
Glama
QuickBooks Desktop MCP

QuickBooks Desktop MCP

by Compolaga

qb_add_transaction

Preview and confirm a home-currency check, deposit, or credit card charge/credit, then book it with a confirmation code and undo log.

Instructions

Adds a transaction (Check, Deposit, CreditCardCharge, or CreditCardCredit) in the home currency. lines: [{"account": str, "amount": number or string, "memo": str|None}, ...]. For foreign-currency accounts or exchange rates use qb_write_check / qb_deposit instead. A Deposit has no header payee or refnum in qbXML: payee is put on every line (as EntityRef) and a refnum is refused.

Two steps: without confirm_code this only returns a preview and a confirm code; with the code it books and logs an undo entry (qb_revert_run).

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": {
      "txn_type": "<txn_type>",
      "account": "<account>",
      "txn_date": "<txn_date>",
      "lines": "<lines>"
    },
    "name": "qb_add_transaction"
  }
}

Input Schema

NameRequiredDescriptionDefault
linesYes
payeeNo
refnumNo
run_idNo
accountYes
txn_dateYes
txn_typeYes
header_memoNo
confirm_codeNo
expected_company_fileNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare the generic mutation profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds genuinely new behavior: a two-step preview/confirm gate, an undo entry being logged and revertible via qb_revert_run, and a qbXML quirk where a Deposit refuses refnum and pushes payee onto every line. This is exactly the kind of context an agent cannot get from the structured fields.

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?

Roughly five sentences, front-loaded with the core action and scope, then the lines shape, then the exclusion and the two-step flow. No filler or restatement of the tool name.

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 no output schema, the description does explain what a call returns in each mode (a preview plus confirm code, or a booked transaction with an undo entry). Gaps remain around expected_company_file guard semantics, run_id usage, and the preview payload contents, but the essentials for calling it correctly are present.

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 0% across 10 parameters, so the description carries the burden and does document the nested lines shape (account, amount, memo) and the confirm_code two-step meaning, plus the refnum/payee restriction on Deposit. It leaves several parameters (account, txn_date, header_memo, run_id, expected_company_file) undocumented, and the txn_type values are only implied by the parenthetical list.

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 (adds) and resource (transaction) and immediately enumerates the four supported txn_type values, so the agent knows exactly the scope. It also distinguishes itself from qb_write_check / qb_deposit by currency scope, making sibling differentiation explicit.

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?

Names the alternatives and the condition that selects them: 'For foreign-currency accounts or exchange rates use qb_write_check / qb_deposit instead.' It also spells out the required call sequence (preview without confirm_code, then book with the returned code), leaving nothing to inference.

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