Skip to main content
Glama

Invio Xero MCP

create_xero_credit_note

create_xero_credit_note

Proposes creating a new credit note in this Xero organisation - it does NOT create anything in Xero itself, and never will on its own. This queues a pending change that a human must explicitly approve (your Xero MCP connector - the exact link is this response's own approvalUrl field) before Xero is touched at all; you have no way to approve it yourself. Tell the user what you are proposing (contact, ACCRECCREDIT or ACCPAYCREDIT, line items, total) and that it needs their approval in Invio before it goes anywhere - do not describe it as done, issued, or created. contactId must come from list_xero_contacts (never invented); if the contact doesn't exist yet, propose it with create_xero_contact first and wait for that to be approved and executed. Even once approved, this only ever creates a DRAFT credit note inside Xero - a human still authorises and applies or refunds it from within Xero itself, this connector never does that. You CAN state a currency (currency, e.g. "NZD") when the user names one - it is checked against the organisation's own configured currencies, and refused with the real list if it is not one of them, so a currency is never silently swapped for the base currency. You CAN also say whether the amounts include tax (lineAmountTypes): use "Inclusive" for "$1,500 including GST", "Exclusive" (the default) for "$1,500 plus GST", "NoTax" for no tax at all. Never adjust the numbers yourself to fake either one. DATES: date is strict YYYY-MM-DD, so you always have to convert whatever the user actually said. A date carrying a month name ("8 Sep", "Sept 8th"), a weekday ("last Tuesday"), or an already-unambiguous full date ("2026-09-08") is yours to convert normally. A BARE NUMERIC date with no month name - "9/8", "08/09", "9-8" - is the one that is not: it means 9 August to most of the world and 8 September in the United States, and getting it wrong puts a credit note a month out in a way nobody skimming the approval card will catch. This Invio account is based in a country that writes the DAY first, so read a bare "9/8" as 9 August, not 8 September. Say in plain words how you read it ("I read 9/8 as 9 August") so the user can correct you before they approve. If their own wording points the other way anywhere in the same request, ask them which they meant instead of picking.

Input Schema

NameRequiredDescriptionDefault
dateYesCredit note date, YYYY-MM-DD. If the user wrote a bare numeric date with no month name ("9/8", "08/09"), do NOT settle it on your own judgement - it is 9 August to most of the world and 8 September in the US, and nothing downstream of this field can tell which you meant once it is a date. Follow the DATES instruction in this tool's description.
typeYesACCRECCREDIT = a credit note against a sales invoice (reduces what this contact owes this business - e.g. a refund or correction on money owed TO the business). ACCPAYCREDIT = a credit note against a bill (reduces what this business owes this contact).
currencyNoThe currency this credit note is raised in, e.g. "NZD". Set this whenever the user names a currency or a currency symbol ("NZ$1,500", "credit them in USD") - it is checked against the currencies this organisation is actually set up to invoice in, and the draft is refused, with the real list, if it is not one of them. Omit it only when the user did not say: the credit note is then raised in the organisation's own base currency.
contactIdYesThe Xero contact this credit note is for. Get this from list_xero_contacts first - never invent one. If the contact does not exist in Xero yet, use create_xero_contact first, wait for it to be approved and executed, then use the contactId it produced.
lineItemsYes
referenceNoFree-text reference shown on the credit note. Per Xero, this is only used for ACCRECCREDIT - omit it for an ACCPAYCREDIT (there, the credit note's own auto-assigned number is what shows as its reference instead).
organisationNoThe Xero organisation to use, by its display name. Only needed if this connection reaches more than one organisation - omit it when there is only one.
lineAmountTypesNoHow to read every unitAmount below. "Exclusive" (the default) = the amounts do NOT include tax and Xero adds it on top - this is what "$1,500 plus GST" means. "Inclusive" = the amounts ALREADY include tax and Xero works the tax out of them - this is what "$1,500 including GST", "$1,500 inc GST" or "$1,500 all up" means. "NoTax" = no tax is calculated at all. If the user says which one they mean, say so here rather than adjusting the numbers yourself.Exclusive

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / contactId / pattern
      Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"
    • removedInput schema / properties / lineItems / items / additionalProperties
      Removed value: -false
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, it discloses the central behavior: no direct Xero write occurs, a human must approve via Invio, the connector cannot self-approve, and even an approved result is only a DRAFT credit note. It also explains currency validation refusal and date-conversion risks.

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 with the core approval-proposal behavior and structured around key risks such as contacts, currency, tax handling, and dates. It is lengthy and occasionally repetitive, but most sentences carry important behavioral guidance for this high-risk mutation tool.

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?

Given the approval workflow, no output schema, and 8-parameter mutation surface, the description is complete enough for correct invocation. It covers prerequisites, approval semantics, draft-only outcome, currency handling, tax interpretation, and date-conversion hazards.

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 already high at 88%, but the description adds meaningful semantics for date ambiguity, currency validation, contactId provenance, lineAmountTypes tax interpretation, and ACCRECCREDIT versus ACCPAYCREDIT. Some parameter guidance is repeated from the schema, but the added cross-field context is substantial.

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 states a specific verb and resource: it proposes creating a credit note in this Xero organisation. It immediately distinguishes the action from true creation by saying it only queues a pending change and never touches Xero itself.

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 gives explicit usage conditions: use list_xero_contacts before contactId, use create_xero_contact and wait for approval if the contact does not exist, and rely on the approvalUrl response field for human approval. It also clearly says not to describe the result as done, issued, or created.

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