Invio Xero MCP

create_xero_leave_application

create_xero_leave_application

Proposes a DRAFT leave application for one employee/period, for Australian, New Zealand or United Kingdom organisations - it does NOT touch Xero itself, and never will on its own. This queues a pending change that a human must explicitly approve (your Xero MCP connector - the exact link is this response's own approvalUrl field) before Xero is touched at all; you have no way to approve it yourself. employeeId must come from list_xero_payroll_employees (never invented), and must currently be ACTIVE - this refuses plainly for a terminated employee. leaveTypeId must come from list_xero_payroll_leave_types (never invented) - call that tool first if you do not already have a real id for the leave type the user named. description is required (max 50 characters) and is shown to the human approver; title is an OPTIONAL, Australia-only short title, silently ignored for New Zealand/United Kingdom. Do NOT compute or pass an hours/units figure - none exists on this tool, because Xero itself works out the number of units automatically from the employee's own payroll calendar; guessing at one here would only be wrong. Once approved, the leave application is IMMEDIATELY USABLE in Xero (the same status an ordinary, already-actioned leave application carries on every region this connector serves) - unlike create_xero_timesheet/create_xero_pay_run, there is no further Xero-side draft state left for a human to review afterwards, so approving this change in Invio is the only approval this leave application ever needs.

Input Schema

TableJSON Schema

Name	Required	Description
`title`	No	A short title for the leave (e.g. "Annual Leave") - AUSTRALIA ONLY. New Zealand and the United Kingdom have no separate title field at all on this operation - this is silently ignored for those two regions if given.
`endDate`	Yes	End of the leave, YYYY-MM-DD. If the user wrote a bare numeric date with no month name ("9/8", "08/09"), do NOT settle it on your own judgement - it is 9 August to most of the world and 8 September in the US, and nothing downstream of this field can tell which you meant once it is a date. Follow the DATES instruction in this tool's description.
`startDate`	Yes	Start of the leave, YYYY-MM-DD. If the user wrote a bare numeric date with no month name ("9/8", "08/09"), do NOT settle it on your own judgement - it is 9 August to most of the world and 8 September in the US, and nothing downstream of this field can tell which you meant once it is a date. Follow the DATES instruction in this tool's description.
`employeeId`	Yes	Get this from list_xero_payroll_employees first - never invent one.
`description`	Yes	A short description of the leave (e.g. "Annual leave - family holiday"), up to 50 characters. Required by Xero itself for New Zealand and the United Kingdom, and required here for Australia too, even though Xero itself does not require it there - so every leave application a human reviews names what it is for.
`leaveTypeId`	Yes	Get this from list_xero_payroll_leave_types first - never invent one.
`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.8/5.0

Behavior5/5

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

Beyond annotations, it discloses the draft/pending-change workflow, the human-approval requirement, the agent's inability to approve, refusal for terminated employees, the region-specific silent ignoring of title, and immediate usability after approval. This is rich behavioral context that the annotations alone do not provide, and there is no contradiction with readOnlyHint=false.

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 long and dense, but the core behavior is front-loaded and nearly every sentence carries an operational constraint. Some repetition around Xero not being touched and the approval requirement keeps it from a 5 on conciseness, but it is still highly efficient for the tool's complexity.

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?

The description covers nearly all non-obvious context: approval workflow, prerequisites, regional differences, and post-approval behavior, and even mentions the response's approvalUrl despite there being no output schema. However, it references a 'DATES instruction in this tool's description' that is not actually present in the provided description, leaving ambiguous-date handling slightly incomplete.

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

Parameters5/5

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

Even though schema coverage is 100%, the description adds substantial meaning: employee must be ACTIVE, ids must never be invented, description is shown to the human approver, title is Australia-only, and no hours/units parameter exists. It reinforces and extends what the input schema already specifies.

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 opens with a specific verb and resource: 'Proposes a DRAFT leave application for one employee/period', scoped to Australian, New Zealand, and United Kingdom organisations. It immediately clarifies the tool does not touch Xero itself, which distinguishes it from the other create_xero_* siblings.

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 explicitly prescribes predecessor calls: employeeId must come from list_xero_payroll_employees and leaveTypeId from list_xero_payroll_leave_types, with 'call that tool first if you do not already have a real id'. It also says not to pass an hours/units figure, and contrasts its approval lifecycle with create_xero_timesheet/create_xero_pay_run, giving clear when-to-use and when-not-to guidance.

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?