QuickBooks Online MCP Server

update-bill

Updates a QuickBooks Online bill by merging changes into the current record, preserving omitted fields and line details. Pass the bill ID and changed fields; lines without IDs become new lines.

Instructions

Update a bill in QuickBooks Online. Performs a read-merge-write: the current bill is fetched and your changes are merged over it, so line-level ClassRef/TaxCodeRef and any other fields you omit are preserved (QBO bill updates are full overwrites). Pass bill.Id plus only the fields to change. Match an existing line by its Id; a line without an Id is added as a new line. SyncToken is optional — the latest is fetched automatically.

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": "update-bill"
  }
}

Input Schema

Name	Required	Description	Default
`params`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 6, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses the read-merge-write pattern, that underlying QBO updates are full overwrites, and that omitted fields such as line-level ClassRef/TaxCodeRef are preserved. It stops short of describing return shape, conflict/error behavior, or the last-write-wins risk implied by auto-fetching SyncToken.

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?

Front-loads purpose in the first clause, then explains the merge behavior, then gives invocation instructions. Every sentence adds distinct information with no filler.

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?

For a mutation tool with no annotations, no output schema, and a deeply nested parameter object, the description covers the highest-risk semantics (overwrite vs merge, line matching, SyncToken). It could still say what is returned or how failures surface, but nothing essential for a correct call is missing.

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%, so the description must compensate, and it does for the critical fields: Id is required, SyncToken is optional and auto-fetched, and Line.Id controls update-vs-append semantics. Many other schema fields (Balance, DueDate, VendorRef, PrivateNote, TotalAmt) remain unexplained in either place, which keeps it below a 5.

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 and resource ('Update a bill in QuickBooks Online') and the resource is unambiguous against closely named siblings like update_bill_payment and update_purchase. An agent can identify the target entity without opening the schema.

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

Usage Guidelines4/5

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

Gives clear operating instructions ('Pass bill.Id plus only the fields to change', 'Match an existing line by its Id; a line without an Id is added as a new line') that tell the agent how to invoke it correctly. It does not explicitly name when to prefer a sibling such as create-bill or update_bill_payment, but the mutation context is clear.

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

Deploy Server