QuickBooks Online MCP Server

create_vendor_credit

Creates a vendor credit in QuickBooks Online with per-line tax codes, class tracking, and global tax calculation for non-US locales; use it to record credits against vendor bills.

Instructions

Create a vendor credit in QuickBooks Online. Supports per-line sales tax (tax_code_ref) and class tracking (class_ref) the same way bills do — for companies using the global tax model (CA/UK/AU etc.), set each line's tax_code_ref and a top-level global_tax_calculation so QBO auto-calculates TxnTaxDetail.

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": {
      "params": "<params>"
    },
    "name": "create_vendor_credit"
  }
}

Input Schema

Name	Required	Description	Default
`params`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 6, 2026

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations supplied, the description carries the full behavioral burden. It usefully discloses that QBO auto-calculates TxnTaxDetail when tax_code_ref and global_tax_calculation are combined, which is real behavior beyond the schema, but it says nothing about permissions, side effects on vendor balances, idempotency, or failure modes for a mutation call.

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?

Two front-loaded sentences: the first establishes the operation, the second concentrates on the non-obvious tax behavior. The parenthetical locale list and em-dash clause are dense but every element carries information; nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a nested, multi-field mutation with no annotations and no output schema, the description covers the trickiest area (global tax handling) but leaves other essentials unaddressed, such as required fields, what the returned credit reference looks like, and whether the credit posts immediately to the ledger.

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?

Adds meaning beyond the schema by explaining how two parameters interact: per-line tax_code_ref plus a top-level global_tax_calculation together drive automatic tax calculation, and class_ref mirrors bill behavior for class tracking. It does not cover the required vendor_ref and line_items or the billable_status/customer_ref pairing, but the hard-to-infer tax semantics are explained well.

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?

States a specific verb and resource: 'Create a vendor credit in QuickBooks Online.' It does not distinguish the tool from near-siblings such as create_bill or create_credit_memo, so an agent still has to infer which document type applies, but the operation itself is unambiguous.

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?

Provides conditional guidance on how to use the tax fields for companies on the global tax model (CA/UK/AU), including the pairing of per-line tax_code_ref with a top-level global_tax_calculation. It gives no guidance on when to choose this over create_bill, create_credit_memo, or create_refund_receipt, and states no prerequisites.

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

Deploy Server