Allows interaction with Xero Accounting Software by providing tools to authenticate, list accounts, bank transactions, contacts, invoices, journals, organisations, payments, and quotes.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Xero MCP Server show me my balance sheet for this quarter"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This MCP server allows Clients to interact with Xero Accounting Software.
Make sure node is installed.
Create an OAuth 2.0 app in Xero to get a CLIENT_ID and CLIENT_SECRET.
Create a free Xero user account (if you don't have one)
Login to Xero Developer center https://developer.xero.com/app/manage/
Click New app
Enter a name for your app
Select Web app
Provide a valid URL (can be anything valid eg. https://www.myapp.com)
Enter redirect URI: http://localhost:5000/callback
Note: The redirect URI can be customized, but it must use
localhostand include both an explicit port and a path (e.g.http://localhost:5050/my-path). Set the same value asXERO_REDIRECT_URIin your MCP client config below.
Tick to Accept the Terms & Conditions and click Create app
On the left-hand side of the screen select Configuration
Click Generate a secret
Configure your MCP client:
Go to Settings -> Developers -> Local MCP Servers -> Edit Config and add the following to claude_desktop_config.json:
{
"mcpServers": {
"xero-mcp": {
"command": "npx",
"args": ["-y", "xero-mcp@latest"],
"env": {
"XERO_CLIENT_ID": "YOUR_CLIENT_ID",
"XERO_CLIENT_SECRET": "YOUR_CLIENT_SECRET",
"XERO_REDIRECT_URI": "http://localhost:5000/callback"
}
}
}
}Restart Claude Desktop, or reload via Developer -> Reload MCP Configuration.
Run the following command to add the MCP server:
claude mcp add xero-mcp \
-e XERO_CLIENT_ID=YOUR_CLIENT_ID \
-e XERO_CLIENT_SECRET=YOUR_CLIENT_SECRET \
-e XERO_REDIRECT_URI=http://localhost:5000/callback \
-- npx -y xero-mcp@latestThe server will be available in your next Claude Code session. To make it available across all projects, add --scope user to the command above.
When accessing a Xero tool for the first time, a Xero login page will pop up to ask your consent. Complete the auth flow and manually close the web page (as the Xero page will not auto close in this version)
Privacy alert: after completing the Xero OAuth2 flow, your Xero data may go through the LLM that you use. If you are doing testing you should authorize to your Xero Demo Company.
Related MCP server: xero-mcp-enhanced
authenticate
Authenticate with Xero using OAuth2
create_bank_transactions
Creates one or more spent or received money transaction
create_contacts
Creates one or multiple contacts in a Xero organisation
get_balance_sheet
Retrieves report for balancesheet
get_bank_transaction
Retrieves a single spent or received money transaction by its Xero bank transaction ID
get_invoice
Retrieves a single sales invoice or purchase bill by its Xero invoice ID
list_accounts
Retrieves the full chart of accounts
list_bank_transactions
Retrieves any spent or received money transactions
list_contacts
Retrieves all contacts in a Xero organisation
list_invoices
Retrieves sales invoices or purchase bills
list_organisations
Retrieves Xero organisation details
list_payments
Retrieves payments for invoices and credit notes
list_quotes
Retrieves sales quotes
update_bank_transaction
Updates an existing spent or received money transaction (e.g. line items, contact, bank account) by bank transaction ID
update_invoice
Updates an existing sales invoice or purchase bill (typically a draft), including line items and account codes
"Visualize my financial position over the last month"
"Track my spendings over last week"
"Add all transactions from the monthly statement into my revenue account (account code 201) as receive money"
MIT
Authenticate with Xero using OAuth2
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It mentions OAuth2 but fails to describe critical aspects like user interaction (redirect), side effects, or token management. This is insufficient for an authentication tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at 4 words, but it lacks structure. While no fluff exists, it omits essential context that could be added without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an authentication tool without an output schema, the description should explain the flow, prerequisites, and return value (e.g., token). It does none of this, making it incomplete for complex OAuth2 interactions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters, and schema coverage is 100% trivially. The description adds no parameter information beyond the schema, but none is needed. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Authenticate) and target (Xero using OAuth2), making the tool's purpose straightforward. However, it does not distinguish it from siblings, though authentication is inherently distinct from CRUD operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool (e.g., as a prerequisite for other tools) or exclude any contexts. The agent must infer its role from the sibling tool list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates one or more spent or received money transaction. Only use this tool when user has directly and explicitly ask you to create transactions.
| Name | Required | Description | Default |
|---|---|---|---|
| Warnings | No | Displays array of warning messages from the API | |
| pagination | No | ||
| BankTransactions | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states that the tool creates transactions, but omits details on authorization, idempotency, error handling, or side effects. This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose followed by a usage guideline. No redundant information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of creating bank transactions (nested objects like line items, contacts, bank accounts), the description lacks details on required fields, data structure, and response format. The input schema example helps, but the description itself is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the 3 parameters. Schema coverage is only 33%, and the input schema's example is not referenced. Without parameter details, the agent cannot correctly construct inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Creates') and resource ('bank transactions'), distinguishing it from siblings like 'list_bank_transactions' and 'update_bank_transaction'. The phrase 'spent or received money transaction' is slightly redundant but unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly restricts use to when the user has directly asked to create transactions ('Only use this tool when user has directly and explicitly ask you to create transactions'). This provides clear when-to-use guidance, though it does not name specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates one or multiple contacts in a Xero organisation. Only use this tool when user has directly and explicitly ask you to create contact.
| Name | Required | Description | Default |
|---|---|---|---|
| Contacts | No | ||
| Warnings | No | Displays array of warning messages from the API | |
| pagination | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states it creates contacts, with no details on side effects, validation, or failure modes. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. Each sentence serves a distinct purpose: purpose and usage guideline. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no output schema and no annotations, the description is incomplete. It lacks details on return values, prerequisites, error handling, and expected input structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is low (33%), and the description adds no parameter-level meaning. It only aligns with the 'Contacts' array concept but doesn't explain any parameter details or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates contacts, specifies 'one or multiple', and adds a usage restriction. It distinguishes from siblings like list_contacts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Only use this tool when user has directly and explicitly ask you to create contact', providing a clear when-to-use condition, but no mention of when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a balance sheet for the end of the month of the specified date. It also returns the value at the end of the same month for the previous year.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavior; it fails to explain how the date is determined given zero parameters, and omits read-only nature or other traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence is concise, but it could be more efficient by removing the conflicting 'specified date' phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations, and the description lacks detail on output format, date handling, or any behavioral caveats; incomplete for a tool with zero parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0 parameters but description implies a date parameter, creating inconsistency; the description adds value by specifying output fields but misleads on required input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a balance sheet for a specific end-of-month date with prior year comparison, but ambiguity arises from mentioning 'specified date' while the input schema has no parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like get_bank_transaction or list_accounts, and no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves a single spent or received money transaction by its Xero bank transaction ID
| Name | Required | Description | Default |
|---|---|---|---|
| unitdp | No | Optional. Unit decimal places (e.g. 4) for unit amounts on line items | |
| bankTransactionID | Yes | Xero-generated unique identifier for the bank transaction (UUID) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only says 'retrieves', which implies read-only but does not explicitly confirm non-destructive behavior, auth needs, or error handling. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no filler, front-loaded with verb and resource. Efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple, but no output schema and description doesn't specify return format or error cases. Adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds no extra meaning beyond schema; 'by its Xero bank transaction ID' repeats schema, and unitdp is not mentioned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Retrieves', resource 'single spent or received money transaction', and identifier 'Xero bank transaction ID'. Distinguishes from siblings like list_bank_transactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies use when ID is known but provides no explicit guidance on when to use vs alternatives like list_bank_transactions or update_bank_transaction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves a single sales invoice or purchase bill by its Xero invoice ID
| Name | Required | Description | Default |
|---|---|---|---|
| unitdp | No | Optional. Unit decimal places (e.g. 4) for unit amounts on line items | |
| invoiceID | Yes | Xero-generated unique identifier for the invoice (UUID) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states the tool retrieves data, implying a read-only operation, but does not disclose error behavior (e.g., missing ID), rate limits, or caching. Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no unnecessary words. Directly conveys the tool's function efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 2 parameters, but no output schema exists. The description could mention return format (e.g., full invoice details) but does not. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no extra meaning beyond what the schema already provides (e.g., invoiceID is a UUID). Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a single sales invoice or purchase bill by its Xero invoice ID. The verb 'Retrieves' and resource specification differentiate it from siblings like list_invoices (multiple) and update_invoice (modify).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you have a specific invoice ID, but does not explicitly state when to use this vs alternatives (e.g., list_invoices for unfiltered retrieval) or prerequisites like authentication. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves the full chart of accounts
| Name | Required | Description | Default |
|---|---|---|---|
| order | No | Order by any element | |
| where | No | Filter by an any element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'Retrieves', implying a read operation, but lacks details on side effects, authentication, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. However, it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity and presence of optional parameters for filtering and ordering, the description's claim of 'full chart of accounts' is misleading. It does not mention the filtering capability, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters having descriptions and examples. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieves') and the resource ('the full chart of accounts'), distinguishing it from sibling list tools for other entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like list_bank_transactions or list_contacts. The description does not provide context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves any spent or received money transactions
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Up to 100 bank transactions will be returned in a single API call with line items details | |
| order | No | Order by any element | |
| where | No | Filter bank transactions by any element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, placing full burden on the description. The description only states a generic read operation without disclosing pagination behavior, authorization needs, or result limits. Schema param descriptions add some info, but the description itself contributes minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that quickly conveys the tool's purpose. It is front-loaded and efficient, though it could be slightly expanded for clarity without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and three parameters, the description is insufficient. It does not explain return format, pagination beyond what the schema says, filtering capabilities, or error scenarios. A list tool requires more context to be fully usable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter's purpose. The description adds no additional meaning beyond the schema, such as how parameters interact or when to use them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Retrieves' and clearly identifies the resource 'bank transactions'. It distinguishes from sibling list tools like list_accounts or list_contacts, and contrasts with get_bank_transaction for a single transaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to retrieve transactions, but lacks explicit guidance on when to use this tool vs alternatives like get_bank_transaction. No when-not-to-use or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves all contacts in a Xero organisation
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Up to 100 contacts will be returned in a single API call | |
| order | No | Order by any element | |
| where | No | Filter by any element | |
| searchTerm | No | Case-insensitive text search across Name, FirstName, LastName, ContactNumber and EmailAddress | |
| includeArchived | No | Contacts with a status of ARCHIVED will be included in the response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only says 'retrieves all contacts', omitting that the tool supports pagination, filtering, searching, and archived inclusion (all defined only in schema).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it lacks structure or detail beyond the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description does not describe the return format or any pagination behavior. For a listing tool with optional filters and pagination, more contextual info is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%; all 5 parameters are already described in the schema. The description adds no additional meaning or context to these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all contacts in a Xero organisation, using a specific verb and resource. It distinguishes from sibling write tools like create_contacts, but doesn't differentiate from other list tools (e.g., list_accounts) by resource alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like create_contacts or list_accounts. No prerequisites or context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves sales invoices or purchase bills
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Up to 100 invoices will be returned per page with line items shown | |
| order | No | Order by any element | |
| where | No | Filter invoices by any element | |
| statuses | No | Filter by a comma-separated list of Statuses (DRAFT, SUBMITTED, AUTHORISED, PAID, VOIDED) | |
| contactIDs | No | Filter by a comma-separated list of ContactIDs | |
| invoiceNumbers | No | Filter by a comma-separated list of InvoiceNumbers | |
| includeArchived | No | Include invoices with a status of ARCHIVED |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, side effects, or authorization requirements. It only states what is retrieved without further context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and to the point. However, it could include more structure or additional context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters and no output schema, the description lacks completeness. It does not explain pagination, filtering, or the expected output format, relying entirely on the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes all parameters. The description adds no additional meaning beyond the overall purpose, meeting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves sales invoices or purchase bills, using a specific verb and resource. However, it does not differentiate from sibling tool 'get_invoice' which retrieves a single invoice. A more explicit 'list all invoices' would improve clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_invoice' for retrieving a single invoice. No context for filtering or pagination is mentioned beyond what is in the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves Xero organisation details
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full responsibility. It implies a read operation ('Retrieves') but does not disclose any behavioral traits such as authentication requirements, rate limits, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundancy. It is front-loaded and gets directly to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description is minimally viable. However, it lacks details on what constitutes 'organisation details' and does not specify return format or any output schema, leaving room for ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and schema coverage is 100%. The description adds no parameter semantics, but with no parameters, the baseline is 4. The description is adequate for this case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Retrieves' and the resource 'Xero organisation details'. It is specific enough to distinguish from sibling list tools. However, 'details' is vague and could be more precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves payments for invoices and credit notes
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Up to 100 payments will be returned in a single API call | |
| order | No | Order by any element | |
| where | No | Filter payments by any element |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. Only states retrieval without mentioning side effects, authentication needs, or pagination behavior beyond what the parameter hint provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with no wasted words; could slightly improve by front-loading key constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple list tool with full parameter documentation, but lacks output schema and fails to differentiate from siblings, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions (100% coverage), so baseline is 3; description does not add additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Retrieves') and the resource ('payments'), with specific context ('for invoices and credit notes'), distinguishing it from generic list tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like list_invoices or list_bank_transactions; usage context is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves sales quotes
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Up to 100 quotes will be returned in a single API call | |
| order | No | Order by any element | |
| dateTo | No | Filter for quotes before a particular date (YYYY-MM-DD) | |
| status | No | Filter for quotes of a particular status (DRAFT, SENT, DECLINED, ACCEPTED, INVOICED) | |
| dateFrom | No | Filter for quotes after a particular date (YYYY-MM-DD) | |
| contactID | No | Filter for quotes belonging to a particular contact | |
| quoteNumber | No | Filter by quote number | |
| expiryDateTo | No | Filter for quotes expiring before a particular date (YYYY-MM-DD) | |
| expiryDateFrom | No | Filter for quotes expiring after a particular date (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It only says 'Retrieves sales quotes' with no mention of pagination (although schema hints at it), rate limits, auth, or error handling. The page parameter description in schema says 'Up to 100 quotes...' but that detail is not in the tool description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is structurally simple but appropriate for a straightforward retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters and no output schema or annotations, the description is too minimal. It lacks details about return format, filtering behavior, or any side effects, leaving many usage aspects unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, meaning every parameter has a description in the schema. The tool description adds no additional parameter meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves sales quotes, which is a specific verb+resource combination. It distinguishes from sibling tools like list_invoices and list_bank_transactions by focusing on quotes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives like list_invoices or when not to use it. There are no prerequisites or context cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates an existing spent or received money transaction by its Xero bank transaction ID
| Name | Required | Description | Default |
|---|---|---|---|
| unitdp | No | Optional. Unit decimal places (e.g. 4) for unit amounts on line items | |
| idempotencyKey | No | Optional idempotency key. Allows safe retries without duplicating processing | |
| bankTransactions | Yes | BankTransactions payload containing an array of bank transaction objects | |
| bankTransactionID | Yes | Xero generated unique identifier for the bank transaction (UUID) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the update action but omits details about partial vs full update, idempotency, validation errors, or destructive nature. The idempotencyKey parameter is not mentioned in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 15 words, front-loaded with purpose. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, nested objects, and no output schema, the description is too brief. It lacks information about return values, error handling, update semantics, and behavioral constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds no additional meaning beyond the schema, simply referencing the bankTransactionID parameter indirectly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (updates), the resource (bank transaction), and the identifier (by its Xero bank transaction ID). It specifies spent or received money transactions, which helps distinguish from other transaction types. However, it does not elaborate on which fields can be updated, relying on the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like create_bank_transactions or list_bank_transactions. No prerequisites, when-not-to-use, or edge cases mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates an existing sales invoice or purchase bill (typically a draft) to change fields like line items and account codes
| Name | Required | Description | Default |
|---|---|---|---|
| unitdp | No | Optional. Unit decimal places (e.g. 4) for unit amounts on line items | |
| invoices | Yes | Invoices payload containing an array of invoice objects | |
| invoiceID | Yes | Xero generated unique identifier for the invoice (UUID) | |
| idempotencyKey | No | Optional idempotency key. Allows safe retries without duplicating processing |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It mentions 'typically a draft' but does not disclose what happens if the invoice is not a draft, whether updates are restricted, or any side effects. The parameter 'idempotencyKey' hints at safe retries but is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 16 words, front-loading the core action and typical use case with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex update tool with 4 parameters and nested objects, the description is minimal. It covers the basic purpose but lacks guidance on prerequisites, return behavior, and edge cases. It is adequate but leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for each parameter. The description adds value by summarizing the main updatable fields (line items, account codes), but mostly reiterates what the schema already provides. Baseline 3 is increased to 4 due to the a helpful overview.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates an existing invoice or bill, specifies the typical state (draft), and gives example fields (line items, account codes), distinguishing it from sibling tools like get_invoice and create_invoice.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it's used when you need to modify a draft invoice, but does not explicitly state when to use or when not to use, nor does it mention alternatives like create_invoice for new ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v2.2.1authenticatecreate_bank_transactionscreate_contactsget_balance_sheetget_bank_transactionget_invoicelist_accountslist_bank_transactionslist_contactslist_invoiceslist_organisationslist_paymentslist_quotesupdate_bank_transactionupdate_invoiceEach tool has a distinct purpose: authentication, CRUD for specific entities (bank transactions, contacts, invoices), and read-only lists for accounts, organisations, payments, quotes. No functional overlap, and descriptions clearly differentiate between list/get and create/update operations.
Most tools follow a clear verb_noun pattern (e.g., 'create_contacts', 'list_invoices'). Exceptions include 'authenticate' (no noun) and slight plural/singular inconsistency (e.g., 'create_bank_transactions' vs 'get_bank_transaction'), but overall the naming is predictable and readable.
15 tools is well-scoped for a Xero API server covering core entities: authentication, bank transactions, contacts, invoices, accounts, organisations, payments, and quotes. Each tool addresses a necessary operation without excessive granularity.
The tool set provides basic CRUD for bank transactions and contacts, but lacks create for invoices, quotes, and payments, and omits delete/archive for any entity. This leaves notable gaps for full lifecycle management, though the domain is partially covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for Codat — companies, connections, invoices, bills and financial statements.
Hosted MCP server for Mini Accountant: invoices, expenses, customers, analytics, tax estimates.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/john-zhang-dev/xero-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
