Skip to main content
Glama

Invio Xero MCP

create_xero_quote

create_xero_quote

Proposes creating a new quote 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 created, sent, or delivered. 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, Xero's "SENT" status is only an internal label - this connector has no way to email or deliver the quote to the customer at any status, and never will on its own; a human still shares it from within Xero itself, or another channel, whenever they choose to. 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. You CAN also set a quoteNumber, reference, expiryDate, title, summary or terms whenever the user gives you one - every one of them is optional and Xero fills in its own sensible default (an auto-assigned number, no expiry, blank text) when omitted. DATES: date and expiryDate 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 a quote 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
dateYesDate the quote was issued, 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.
termsNoTerms and conditions text shown on the quote.
titleNoA short title for the quote (e.g. "Kitchen renovation"), shown at the top of it.
statusNoWhat state the quote lands in inside Xero once a human approves this in Invio. Defaults to "DRAFT". Xero also documents "SENT" as directly creatable, but SENT is only Xero's own internal status label - choosing it does NOT email or deliver the quote to the contact, and this connector has no way to do that at any status. Only pass "SENT" when the user explicitly wants the quote marked that way in Xero (e.g. because they already shared it some other way); otherwise leave this as the default.DRAFT
summaryNoA longer free-text summary of what the quote covers.
currencyNoThe currency this quote is raised in, e.g. "NZD". Set this whenever the user names a currency or a currency symbol ("NZ$1,500", "quote 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 quote is then raised in the organisation's own base currency.
contactIdYesThe Xero contact this quote 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 quote.
expiryDateNoDate this quote expires, YYYY-MM-DD. Set it whenever the user says one ("valid for 30 days", "expires end of month"). 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.
quoteNumberNoA specific quote number to use, if the user names one. Omit this and Xero assigns the next number in its own sequence automatically - that is the right choice unless the user explicitly asks for a particular 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. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations provide only broad hints (readOnlyHint false, openWorldHint true), so the description carries the full burden. It discloses the pending-approval queue, that a human must approve before Xero is touched, that the agent cannot approve it, that no email/delivery is ever possible, and that currency is validated against the organisation's configured list. This is exceptionally transparent behavior disclosure beyond what annotations could express.

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 its length is earned by the tool's complexity and safety-critical approval model. It is front-loaded with the most important caveat (does NOT create in Xero). There is some repetition around 'no way to email/deliver' and 'do not describe as created/sent/delivered,' which is arguably justified for safety but prevents a perfect conciseness score.

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 13-parameter tool with no output schema, the description covers everything an agent needs: the pending-change workflow, the approvalUrl field in the response, the required contact lookup flow, date parsing rules, status semantics, and optional field defaults. Nothing critical is missing for correct invocation.

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 schema description coverage is 92%, the description adds substantial meaning beyond the schema: it explains bare numeric date ambiguity with the day-first convention, gives concrete examples for lineAmountTypes ('$1,500 plus GST'), clarifies currency validation behavior, and states what Xero defaults apply when optional fields are omitted. This is far more than a minimum-viable complement to the schema.

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: it 'Proposes creating a new quote in this Xero organisation' and immediately clarifies it does NOT create anything in Xero itself. This clearly distinguishes it from create_xero_invoice, create_xero_credit_note, and other creation tools, while also differentiating it from get/list quote tools.

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 gives explicit when and how guidance: it names list_xero_contacts as the source for contactId, instructs using create_xero_contact first if the contact doesn't exist, and explains when 'SENT' status is appropriate versus the default. It also tells the agent what to tell the user and what not to claim, leaving no ambiguity about the approval-gated workflow.

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