Skip to main content
Glama

Invio Xero MCP

list_xero_payroll_earnings_rates

list_xero_payroll_earnings_rates
Read-only

This organisation's payroll earnings rates (Ordinary Time, Overtime and similar) - name, earnings type, rate type and, where set, the rate itself (a per-unit rate, a multiplier of the ordinary earnings rate, or a fixed amount - only one of the three applies, depending on rateType). Read-only, for Australian, New Zealand and United Kingdom organisations. For Australia, each employee's own ordinaryEarningsRateId (from list_xero_payroll_employees) remains the right default for that employee's own ordinary hours - use this tool when you need a DIFFERENT rate (overtime, an allowance, and similar), since Australia's full list is now readable too, not just the one rate an employee record carries. 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. Use this before drafting a New Zealand or United Kingdom timesheet (create_xero_timesheet) - each timesheet line needs a real earningsRateId, and an employee record for those two regions carries no earnings rate of its own to fall back on. When the user has not named a specific rate, use the one whose earningsType is RegularEarnings (New Zealand/United Kingdom) for ordinary hours worked; say so rather than guessing at a name. Returns up to 100 rates for the requested page.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo1-based page number. Omit for page 1.
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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, and the description adds meaningful context beyond them: refusal behavior (refuses plainly rather than returning an empty list when prerequisites are missing), prerequisites (Payroll setup complete, admin access at connection time), geographic scope (AU/NZ/UK), and a 100-rate pagination limit. No contradiction with annotations.

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?

Long (~200 words) but every sentence earns its place given the regional complexity, prerequisites, and fallback logic. Front-loaded with the core purpose before diving into usage guidance. The only minor inefficiency is that the AU/NZ/UK scope is stated early and the geographic detail is re-emphasized in the timesheet context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/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 return-format burden and does so adequately: it names the fields returned and the rate-type variants. It also covers prerequisites, refusal behavior, regional scope, pagination, and a default-selection rule. Nearly complete; the only minor gap is not describing the exact response envelope or whether rates are ordered.

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?

Schema description coverage is 100% — both parameters (page, organisation) are already documented in the schema. The description adds the pagination limit context ('Returns up to 100 rates for the requested page') which slightly enriches the page parameter, but mostly the schema carries the semantic load, so baseline 3 is appropriate.

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 (list) + resource (payroll earnings rates) and enumerates the returned fields (name, earnings type, rate type, rate). It distinguishes itself from sibling tools by the three-way rate interpretation (per-unit, multiplier, fixed amount) and by explicitly contrasting with list_xero_payroll_employees' ordinaryEarningsRateId, so an agent can tell them apart without opening schemas.

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?

Exceptionally explicit: names when to use (Australia needs a DIFFERENT rate; NZ/UK timesheets) and when not to (Australia ordinary hours fall back to employee's own ordinaryEarningsRateId). Names the alternative tools (list_xero_payroll_employees, create_xero_timesheet) and even prescribes a default selection (RegularEarnings) when the user hasn't specified. Nothing is left to inference.

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