Skip to main content
Glama

Invio Xero MCP

create_xero_manual_journal

create_xero_manual_journal

Proposes a manual journal (a general-purpose double-entry adjustment - reallocating an expense between accounts, recording a bank fee, writing off a small balance, and similar) 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. Every line needs a real accountCode from list_xero_accounts - unlike an invoice line, a journal line has no default account to fall back to, so never invent one. lineAmount is SIGNED: positive = a debit, negative = a credit - this is Xero's own convention, and getting it backwards silently swaps a debit for a credit in a real ledger. Every line together must sum to exactly zero - an unbalanced entry is rejected before anything is queued, with the exact imbalance named so you can fix it. Tell the user plainly which accounts are debited and which are credited, by how much, and that it needs their approval in Invio before it goes anywhere - never describe it as posted or done. Even once approved, this only ever creates a DRAFT journal inside Xero - a human still posts it themselves from inside Xero, this connector never does that. You CAN also say whether a taxed line's amount includes tax (lineAmountTypes): use "Inclusive" for "$1,500 including GST", "Exclusive" for "$1,500 plus GST", "NoTax" for no tax at all. This only changes anything on a line that also names a taxType - a line with no taxType is unaffected either way. Omit it and Xero applies its own default for a manual journal, which this connector does not claim to know. Never adjust the amounts yourself to fake a tax treatment. 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 manual journal 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
dateYesDate the journal is posted, 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.
lineItemsYesAt least two lines, each with a signed lineAmount (positive = debit, negative = credit) and a real accountCode. The lineAmounts across every line must sum to exactly zero - this is checked before anything is queued, not left for Xero to reject after approval.
narrationYes
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 Xero reads every lineAmount below on any line that names a taxType. "Exclusive" = the amounts do NOT include tax and Xero adds it on top - "$1,500 plus GST". "Inclusive" = the amounts ALREADY include tax and Xero works the tax out of them - "$1,500 including GST", "$1,500 inc GST", "$1,500 all up". "NoTax" = no tax is calculated on any line. Set this whenever the entry has a tax dimension at all (a GST or VAT correction, a BAS adjustment, reallocating a tax-coded expense) and say which one you used. Omit it only for an entry with no tax in it, where Xero applies its own default. Never adjust the amounts yourself to fake a tax treatment, and never assume a bare "$1,500" is one or the other - ask if the user did not say.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • removedInput schema / properties / lineItems / items / additionalProperties
      Removed value: -false
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Richly discloses behavior beyond the annotations: the call only queues a pending change, a human must approve via the approvalUrl in the response, the agent cannot approve, and even after approval only a DRAFT journal exists in Xero. It also names the validation rule and failure mode (unbalanced entries rejected before queueing with the exact imbalance reported).

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?

Front-loaded with the most important fact (it is a proposal, not a write), but the description is very long and repeats material already in the schema field descriptions, notably the date ambiguity warning and the signed lineAmount convention. The tax paragraph is dense and could be tightened without losing meaning.

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 a mutation tool with no output schema, the description covers prerequisites (list_xero_accounts), approval lifecycle, validation rules, tax semantics, date interpretation, and user-facing communication obligations. Nothing an agent needs in order to call it correctly appears to be missing.

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?

Adds substantial meaning over the schema despite 80% coverage: lineAmount is signed with debit/credit convention and the consequence of getting it backwards, lines must sum to zero, lineAmountTypes only affects lines that name a taxType, and date ambiguity for bare numeric formats has an explicit resolution policy rather than a guess.

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 ('Proposes a manual journal') and immediately defines the resource with concrete examples (reallocating an expense, bank fee, write-off). It also disambiguates from sibling write tools by stressing it 'does NOT create anything in Xero itself', so an agent can tell it apart from create_xero_invoice or create_xero_payment.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operational guidance: get accountCode from list_xero_accounts, never invent one, never call this expecting immediate posting, and tell the user it needs their approval. It contrasts a journal line with an invoice line to explain the schema difference. It stops short of naming when an agent should pick a journal over e.g. create_xero_invoice for a given real-world scenario.

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