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

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. Changed7 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • removedInput schema / properties / date / $ref
      Removed value: -"#/properties/fromDate"
    • addedInput schema / properties / date / pattern
      Added value: +"^\\d{4}-\\d{2}-\\d{2}$"
    • addedInput schema / properties / date / type
      Added value: +"string"
    • removedInput schema / properties / toDate / $ref
      Removed value: -"#/properties/fromDate"
    • addedInput schema / properties / toDate / pattern
      Added value: +"^\\d{4}-\\d{2}-\\d{2}$"
    • addedInput schema / properties / toDate / type
      Added value: +"string"
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only give readOnlyHint/openWorldHint; the description carries the real behavioral burden and does so thoroughly: server-side arithmetic that must not be re-derived, no intercompany elimination, no account mapping, no currency conversion, single-currency refusal with per-org currency listing, all-or-nothing failure with no partial totals, and reporting of `warnings`/`conflicts`. This is exactly the context annotations cannot supply.

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?

Front-loaded correctly — the identity of the tool, its read-only nature and the not-a-consolidation warning come before any mechanics. It is a dense, long block, though, and some rules (the date-pairing rules for profit_and_loss and balance_sheet) restate the schema verbatim and could be trimmed 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?

For a five-parameter, output-schema-less aggregation tool whose failure modes are non-obvious, the description covers everything an agent needs: date semantics, matching semantics, null-versus-zero, currency constraints, partial-failure policy, output field meaning, and the correct user-facing vocabulary. There is no meaningful gap left for the caller to guess.

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 100%, so the baseline is 3, and much of the description's parameter text (date pairing, end-of-month behaviour, display names, 30-org cap) duplicates the schema verbatim. It does add genuine meaning beyond the schema, though: that `companies` selection is bounded by the org's base currency, that restricted team members only ever see their own orgs, and that `matchedBy`/`values` positionally line up with `columns` with null meaning no figure rather than zero.

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?

Opens with a specific verb-resource-scope statement: side-by-side P&L or Balance Sheet across several Xero organisations, one row per account, one column per org plus Total. It explicitly contrasts itself with get_xero_profit_and_loss and get_xero_balance_sheet, so an agent can pick the right sibling without opening any schema.

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?

Names when to use it (multi-org) versus the single-org siblings, plus concrete decision rules: omit `companies` for all orgs, pass `companies` by display name to narrow, retry with a reduced `companies` list only if the person agrees to drop the failed org. It even covers the 'different financial year ends' case and tells the agent to ask first.

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