Skip to main content
Glama

Conecto Invoices

Change a draft

invoices_update
Idempotent

Change a draft quote or invoice: give only what changes; customer and items replace the old ones. A sent document can't change: void it with invoices_void and create a new one. Costs $0.01 per call; nothing if it fails.

Input Schema

NameRequiredDescriptionDefault
itemsNo
notesNoPrinted above the lines, e.g. "Thank you for your order" or a project reference.
currencyNoISO 4217, e.g. "USD", "EUR" or "JPY".
customerNoWho the document is for. Link a CRM record with contact_id or company_id, or give name and email (an email that matches a CRM contact links it). What is given here is printed as it is.
due_dateNoYYYY-MM-DD, or null to go back to the default.
e_invoiceNoInvoices and their credit notes as EN 16931 e-invoices (German B2B invoices must be from 2027): factur-x (Factur-X/ZUGFeRD, the XML inside the PDF/A-3) or xrechnung (XRechnung 3.0, its own XML beside the PDF), checked against the EN 16931 schema before sending. "" is the default: none, except that from 2027 an invoice from a German business to a German business above EUR 250 is a factur-x; "none" opts out (a business under the EUR 800,000 turnover allowance until 2028). Needs the customer's country. Default: the profile's.
invoice_idYesThe invoice_id invoices_create returned (quotes and credit notes have one too).
issue_dateNoYYYY-MM-DD, or null to go back to the default.
supply_dateNoYYYY-MM-DD, or null to go back to the default.
valid_untilNoYYYY-MM-DD, or null to go back to the default.
payment_linkNoAn https link to pay this document. Default: the profile's payment_link.
supply_untilNoYYYY-MM-DD, or null to go back to the default.
tax_exemptionNoWhy lines with tax_rate 0 carry no tax, printed on the invoice as the law asks: exempt, zero_rated, reverse_charge (the customer accounts for the VAT), intra_eu (goods to a business in another EU country), export (goods leaving the EU), outside_scope, small_business (a business under its country's small-business VAT exemption, such as UStG §19 or art. 293 B CGI: no line may carry tax). Needed in the EU for any line without tax. Default: the profile's.
vat_exchange_rateNoFor an invoice in another currency than the national one of the business's country: one unit of it in the national currency, for the VAT shown in both. Default in the EU: the European Central Bank's rate for the day of supply; UK businesses give it.
payment_terms_daysNo
tax_exemption_noteNoThe wording printed for the exemption instead of the standard one, e.g. "Steuerbefreit als Kleinunternehmer nach § 19 UStG".

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?

Goes well beyond the annotations (readOnly=false, idempotent=true, destructive=false): it discloses patch semantics ('give only what changes'), the destructive-subtle rule that customer and items replace the old ones wholesale, the draft-only guard, and a per-call cost with a failure-charge exemption. That is exactly the context annotations cannot carry.

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?

Three sentences, each load-bearing: what it changes, how the payload is interpreted, the blocking condition plus alternative, and the cost. Front-loaded with the action and the mutation model.

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 16-parameter mutation with nested objects and no output schema, the definition covers the risky parts (draft-only, replace semantics, cost) that determine correct invocation. Only minor gap is that it says nothing about what a successful call returns or whether the invoice_id changes.

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 88%, so the baseline is 3; the description adds genuinely new semantics beyond it by clarifying that parameters behave as a partial patch and that 'customer' and 'items' are replace-not-merge. It does not touch the 16 individual fields, but the schema already documents those well.

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 ('change a draft quote or invoice') and immediately pins down the operation's nature as a partial update. An agent can distinguish this from invoices_create, invoices_send and invoices_void without opening any schema.

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?

Explicitly names the exclusion ('a sent document can't change') and routes to the alternative workflow with the sibling named: 'void it with invoices_void and create a new one'. The when-to-use condition (draft only) is stated, not implied.

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