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

TableJSON 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. First observed

TDQS

A4.9/5.0
Behavior5/5

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

The description goes far beyond the annotations (readOnlyHint:false, openWorldHint:true, idempotentHint:false, destructiveHint:false) by disclosing the asynchronous approval workflow, the fact that it never touches Xero on its own, the draft-only outcome after approval, currency validation refusal, and the exact handling of lineAmountTypes and ambiguous dates. It also explains that the tool cannot approve changes itself and tells the agent how to communicate this to the user. These are critical behavioral traits not inferable from annotations alone.

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 long but every section earns its place: it is front-loaded with the most critical caveat ('does NOT create anything in Xero itself'), then organized into clear thematic blocks (approval, contacts, currency, lineAmountTypes, dates). The length is justified by the tool's complexity and the high risk of user misunderstanding, but it could be tightened by removing some redundancies with the schema, such as repeating the date pattern warning already present in the parameter description.

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 tool's complexity (8 params, no output schema, critical safety implications), the description is complete: it covers the full workflow (contact prerequisite, proposal, human approval in Invio, draft-only result), provides all necessary parameter semantics, explains response fields (approvalUrl), and addresses edge cases like ambiguous dates and currency validation. An agent can invoke this tool correctly and communicate its behavior to the user without any missing information.

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?

Even though the schema already provides detailed descriptions for most parameters (88% coverage), the tool description adds substantial additional meaning: it explains the DATES rules for converting user input, warns about ambiguous bare numeric dates and how to read them in this organisation's region, details the currency check against configured currencies, and clarifies lineAmountTypes with concrete examples ('Inclusive' for 'including GST'). It also provides workflow semantics for contactId (must come from list_xero_contacts and create_xero_contact if needed). This far exceeds the schema's information.

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 opens with a specific verb and resource: 'Proposes creating a new credit note in this Xero organisation' and immediately clarifies the crucial nuance that it does NOT actually create anything in Xero—it queues a pending change. It clearly distinguishes itself from siblings like create_xero_invoice and approve_xero_pending_change by describing the proposal workflow and prerequisite contact creation, leaving no ambiguity about what the tool does.

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?

The description explicitly states when to use this tool versus alternatives: contactId must come from list_xero_contacts, create_xero_contact should be used first if the contact doesn't exist, and approval is required via Invio (with the approvalUrl in the response). It also includes guidance on currency handling, lineAmountTypes interpretation, and date conversion rules, including a clear directive to confirm ambiguous bare numeric dates with the user. These are precise usage conditions, not just vague context.

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