Skip to main content
Glama
WYRE-AI

QuickBooks Online MCP Server

by WYRE-AI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

qbo_payments_create

Create a new Payment record in QuickBooks Online.

Instructions

Create a new Payment record in QuickBooks Online.

Input Schema

NameRequiredDescriptionDefault
LineNoLinked transactions applying this payment, e.g. [{Amount: 100, LinkedTxn: [{TxnId: '5', TxnType: 'Invoice'}]}]. On update, Line replaces existing applications. QuickBooks keeps one line per invoice: a second line for an invoice that is already linked replaces that amount instead of adding to it. To increase an application, send one line with the combined amount.
TxnDateNoTransaction date (YYYY-MM-DD format)
TotalAmtYesTotal payment amount
CustomerRefYesCustomer reference object, e.g. {"value": "123"} where value is the customer ID
PaymentMethodRefNoPayment method reference object, e.g. {"value": "1"}
DepositToAccountRefNoBank or asset account to deposit this payment into, e.g. {"value": "35"}. Omit on create to use Undeposited Funds. Omit on update to leave the existing deposit account unchanged.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.6.6
    • addedInput schema / properties / DepositToAccountRef
      Added value: +{
+  "description": "Bank or asset account to deposit this payment into, e.g. {\"value\": \"35\"}. Omit on create to use Undeposited Funds. Omit on update to leave the existing deposit account unchanged.",
+  "type": "object"
+}
    • changedInput schema / properties / Line / description
      Previous value: -"Array of LinkedTxn entries linking this payment to invoices, e.g. [{Amount: 100, LinkedTxn: [{TxnId: '5', TxnType: 'Invoice'}]}]"New value: +"Linked transactions applying this payment, e.g. [{Amount: 100, LinkedTxn: [{TxnId: '5', TxnType: 'Invoice'}]}]. On update, Line replaces existing applications. QuickBooks keeps one line per invoice: a second line for an invoice that is already linked replaces that amount instead of adding to it. To increase an application, send one line with the combined amount."
  2. Addedv1.4.4

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It signals a write operation but does not disclose side effects, idempotency, authentication needs, or what happens to linked transactions, leaving significant gaps for a mutation tool.

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?

The description is a single front-loaded sentence with no wasted words. However, it is arguably too sparse for a six-parameter write tool with nested objects, so it is not fully appropriately sized.

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

Completeness2/5

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

Given a write operation with no annotations and no output schema, the description should provide more context about when to use it, what it affects, and how it relates to sibling creation tools. The one-line description leaves the agent to rely almost entirely on the schema and tool name.

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 100%, so the input schema already documents all six parameters in detail, including the important Line replacement behavior and DepositToAccountRef defaults. The description adds no additional parameter meaning beyond what the schema provides, making the baseline score appropriate.

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?

The description states a specific verb (Create) and resource (Payment record) in a named system (QuickBooks Online), so the basic purpose is unambiguous. It does not differentiate this customer-payment tool from closely named siblings such as qbo_bill_payments_create or qbo_sales_receipts_create, which leaves routing ambiguity.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of required permissions or setup. The agent is left to infer usage entirely from the name and schema.

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

Deploy Server

Other Tools