Skip to main content
Glama

Invio Xero MCP

get_xero_group_report

get_xero_group_report
Read-only

Profit and Loss or Balance Sheet for SEVERAL Xero organisations at once, side by side: one row per account, one column per organisation, and a Total column. Read-only. Every figure and every total is added up on Invio's server - relay the returned numbers, never add, subtract or round them yourself. THIS IS A SIDE-BY-SIDE SUM, NOT A CONSOLIDATION. Intercompany balances (loans, sales or recharges between these organisations) are NOT eliminated and are counted on both sides; accounts are matched only by exact account code, or by exact name where an account has no code - there is NO account mapping, so differently-named or differently-numbered accounts stay as separate rows; and NO currency is converted. Never call the result consolidated statements: say "combined" or "side by side", and say plainly that intercompany items are still in it. SINGLE CURRENCY ONLY: if the chosen organisations do not all report in the same base currency the call is refused and each organisation's currency is listed - tell the person, and offer to run it for the organisations that share a currency. By default it covers EVERY organisation this connector token may use within the account's plan limit (organisations outside the limit are named in warnings); pass companies - display names exactly as list_xero_organisations shows them - to choose some. A team member restricted to certain organisations only ever gets those. IF ANY ONE ORGANISATION CANNOT BE READ (access revoked, a missing report permission, a rate limit, a timeout) THE WHOLE CALL FAILS and names it, with the reason - there is NO partial total. Tell the person which organisation failed and why; only if they agree to leave it out, call again with companies naming just the others. report "profit_and_loss" takes fromDate and toDate TOGETHER (YYYY-MM-DD) or neither (Xero then gives the CURRENT calendar month) - never one alone; "balance_sheet" takes date (Xero reports it as at the END of that month, not the exact day - say "as at [end of month]") and uses only the as-at column per organisation, not Xero's prior-year comparison column. One date range is applied to every organisation, but organisations can have different financial year ends: organisationDetails[].financialYear shows each one's - for "this financial year", only use this tool if they agree, otherwise say they differ. Each row's matchedBy says how it was matched ("account_code", "account_name", "report_label" for subtotals, or "single_organisation" when only one organisation has it); values lines up with columns (organisations in order, Total last) and a null means that organisation has no figure on that row - not zero. Always state the currency and the period when relaying a figure, and report every entry in warnings and every row conflicts to the person - do not smooth them over. Where one organisation is wanted on its own, use get_xero_profit_and_loss or get_xero_balance_sheet instead. Up to 30 organisations per call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dateNobalance_sheet only. As-at date, YYYY-MM-DD. Xero reports the balance sheet as at the END of the month containing this date, not the exact day. Omit for today.
reportYesWhich report to add up across the organisations: "profit_and_loss" or "balance_sheet".
toDateNoprofit_and_loss only. End date, YYYY-MM-DD. Supply together with fromDate, or omit both. Never alone.
fromDateNoprofit_and_loss only. Start date, YYYY-MM-DD. Supply together with toDate, or omit both (Xero then uses the CURRENT calendar month). Never alone.
companiesNoWhich organisations to include, by display name exactly as list_xero_organisations shows them. Omit to include EVERY organisation this connector token may use within the account's plan limit.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only cover readOnly/openWorld, so the description carries the rest and does so richly: server-side summation, no intercompany elimination, account matching only by exact code/name, no currency conversion, all-or-nothing failure with no partial total, plan-limit exclusions surfaced in `warnings`, and the required wording ('combined', not 'consolidated').

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?

It is a single dense block, but nearly every clause carries load-bearing behavior an agent needs. It could be broken into labeled sections (dates, currency, failure mode, output) to improve scanning, but there is little pure filler.

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?

With no output schema, the description fully covers the return shape: `columns` and `values` alignment, Total last, null meaning 'no figure' rather than zero, `matchedBy` values, and the obligation to relay every `warnings` and `conflicts` entry plus the currency and period.

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?

Though schema coverage is 100%, the description adds real semantics beyond it: fromDate/toDate must be supplied together or not at all, the balance-sheet `date` is reported as at month end, `companies` must use exact display names from list_xero_organisations, and organisationDetails[].financialYear matters for one shared date range.

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+resource and scope: a side-by-side P&L or Balance Sheet for several Xero organisations, one row per account, one column per organisation. It explicitly contrasts itself with siblings by naming get_xero_profit_and_loss and get_xero_balance_sheet as the single-organisation alternatives.

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?

Gives explicit when-to-use (multiple orgs, same base currency) and when-not (single organisation, mixed currencies, financial-year-end mismatches), plus named alternatives. It also spells out recovery behavior: only re-call with `companies` if the user agrees to drop the failing organisation.

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