Skip to main content
Glama
klodr

mercury-invoicing-mcp

mercury_update_invoice

Update an existing invoice. Pass only the fields you want to change.

Instructions

Update an existing invoice. Pass only the fields you want to change.

USE WHEN: amending an outstanding invoice (line items, due date, memo, PO number) before the customer pays. The MCP fetches the current invoice and merges your changes before submitting — Mercury's update endpoint requires the full payload despite the API docs implying PATCH.

DO NOT USE: to cancel an invoice (use mercury_cancel_invoice). To change the customer or the destination account, cancel + recreate. Once an invoice is paid, updates are likely rejected by Mercury — fetch first to confirm status.

SIDE EFFECTS: overwrites the invoice on Mercury's side. The customer-facing payment URL stays the same. If the invoice was already emailed, the customer is NOT re-notified of the change — communicate the change out-of-band if needed.

RETURNS: { id, status, amount, ... } — the updated invoice.

Input Schema

NameRequiredDescriptionDefault
dueDateNoDue date (YYYY-MM-DD)
ccEmailsNo
poNumberNo
invoiceIdYesInvoice ID
lineItemsNo
payerMemoNo
invoiceDateNoInvoice date (YYYY-MM-DD)
internalNoteNo
invoiceNumberNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.20.3
    • changedInput schema / properties / ccEmails / items / pattern
      Previous value: -"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"New value: +"^(?:[A-Za-z0-9_'+\\-]+\\.)*[A-Za-z0-9_'+\\-]*[A-Za-z0-9_+-]@(?:[A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"
  2. Addedv0.15.6
  3. Removedv0.15.5
  4. Addedv0.15.4
  5. Removedv0.15.2
  6. Changed1 schema field changedv0.12.0
    • addedInput schema / additionalProperties
      Added value: +false
  7. First observedv0.9.1

TDQS

A4.9/5.0
Behavior5/5

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

Goes well past the annotations (destructiveHint=false, openWorldHint=true) by disclosing the hidden full-payload/merge behavior, that the customer-facing payment URL is unchanged, and critically that the customer is NOT re-notified after an emailed invoice is amended. Overwrite here is field-scoped merging, so it does not contradict destructiveHint=false.

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?

Labeled sections (USE WHEN / DO NOT USE / SIDE EFFECTS / RETURNS) with the core behavior front-loaded in the first sentence. Length is justified because each block delivers a distinct, actionable fact.

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?

Despite no output schema, it sketches the return shape ({ id, status, amount, ... }) and covers the mutation lifecycle concerns an agent needs: merge behavior, irreversibility of paid-invoice edits, and the absent customer notification. Nothing essential for correct invocation 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?

With only 33% schema description coverage, the description compensates by enumerating the commonly-changed fields (line items, due date, memo, PO number) and by making the partial-update contract explicit, which is the key semantic for this tool. A few parameters (ccEmails, invoiceNumber, internalNote, invoiceDate) still get no meaning from either source.

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 an existing invoice") and immediately clarifies partial-update semantics with "Pass only the fields you want to change." It is unmistakably distinct from mercury_create_invoice, mercury_cancel_invoice and mercury_get_invoice.

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?

Explicit USE WHEN condition (amending an outstanding invoice before payment) and DO NOT USE block that routes to mercury_cancel_invoice for cancellation and to cancel+recreate for customer/destination changes. It even names a precondition check (fetch first to confirm status) for paid invoices.

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