Skip to main content
Glama

Invio Xero MCP

get_xero_leave_balances

get_xero_leave_balances
Read-only

This organisation's employee leave balances (annual leave, personal/sick leave and any other leave types Xero has set up) - by name, in the units Xero tracks them in (usually Hours, or Dollars for some New Zealand leave types). Read-only, for Australian, New Zealand and United Kingdom organisations (this refuses plainly for any other country). 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. Pass employeeId to get one employee (from list_xero_payroll_employees); omit it for every active employee. For Australia that means up to 100, one page only - use employeeId for anyone beyond that. For New Zealand and the United Kingdom, "every employee" is capped at 25 (leave balances are a separate call per employee for those two regions, unlike Australia) - truncated: true on the result means more active employees exist than were fetched; say so and suggest employeeId for anyone missing rather than presenting the list as complete. Each balance carries negative: true when the employee has taken more of that leave type than they have accrued - point those out plainly, do not just report the raw number. This tool cannot say whether a leave request has been approved, paid, or reported to any tax authority - only the current balance Xero holds.

Input Schema

NameRequiredDescriptionDefault
employeeIdNoOne employee, by their Xero EmployeeID. Omit for every employee.
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.
includeInactiveNoInclude terminated employees too. Omit or false for active employees only (Xero's own EmployeeStatus: ACTIVE or TERMINATED).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / employeeId / pattern
      Added value: +"^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})$"
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond readOnlyHint/openWorldHint, it discloses supported countries, refusal behavior for unsupported countries or incomplete payroll setup/admin access, pagination and truncation limits, and negative balance semantics. It also states what the tool cannot determine, such as leave approval or tax reporting.

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 description is front-loaded and every major clause carries useful operational information, but it is a single dense paragraph with several long run-on sentences. The content earns its place, though segmentation would improve readability.

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?

Given the lack of an output schema and the tool's regional/pagination complexity, the description is complete: it covers return shape, units, negative balances, truncation, prerequisites, and limitations. An agent has enough information to call it correctly and interpret common edge cases.

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, but the description adds meaningful employeeId semantics: where to get it, what omitting it means, and how regional caps affect fetching all employees. It does not add much for organisation or includeInactive beyond the schema, so it is not a 5.

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?

The description states the exact resource: employee leave balances by name and units, with annual/personal/other leave types. It clearly distinguishes this from leave-request approval/payment tools and points to list_xero_payroll_employees as the source for employeeId.

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?

It gives explicit usage rules: pass employeeId for one employee, omit it for every active employee, and use employeeId beyond Australia's one-page cap. It also explains the NZ/UK 25-employee cap, what truncated:true means, and how to respond when payroll setup or admin access is missing.

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