QuickBooks Desktop MCP

Overview Schema Source Related Servers Discussions Admin

qb_list_open_invoices

Read-only

List open invoices with a balance greater than zero for one customer by exact full name or all customers; returns reference number, date, customer, currency, total, and balance.

Instructions

Unpaid invoices (balance > 0), for one customer (exact full name) or all. Returns ref number, date, customer, currency, total and balance.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "qb_list_open_invoices"
  }
}

Input Schema

Name	Required	Description	Default
`customer`	No
`max_results`	No

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.2.0Nov 1, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds real value by defining what 'open' means ('balance > 0') and what fields come back. It remains silent on the default/behavior of max_results and whether the result is capped without notice, which matters for a list tool.

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?

Two tight sentences, filter semantics front-loaded, nothing padded. Every clause carries information an agent needs.

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 the field list is a bonus rather than a necessity. The only meaningful hole is the undocumented max_results parameter and any truncation/pagination behavior it implies.

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 0%, so the description must carry the parameter burden. It compensates well for 'customer' by stating it must be the exact full name and that omitting it means all customers, but 'max_results' is never mentioned despite being the truncation control on a 200-default list.

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?

Specific verb+resource ('list open invoices') with the filter criterion spelled out as 'balance > 0', plus the two modes (single customer or all). This is clearly distinguishable from qb_find_invoice or qb_query_transactions, though it never names those siblings explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to reach for it (you want unpaid invoices, not all invoices) and gives an important precondition — the customer must be an exact full name, not a partial match. However it does not tell the agent when to prefer qb_find_invoice or qb_query_transactions instead, leaving the routing to inference.

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