This server provides safe, structured access to a QuickBooks Desktop company file via the MCP protocol, enabling read, write, and management operations with automatic undo logging.
Company & Setup
qb_company_info — Get the currently open QuickBooks company file path (confirm you're working with the right file before writing)
Reading Data
qb_list_accounts — List all chart of accounts entries (name, type, active status, balance)
qb_list_vendors — List all vendors (name, ListID), optionally filtering to active-only
qb_vendor_history — Get a breakdown of which accounts a vendor's past transactions were booked to, with counts
qb_query_transactions — Query transactions by type (Check, Deposit, CreditCardCharge, CreditCardCredit, Transfer, JournalEntry), with optional filters for date range, entity, and account
qb_check_duplicate — Check whether a transaction with a given date and amount already exists, with a configurable date tolerance window
Writing Data
qb_add_transaction — Add a new transaction (Check, Deposit, CreditCardCharge, or CreditCardCredit) with line items; automatically logged for undo
qb_modify_transaction_line — Modify an expense/deposit line on an existing transaction; requires original values for undo logging
qb_delete_transaction — Delete a transaction; requires a full before-snapshot so the operation can be reverted
qb_add_vendor — Create a new vendor after verifying no duplicate exists
Safety & Undo
qb_revert_run — Revert all operations from a prior run log in reverse order; supports dry_run mode to preview changes before applying
qb_list_runs — List recent run logs to find a specific run to inspect or revert
All write tools accept an optional expected_company_file parameter to guard against accidentally posting to the wrong company file
Provides safe, structured access to QuickBooks Desktop company files: read accounts, vendors, and transactions; add, modify, or delete transactions and vendors with automatic undo logging.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@quickbooks-desktop-mcp show me the chart of accounts"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP frontend for QuickBooks Desktop.
Gives any MCP-compatible client (Claude Desktop, Claude Code, or anything else that speaks MCP) safe, structured access to a local QuickBooks Desktop company file: read accounts/vendors/transactions, post new transactions, and modify or delete existing ones -- with every write automatically logged so it can be reverted.
QuickBooks Desktop's automation API (QBXML/QBFC) only works on the machine (or LAN) where QuickBooks is actually installed -- there is no cloud proxy for it. QBBridge runs locally, right next to QuickBooks, and your company file's data never has to leave that machine to be used by an MCP client.
QBXML is powerful but has real, undocumented sharp edges: several element orderings are order-sensitive in ways the schema alone doesn't tell you, and getting them wrong produces a bare COM parse exception with no indication of which field was the problem. This package exists so you don't have to rediscover those the hard way -- they're encoded and tested once, here.
Related MCP server: quickbooks-online-mcp-server
Read: chart of accounts, vendor list, a vendor's transaction history (so you can classify a new transaction against how this vendor has actually been booked before, not a guess), flexible transaction queries, and a duplicate/overlap checker.
Write: add/modify/delete transactions (Check, Deposit, CreditCardCharge, CreditCardCredit) and vendors.
Safety: every write is automatically recorded to an append-only undo log as it happens (not batched at the end -- a crash mid-run still leaves a usable log of everything that did complete). Any run can be reverted, in reverse order, with one call.
This server has no business-specific logic in it -- no classification rules, no confidence thresholds, no assumptions about what kind of business you run. Deciding which vendor maps to which account, when to trust a match versus flag it for a human, and how to parse a specific bank's statement format is policy, and policy differs by business. That belongs in the agent/skill calling this server, not in the server itself. This keeps the server itself universal.
The server is the mechanism; skills/qbbridge-bookkeeping/SKILL.md
is the judgment. It's a Claude skill that teaches an agent how to actually
use these tools well -- when to trust a vendor's transaction history vs.
flag it for a human, how to handle payment/credit lines vs. purchases,
and the safety habits (checking the open company file, checking for
duplicates) to follow before every write. Install the MCP server for the
plumbing; add this skill for the bookkeeping judgment on top of it.
Windows, with QuickBooks Desktop installed and the target company file open.
Python 3.10+.
pywin32 (installed automatically on Windows).
pip install qbbridge-mcpPoint your MCP client at the qbbridge-mcp command. For Claude Desktop,
add to your MCP config:
{
"mcpServers": {
"qbbridge": {
"command": "qbbridge-mcp"
}
}
}Every write tool accepts an optional expected_company_file parameter.
Pass the path you expect QuickBooks to have open (from a prior
qb_company_info call); the tool refuses to run if a different file is
actually open. This is the single check that prevents posting to the
wrong client's file.
qb_delete_transaction requires you to pass a full snapshot of the
transaction (query it first) -- without it, a delete cannot be undone.
Undo logs are written to ./qbbridge_runs by default, or
$QBBRIDGE_RUNS_DIR if set.
MIT
Adds a transaction (Check, Deposit, CreditCardCharge, or CreditCardCredit). lines: [{"account": str, "amount": float, "memo": str|None}, ...]. Automatically logs an undo entry -- every add can be reverted with qb_revert_run using the returned run_id.
Pass expected_company_file (from a prior qb_company_info call) to have this refuse to run if a different file is open than you expect.
| Name | Required | Description | Default |
|---|---|---|---|
| lines | Yes | ||
| payee | No | ||
| refnum | No | ||
| account | Yes | ||
| txn_date | Yes | ||
| txn_type | Yes | ||
| header_memo | No | ||
| expected_company_file | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses important behavioral traits beyond the basic add: automatic undo logging and the ability to revert via qb_revert_run, along with the expected_company_file safety mechanism. With no annotations provided, the description carries the full burden and does well to mention these side-effects and dependencies, though it omits details on permissions, rate limits, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences that front-load the purpose and quickly deliver the most critical usage details. Every sentence adds value, with no redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, undo mechanism, company file safety), the description is reasonably complete. It covers the core functionality, undo support, and an important guardrail. It could be improved by explicitly stating the return value (run_id) and mentioning prerequisite state, but overall it provides sufficient context for an AI agent to understand the tool's behavior and constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds some meaning beyond the input schema by describing the 'lines' parameter format (account, amount, memo) and explaining the 'expected_company_file' parameter's purpose. However, with 0% schema description coverage, the description should compensate more for the remaining six parameters (txn_type, account, txn_date, payee, refnum, header_memo) which are left unexplained. The provided info is helpful but insufficient for a tool with 8 parameters and no other documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly identifies the tool's action (adds a transaction) and lists the specific transaction types it supports (Check, Deposit, CreditCardCharge, CreditCardCredit). This distinctively separates it from sibling tools like qb_delete_transaction or qb_modify_transaction_line, making purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides specific guidance on using expected_company_file to prevent running on the wrong company file, and references qb_revert_run for undoing the transaction. However, it does not explicitly contrast with other transaction-related tools like qb_modify_transaction_line or qb_delete_transaction, leaving some ambiguity about when to choose this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a vendor if it doesn't already exist. Check qb_list_vendors first -- QuickBooks Desktop vendor names must be unique, and the same real-world vendor sometimes already exists under slightly different spelling/casing.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| expected_company_file | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description partially discloses behavior (conditional creation, uniqueness concern) but omits what happens if vendor exists (error or skip) and any other side effects or responses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct, front-loaded sentences with zero redundancy; every phrase earns its place by conveying essential behavior and a key warning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create-check tool with two parameters and no output schema, the description covers the main purpose and a critical usage rule but lacks parameter detail and duplicate behavior clarity, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description adds no explanation beyond the tool's function; the optional 'expected_company_file' parameter remains completely unexplained, failing to compensate for missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a vendor conditionally ('if it doesn't already exist') and distinguishes it by referencing 'qb_list_vendors' as a prerequisite check, making the purpose specific and distinct from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to check 'qb_list_vendors' first and explains why (unique names, possible existing variations), providing clear when-to-use guidance and a context-aware precaution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Checks whether a transaction with this date+amount already exists somewhere in the company file, within a tolerance window (banks don't always post the two sides of a transfer/payment on the exact same date). Use this before posting anything, to avoid double-entry -- especially for payments/transfers, where the same real-world event can get recorded from either side of a linked account.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| amount | Yes | ||
| account | No | ||
| txn_types | No | ||
| date_tolerance_days | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the tolerance window and the reason, but does not explicitly state read-only nature or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, front-loaded with purpose, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (not shown), return values are covered. But with no annotations and incomplete parameter coverage, the description is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage, and the description only explains date and amount and hints at date_tolerance_days. It does not describe account or txn_types, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks for duplicate transactions by date+amount with tolerance, distinguishing it from siblings like qb_add_transaction or qb_query_transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using this before posting to avoid double-entry, especially for payments/transfers, providing clear usage context. It does not explicitly mention when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the company file path QuickBooks Desktop currently has open. Call this first, and before any write, to confirm you're pointed at the right client's file.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only mentions it returns a path and its usage, but lacks details on permissions or side effects. Adequate for a simple read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with result then usage. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description fully explains what it does and when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, baseline 4. Description adds meaning by explaining the output (file path) and usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns the company file path. Distinguishes from siblings as no other tool provides this information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call this first and before any write to confirm the correct file. Provides clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deletes a transaction. You must pass before_snapshot -- the full transaction as it exists right now (query it first: account, payee, refnum, txn_date, header_memo, lines) -- so the undo log can recreate it if this needs to be reverted. Deleting without an accurate snapshot means it cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| txn_id | Yes | ||
| txn_type | Yes | ||
| before_snapshot | Yes | ||
| expected_company_file | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full responsibility. It discloses the destructive nature (deletion), the requirement for an accurate snapshot for undo capability, and the consequence of missing snapshot (cannot be undone). This adequately informs the agent of key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and contains no wasted words. Every sentence adds necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and the critical snapshot requirement, but lacks information on return values (no output schema) and error conditions. Given the tool has four parameters and one nested object, more detail on expected outcomes would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds value for 'before_snapshot' by specifying required fields (account, payee, etc.) and its purpose. However, 'txn_id', 'txn_type', and 'expected_company_file' receive no additional meaning beyond schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Deletes a transaction') and identifies the resource. It distinguishes from sibling tools like qb_add_transaction and qb_modify_transaction_line by focusing on deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to query the transaction first to obtain the before_snapshot, and warns about the irreversibility without an accurate snapshot. It provides clear context for use, though it doesn't explicitly list when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all accounts in the chart of accounts (name, type, active, balance). Use this to confirm an account name exists exactly before trying to post to it -- QuickBooks rejects an AccountRef to a nonexistent or misspelled account.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly implies this is a read-only operation ('lists'), and it adds important context about the necessity of exact account names for subsequent operations. The description is consistent and adds value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose. Every sentence adds value: the first states what it does, the second provides crucial usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, output schema present), the description is complete. It covers purpose, usage context, and key behavioral nuance. The output schema can handle return value details, so no additional explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description does not need to add parameter info beyond what is already obvious. It appropriately focuses on the overall purpose and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'lists' and the resource 'accounts in the chart of accounts', and specifies the exact fields returned (name, type, active, balance). It distinguishes itself from sibling tools like qb_list_vendors by the specific resource it lists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool: 'Use this to confirm an account name exists exactly before trying to post to it'. It also explains why this is important because QuickBooks rejects nonexistent accounts. This provides clear context and differentiates this tool from posting tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists recent run logs (most recent first), so you can find a run to inspect or revert without knowing its exact filename.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses ordering ('most recent first') and hints at the tool being read-only by mentioning inspection and revert. However, it does not disclose potential side effects, authentication requirements, or rate limits, which are gaps for a listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that wastes no words. It front-loads the action and immediately provides the benefit, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, output schema exists), the description is largely complete. It explains the ordering and purpose. However, it could mention that the 'limit' parameter controls the number of results, but since the schema has a default, this is a minor omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It does not explain the 'limit' parameter at all, leaving the agent to infer its meaning from the schema alone. The description only adds context about ordering and purpose, not parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('lists') and resource ('recent run logs'), clearly indicating the tool's purpose. It distinguishes itself from siblings like 'qb_revert_run' by focusing on listing rather than reverting, and explains the use case of finding a run without knowing the exact filename.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case ('find a run to inspect or revert') implying when to use the tool. However, it does not explicitly state when not to use it or compare to other listing tools like 'qb_query_transactions', which could filter runs more specifically.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists vendors (name, ListID). Use this to confirm a payee exists exactly before posting a transaction against it.
| Name | Required | Description | Default |
|---|---|---|---|
| active_only | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It identifies the tool as a read operation (lists) but does not mention behavior such as whether it returns all vendors, sorting, or the effect of the 'active_only' parameter. Lacking some behavioral detail but adequate for a simple list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences: first clearly states the function and output fields, second provides usage context. No wasted words, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and a simple single-parameter tool, the description covers the basic purpose and usage context. However, it lacks explanation of the 'active_only' parameter and any return value details beyond name and ListID. The presence of an output schema partially compensates, but the description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'active_only' parameter at all. It adds no meaning beyond what the schema provides. The parameter's purpose and effect are completely undocumented in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists vendors with specific fields (name, ListID) and distinctively positions it for payee verification before transaction posting, distinguishing it from sibling tools like qb_add_vendor or qb_vendor_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: to confirm a payee exists exactly before posting a transaction. While it does not exclude other uses or list alternatives, the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Modifies one expense/deposit line on an existing transaction. You must pass the ORIGINAL account/amount/memo (query the transaction first if you don't already have them) so the undo log can restore them exactly.
| Name | Required | Description | Default |
|---|---|---|---|
| txn_id | Yes | ||
| line_id | Yes | ||
| new_memo | No | ||
| txn_type | Yes | ||
| new_amount | Yes | ||
| new_account | Yes | ||
| edit_sequence | Yes | ||
| original_memo | No | ||
| original_amount | No | ||
| original_account | No | ||
| expected_company_file | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It mentions modification and undo log but lacks details on side effects, error conditions, permissions, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no unnecessary words, front-loaded with the main action and key prerequisite.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters and no output schema or annotations, the description is too brief. It omits essential details about multiple required parameters and expected return values, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains only original_account, original_amount, and original_memo, leaving many required parameters (e.g., edit_sequence, txn_type, line_id) unexplained. With 0% schema coverage, this is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool modifies one expense/deposit line on an existing transaction, using specific verbs and resource identification. It distinguishes from siblings like qb_add_transaction and qb_delete_transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it modifies a line and requires original values from a prior query. However, it does not explicitly state when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Queries transactions of one type (Check, Deposit, CreditCardCharge, CreditCardCredit, Transfer, JournalEntry). date_from/date_to as YYYY-MM-DD. Returns normalized records: date, amount, payee, account (first line), memo, txn_id, edit_sequence.
| Name | Required | Description | Default |
|---|---|---|---|
| entity | No | ||
| account | No | ||
| date_to | No | ||
| txn_type | Yes | ||
| date_from | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It describes the output format (date, amount, payee, etc.) and date format requirement, but omits details on safety (read-only vs. destructive), authentication needs, rate limits, or pagination. The description is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the key verb and object. It efficiently conveys the transaction type constraint and output format. However, it could be slightly more structured (e.g., bullet points for parameters) without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and an output schema that covers return values, the description partially compensates by documenting txn_type and date fields. However, entity and account remain unexplained, and behavioral aspects are shallow. The presence of an output schema reduces the need to describe returns, but parameter gaps persist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It clarifies txn_type (one of the listed types) and date_from/date_to format (YYYY-MM-DD), but does not explain entity or account parameters. This leaves significant ambiguity for three of five parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries transactions of one specific type, listing allowed types (Check, Deposit, etc.), and specifies input date format and output fields. This makes the purpose highly specific and distinguishable from sibling tools like qb_add_transaction or qb_delete_transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for querying transactions but does not explicitly state when to use or when to avoid. No guidance on alternatives or exclusions is provided. While sibling tool names help infer context, the description itself offers no usage directives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reverts every operation in a run log, in reverse order. Set dry_run=true first to preview what would happen without changing anything.
| Name | Required | Description | Default |
|---|---|---|---|
| dry_run | No | ||
| run_log_path | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that operations are reverted in reverse order and that dry_run allows previewing. However, without annotations, it does not explicitly state the destructive nature or irreversible consequences, leaving some behavioral uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, no filler. It front-loads the core action and immediately provides actionable advice. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (reverting a run) and lack of output schema or annotations, the description covers the main behavior and a key usage tip. It lacks details like prerequisites, error conditions, or what happens after reverting, but is reasonably complete for a small tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description indirectly covers dry_run by explaining its role, but does not describe run_log_path beyond its name. With 0% schema coverage, the description adds limited meaning; the parameter names are self-explanatory, so adequacy is borderline average.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: reverting every operation in a run log in reverse order. The verb 'revert' and resource 'run log' are specific, and the tool is distinct from its siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance to use dry_run=true for previewing, which is valuable. However, it does not mention when to avoid using this tool or suggest alternatives, such as qb_list_runs to inspect the run log first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns which account(s) this vendor's past transactions were booked to, with counts -- e.g. {"Food Purchases": 175}. Use this before guessing an account for a new transaction from a known vendor: prefer whatever this vendor has actually been booked to before, not a plausible-sounding guess.
| Name | Required | Description | Default |
|---|---|---|---|
| txn_types | No | ||
| vendor_name | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description implies a read operation but does not explicitly state it is read-only or disclose any side effects, authorization needs, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each serving a purpose: first explains output, second provides usage guidance. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output format is explained with example; missing explanation of txn_types parameter and potential error cases. Overall adequate for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; description adds no semantic information about parameters (vendor_name, txn_types). The example format helps output but not input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns account(s) and counts for a vendor's past transactions, distinguishing it from siblings like qb_list_accounts and qb_query_transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use this tool before guessing an account for a known vendor, providing clear context. Could also mention when not to use it or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0qb_add_transactionqb_add_vendorqb_check_duplicateqb_company_infoqb_delete_transactionqb_list_accountsqb_list_runsqb_list_vendorsqb_modify_transaction_lineqb_query_transactionsqb_revert_runqb_vendor_historyEach tool has a clearly distinct purpose, from adding transactions and vendors to checking duplicates, querying, and reverting operations. No two tools overlap in function; even 'vendor_history' and 'list_vendors' serve different needs (history lookups vs. listing names).
Most tools follow a 'qb_verb_noun' pattern (e.g., add_transaction, list_accounts, revert_run), but 'company_info' and 'vendor_history' use a 'noun_info/history' pattern, breaking strict consistency. However, the prefix 'qb_' unifies them, and the naming is still predictable.
With 12 tools, the set is well-scoped for a QuickBooks Desktop integration. It covers essential operations (CRUD for transactions and vendors, plus supporting tools for company info, duplicates, and undo) without being overwhelming or sparse.
The tool surface covers core workflows: adding/deleting/modifying transactions, managing vendors, querying, and undoing operations. Missing are vendor updates or transaction header modifications, but the provided tools handle most common needs, and the undo system adds robustness.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Bookkeeping for owner-operated businesses. Query transactions, invoices, and reports.
Personal, family and business books over fiat and crypto. Reads and records; it cannot pay.
QuickBooks Online in Claude and ChatGPT: 211 tools, full ledger, multi-company, Canada + US, FR/EN.
Read-only tools for finding where a small business leaks deals, time, and cash.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/lilfroog/qbbridge'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
