Skip to main content
Glama

Create invoice

create_invoice
Destructive

Creates a new invoice from the given recipient, line items and discounts. Use it for a new invoice written from scratch; for a repeat of earlier work use create_invoice_from_previous. By default it creates a draft, which is free and can still be edited or deleted; a finalized invoice cannot be deleted. With isDraft=false it creates a finalized invoice and spends credits. Finalizing uses one free invoice if any remain, otherwise it deducts the per-invoice price from the credit balance. It fails when the balance is too low, and the charge is not refunded. invoiceDate and dueDate are written in the sender's date format, the dateFormat field of get_sender_settings (for example DD.MM.YYYY). A date that cannot be read as day, month and year in that format is rejected. The check goes no further: a date written in another format with the same separator is read in the expected order (03/04/2026 is 3 April in DD/MM/YYYY and 4 March in MM/DD/YYYY), a day past the end of its month rolls into the next one (31.02.2026 becomes 3 March), and a two-digit year is read as 19xx (26 is 1926). Left out, they default to today and today plus the payment terms; currency, VAT rate and style default from the sender settings, which must already exist. Line item prices take unitPrice (decimal, e.g. 110.00) or unitPriceCents (integer, e.g. 11000); VAT rates are basis points (1900 = 19%). Side effect: the recipient gets a customer record if none exists under that company name, created from the recipient details of the invoice, and the invoice is linked to it. An existing customer record is not changed. It does not email anyone. Each call creates another invoice, so repeating a call that succeeded leaves a duplicate.

Input Schema

NameRequiredDescriptionDefault
dueDateNoDue date in the sender's date format (dateFormat from get_sender_settings). Defaults to today + payment terms if omitted.
isDraftNoCreate as draft (free, default) or final (charges credits)
currencyNoCurrency code (e.g. EUR, USD). Defaults to sender settings currency if omitted.
discountsNoInvoice-level discounts
lineItemsNoInvoice line items
vatRateBpsNoDefault VAT rate in basis points (e.g. 1900 = 19%). Defaults to sender settings if omitted.
invoiceDateNoInvoice date in the sender's date format (dateFormat from get_sender_settings, e.g. 31.12.2026 for DD.MM.YYYY). Defaults to today if omitted.
invoiceNoteNoNote/footer text for the invoice
invoiceStyleNoInvoice PDF style. Defaults to sender settings if omitted.
invoiceNumberNoInvoice number
recipientCityNoRecipient city
shippingCentsNoShipping cost in minor units
buyerReferenceNoBuyer reference / PO number
recipientEmailNoRecipient email
recipientStateNoRecipient state/province
recipientVatIdNoRecipient VAT ID
recipientStreetNoRecipient street address
recipientCountryNoRecipient country ISO code (e.g. DE, US)
recipientPostalCodeNoRecipient postal code
recipientCompanyNameNoRecipient company name
recipientAddressLine2NoRecipient address line 2

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

The description adds rich behavior beyond the annotations: drafts are free and editable/deletable, finalized invoices spend credits, cannot be deleted, and low-balance failures are not refunded. It also discloses side effects such as automatic customer creation, no emailing, and duplicate invoices on repeated calls, all consistent with the destructive and non-idempotent hints.

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 front-loaded and mostly earns its length because the tool is complex and has significant financial side effects. However, a few passages repeat schema details such as unit price and VAT basis-point examples, which slightly reduces concision.

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

Completeness5/5

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

For a 21-parameter creation tool with no output schema, the description is unusually complete: it covers billing behavior, draft/final modes, date defaults and format risks, customer-record side effects, no emailing, and duplicate-call behavior. An agent has enough context to call it correctly.

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 coverage is 100%, so the baseline is 3, but the description adds useful semantics around date formats and parsing edge cases, defaults from sender settings, and unitPrice versus unitPriceCents. Some parameter information duplicates the schema, but the date-format caveats are genuinely additional meaning.

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 gives a specific verb and resource: creates a new invoice from recipient, line items and discounts. It explicitly distinguishes this from the sibling create_invoice_from_previous, so an agent can route correctly without inspecting schemas.

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

Usage Guidelines5/5

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

It clearly states when to use this tool versus the alternative: new invoice from scratch, or create_invoice_from_previous for repeat work. It also explains the critical draft-versus-finalized mode choice and its cost consequences.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources