Skip to main content
Glama

Invio Xero MCP

create_xero_invoice

create_xero_invoice

Proposes creating a new invoice 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, line items, total) and that it needs their approval in Invio before it goes anywhere - do not describe it as done, sent, 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. Once a human approves it in Invio, it is created in Xero in the state you asked for (status) - or, if you say nothing, AUTHORISED: approved and ready to send, with nothing left for anyone to fill in. That is what an ordinary invoicing request means, and approving the change in Invio is already the approval - do not pass status "DRAFT" out of caution, that only makes the user approve the same invoice again by hand in Xero. Pass status "DRAFT" only when the user actually says they want to check or edit it in Xero first. Either way, THIS CONNECTOR NEVER EMAILS THE INVOICE TO THE CUSTOMER - sending it is a separate action a person takes inside Xero, and you have no tool for it, so never tell a user their customer has been sent anything. For a bill (ACCPAY) there is no customer and nothing to send: it is money this business owes, and AUTHORISED means ready to pay. 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 and dueDate are 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 an invoice 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
dateYesInvoice 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.
typeYesACCREC = a sales invoice (money owed TO this business by the contact). ACCPAY = a bill (money this business owes the contact).
statusNoWhat state the invoice lands in inside Xero once a human approves this in Invio. Defaults to "AUTHORISED" - approved and ready for them to send from Xero, with nothing left to fill in - because approving this change in Invio is already the approval, and that is what an ordinary "invoice this customer" request means. Do not leave this as "DRAFT" out of caution: doing so makes the user approve the same invoice a second time, by hand, in Xero. Pass "DRAFT" only when the user actually says they want to check or edit it in Xero first - it then lands unapproved and they have to approve it there too. Either way this connector never emails the invoice to the customer; that stays a deliberate action a person takes in Xero. A bill (ACCPAY) has no customer and nothing to send: AUTHORISED means ready to pay.AUTHORISED
dueDateNoDue date, YYYY-MM-DD. Set it whenever the user says one ("due in 30 days", "by the end of the month"). Omit it and this connector derives one from the organisation's own default payment terms in Xero and tells you which terms it used - but an organisation that has set no default terms cannot have one derived, and you will be told that too, in which case ask the user for a due date rather than leaving it blank. 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.
currencyNoThe currency this invoice is raised in, e.g. "NZD". Set this whenever the user names a currency or a currency symbol ("NZ$1,500", "invoice 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 invoice is then raised in the organisation's own base currency.
contactIdYesThe Xero contact this invoice is for. Get this from list_xero_contacts first - never invent one. If the contact doesn't 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 invoice (e.g. a PO number).
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. Changed1 schema field changed
    • changedInput schema / properties / status / description
      Previous value: -"What state the invoice lands in inside Xero once a human approves this in Invio. Defaults to \"AUTHORISED\" - approved and ready for them to send from Xero, with nothing left to fill in - because approving this change in Invio is already the approval, and that is what an ordinary \"invoice this customer\" request means. Do not leave this as \"DRAFT\" out of caution: doing so makes the user approve the same invoice a second time, by hand, in Xero. Pass \"DRAFT\" only when the user actually says they want to check or edit it in Xero first - it then lands unapproved and they have to approve it there too. Either way this connector never emails the invoice to the customer; that stays a deliberate action a person takes in Xero."New value: +"What state the invoice lands in inside Xero once a human approves this in Invio. Defaults to \"AUTHORISED\" - approved and ready for them to send from Xero, with nothing left to fill in - because approving this change in Invio is already the approval, and that is what an ordinary \"invoice this customer\" request means. Do not leave this as \"DRAFT\" out of caution: doing so makes the user approve the same invoice a second time, by hand, in Xero. Pass \"DRAFT\" only when the user actually says they want to check or edit it in Xero first - it then lands unapproved and they have to approve it there too. Either way this connector never emails the invoice to the customer; that stays a deliberate action a person takes in Xero. A bill (ACCPAY) has no customer and nothing to send: AUTHORISED means ready to pay."
  2. 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
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

The annotations only say readOnlyHint=false, idempotentHint=false, destructiveHint=false, and openWorldHint=true; the description supplies the real behavioral context on top of that. It explains the human-approval gate with the approvalUrl, the fact that this connector never emails the customer, how the accountCode is auto-filled or refused, and how a currency mismatch is refused with the real list. None of that contradicts the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is stated up front and the DATES block is clearly signposted, but the text is roughly 600 words and repeats the bare-numeric-date warning that the date and dueDate schema fields already carry. Repetition weakens focus on a definition this long.

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 10-parameter mutation with a human-approval step and no output schema, the description covers the whole lifecycle: the pending change, the approval link, the default status, the tax-type handling, the currency refusal, and the date-format edge case. An agent has everything it needs in order to call this tool correctly and to tell the user what happens next.

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 90%, so the baseline is 3, and this description earns an extra point by explaining how the parameters interact: AUTHORISED requires a real accountCode on every line, and currency is checked against the organisation's configured currencies. Much of the material is repeated from the field descriptions, but the cross-field consequences add real 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 opens with a specific verb and resource ("Proposes creating a new invoice in this Xero organisation") and immediately distinguishes itself from a direct write: "it does NOT create anything in Xero itself, and never will on its own." It also implicitly separates this tool from approve_xero_pending_change by saying a human must approve the queued change.

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 when-to-use rules: contactId must come from list_xero_contacts and never be invented, and create_xero_contact should be used first if the contact does not exist. It also draws a sharp line between the default AUTHORISED state and the DRAFT state ("Pass status \"DRAFT\" only when the user actually says they want to check or edit it in Xero first"), which is exactly the alternative-choice guidance an agent needs.

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