Invio Xero MCP

get_xero_pay_run_summary

get_xero_pay_run_summary

Read-only

What one pay run cost all-in, its status (DRAFT or POSTED), and a comparison against the PREVIOUS pay run of the SAME payroll calendar: each employee paid in both runs, with their net pay and net change; everyone flagged with largeChange: true when that change is 20% or more either way (this connector's own threshold, not Xero's); anyone paid in this run but not the previous one (newThisRun); anyone paid in the previous run but not this one (notPaidThisRun - could mean terminated, on unpaid leave, or simply not rostered this cycle; this tool cannot tell which). Omit payRunId for the most recent pay run. Read-only, for Australian, New Zealand and United Kingdom organisations (this refuses plainly for any other country - see list_xero_payroll_employees for the same gate). Also requires Xero's own Payroll setup to be complete for the organisation, and the Xero user who connected to have held payroll administrator access at the time - if either is missing this refuses plainly rather than returning an empty list, so report that rather than implying the organisation has no payroll data. wages/tax/super on the pay run itself are Australia only; New Zealand and the United Kingdom instead report totalCost - see list_xero_pay_runs for why. A large swing in net pay often reflects a change in hours worked, but can equally be a bonus, an allowance, leave taken or a tax change - say that it moved, not why. THIS TOOL CANNOT SAY WHETHER A PAY RUN HAS ACTUALLY BEEN PAID OUT OR REPORTED TO ANY TAX AUTHORITY (there is no ATO/IRD/HMRC filing status in any of the three regions' Payroll APIs, and never will be) - only what Xero itself has recorded for the pay run.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`payRunId`	No	One pay run, by its Xero PayRunID. Omit for the most recent pay run.
`organisation`	No	The 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.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 27, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Beyond readOnlyHint, it discloses refusal behavior for unsupported countries and missing setup, region-dependent field differences, the connector-specific 20% threshold, ambiguous notPaidThisRun semantics, and the hard limitation about paid-out/tax-filing status. Nothing 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.

Conciseness5/5

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

The core result is front-loaded in the first sentence, followed by the input shortcut, gates, and caveats. Although long, every sentence carries a distinct operational fact, and the capitalized limitation warning is justified by a common misinterpretation.

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 carries the full burden of explaining return semantics, and it does so in detail: employee-level comparison fields, region-specific cost fields, refusal cases, and interpretation warnings. An agent can invoke it safely and phrase the result accurately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already documents both parameters at 100% coverage, so the baseline is 3. The description repeats the omit-payRunId rule but does not add new input-level meaning; its added value is concentrated in output interpretation.

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 the exact deliverable: all-in cost, DRAFT/POSTED status, and comparison against the previous pay run of the same payroll calendar. Names output markers like largeChange, newThisRun, and notPaidThisRun, making it unmistakable from list_xero_pay_runs or other getters.

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?

Provides explicit when-to-use guidance (omit payRunId for most recent), hard regional when-not gates (AU/NZ/UK only; refuses otherwise), and prerequisite gates (Payroll setup complete and admin access). It also instructs how to report a refused result rather than misreading it as empty data.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Invio Xero MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?