Skip to main content
Glama
laf-rge

QuickBooks MCP

by laf-rge

create_invoice

Create invoices in QuickBooks by specifying customer, line items, and optional details. Returns invoice data and a link to view it.

Instructions

Create an invoice. Accepts item/customer/department names (will lookup IDs automatically). Either customer_name or customer_id is REQUIRED — invoices must have a customer. Lines use SalesItemLineDetail (product/service references, not accounts). Returns invoice details and a link to view in QuickBooks.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
txn_dateYesTransaction date in YYYY-MM-DD format
customer_nameNoCustomer display name (e.g., 'Cash Sales'). Will be looked up to get ID.
customer_idNoCustomer ID (use if you already know it, otherwise use customer_name)
due_dateNoDue date in YYYY-MM-DD format (optional)
department_nameNoHeader-level department/location name (e.g., '20358', 'Cotati'). Will be looked up to get ID.
department_idNoHeader-level department/location ID (use if you already know it, otherwise use department_name)
memoNoPrivate memo for the invoice (internal, not visible to customer)
customer_memoNoCustomer-facing message visible on the invoice
bill_emailNoEmail address to send the invoice to. Required if you want QuickBooks to email the invoice.
sales_term_refNoPayment terms name (e.g., 'Net 30', 'Due on receipt'). Will be looked up to get ID.
allow_online_credit_card_paymentNoAllow customer to pay this invoice with a credit card online. Must be explicitly set — company defaults do not apply via API.
allow_online_ach_paymentNoAllow customer to pay this invoice via bank transfer (ACH) online. Must be explicitly set — company defaults do not apply via API.
doc_numberNoReference number for the invoice (optional)
linesYesArray of line items. Each line references an item (product/service). Provide item_name OR item_id (name preferred).
draftNoIf true, validate and show preview without creating (default: true)
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses automatic ID lookups, draft mode behavior, and that online payment flags must be explicitly set (company defaults don't apply). This adds significant behavioral context beyond the schema, though rate limits or auth needs are not mentioned.

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?

The description is compact (4 sentences) and front-loaded with the core purpose. Every sentence adds value, with no redundant information. It is efficient and easy to parse.

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?

Given the tool's complexity (15 parameters, no output schema), the description covers key aspects: mandatory fields, lookup behavior, line item requirements, draft mode, and online payment flag handling. It could mention error handling for failed lookups, but overall it is thorough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds critical meaning: explains the lookup mechanism for names, the requirement for customer, the line item structure (SalesItemLineDetail), and the draft default. This goes beyond the schema descriptions, providing essential context for correct usage.

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?

The description clearly states 'Create an invoice' and specifies it accepts names for automatic ID lookup. This differentiates it from sibling tools like create_sales_receipt, establishing a distinct verb+resource scope.

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?

It explicitly states that either customer_name or customer_id is REQUIRED, and that lines use SalesItemLineDetail rather than accounts, providing clear context. However, it does not explicitly list when not to use this tool or name alternatives beyond what is implied by sibling tools.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/laf-rge/quickbooks-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server