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.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_xero_payroll_earnings_rates"
  }
}

Input 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. Changed1 schema field changed
    • removedInput schema / additionalProperties
      Removed value: -false
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint and openWorldHint, and the description adds substantial context beyond them: region eligibility (AU/NZ/UK), the requirement that Xero Payroll setup be complete and the connecting user have held payroll administrator access, and the important failure-mode disclosure that a hard refusal must not be reported as an empty list. It also states the 100-item page cap.

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?

The core purpose and region scope are front-loaded, and the longer sentences carry genuinely load-bearing content (auth prerequisites, failure semantics, default-rate rule). It is dense to the point of being a single wall of text with limited visual separation, which slightly hurts scanability, but little is redundant.

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 read-only list tool with no output schema and full schema coverage, the description covers everything an agent needs: what comes back, which regions work, what preconditions can cause failure, how to report a refusal, and how to pick a default rate. No material gap remains.

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 both page and organisation are already documented, establishing a baseline of 3. The description adds useful return-shape context tied to pagination ('up to 100 rates for the requested page'), which helps the agent size its paging strategy beyond what the schema alone conveys.

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 and enumerates the returned fields (name, earningsType, rateType, rate), including the rateType-dependent semantics of the rate value. It clearly separates itself from list_xero_payroll_employees by explaining that this tool exposes the full rate list rather than an employee's single default rate.

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 routing rules: use list_xero_payroll_employees' ordinaryEarningsRateId for an employee's own ordinary hours, and use this tool when a DIFFERENT rate is needed (overtime, allowance). It also mandates calling this before drafting NZ/UK timesheets because each line needs a real earningsRateId, and prescribes a default selection rule (earningsType=RegularEarnings) when the user names no rate.

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