Most Australian businesses run their books in Xero. When you want Claude to answer questions about cash flow, draft a BAS summary, or reconcile a week of transactions, it needs a safe, structured way to reach that data. A Model Context Protocol server, usually shortened to MCP, is that bridge. It gives Claude a defined set of tools to call, so the model works from live figures in your Xero organisation instead of guesswork. This guide covers what it takes to build one properly, including the Australian tax and compliance details that generic tutorials skip.
What an MCP server does for Xero
An MCP server is a small service that speaks two languages. On one side it talks to Claude using the Model Context Protocol, advertising a list of tools and the inputs each one accepts. On the other side it calls the Xero Accounting API over HTTPS. Claude never sees your Xero credentials or the raw API. It only sees the tools you choose to expose, such as list invoices, get a contact, or fetch a profit and loss report. That boundary is the entire point. You decide exactly what the model can read and what it can do.
For a Sydney bookkeeping practice managing forty client files, the payoff is concrete. A question such as which clients have invoices overdue by more than 30 days becomes a single tool call rather than a manual export and sort. The server does the filtering and returns Claude a clean, short answer.
The Xero OAuth 2.0 flow, where most builds stall
Xero uses OAuth 2.0 with rotating refresh tokens, and this is the step that catches first-time builders. Your server registers as an app in the Xero developer portal, sends the user through a consent screen, and receives an access token plus a refresh token. Access tokens last 30 minutes. Refresh tokens rotate on every use, so you have to store the new one each time or the connection quietly breaks.
Register the app at developer.xero.com and hold the client ID and secret as environment variables, never in source code.
Request only the scopes you need, such as accounting.transactions.read or accounting.reports.read, so a leaked token has a limited blast radius.
Persist the rotating refresh token after every refresh, and treat a failed refresh as a re-consent event rather than a crash.
Record the Xero tenant ID returned at connection, because one login can grant access to several organisations.
Get token rotation right early. Retrofitting it once you have ten client connections live is far more painful than building it in from the first commit.
Designing tools Claude can actually use
A good MCP tool is narrow, clearly named, and returns tidy data. Claude chooses tools from their descriptions, so vague names like query or run lead to poor picks. Prefer explicit tools such as get_overdue_invoices or get_bank_balance, each with a short description of what it returns and when to use it.
Return summarised JSON, not raw API payloads. Xero responses are verbose, and trimming them to the fields that matter keeps Claude focused and cuts token cost.
Add sensible defaults. A profit and loss tool should default to the current financial year, which in Australia runs from 1 July to 30 June, not the calendar year.
Make date handling explicit. Australian reporting maps to quarterly BAS periods, so accept a period argument instead of forcing raw date maths.
Fail clearly. If a tenant is disconnected, return a plain message Claude can relay, not a stack trace.
Handling GST, BAS and the Australian specifics
This is where an Australian-built server earns its keep. Xero tracks GST on every line, and a business registered for GST, which is required once turnover reaches $75,000, lodges a Business Activity Statement to the ATO each quarter. A tool that totals GST collected and GST paid for a chosen period saves an accountant real time.
Be careful with tax codes. Xero uses codes such as GST on Income, GST Free, and BAS Excluded, and mixing them up produces a wrong activity statement. Your server should read the tax code from each transaction rather than assuming a flat 10 per cent. A tool that reconstructs the key BAS labels, including G1 total sales, 1A GST on sales, and 1B GST on purchases, turns a fiddly quarterly job into a review-and-confirm step.
Security, tenancy, and what to keep off limits
Connecting an assistant to financial records raises obvious questions, and the answers belong in the design rather than a disclaimer at the end. The Privacy Act 1988 governs how you handle the personal information inside those records, so data minimisation is both sound engineering and a legal expectation.
Start read-only. Ship reporting and lookup tools well before you consider any tool that creates or edits a transaction in Xero.
Scope every call to a single tenant ID so one client's data can never appear in another client's answer.
Log which tool ran, for which tenant, and when, so you have an audit trail if a client asks what the assistant touched.
Keep secrets in a managed store, and rotate the Xero client secret immediately if it ever lands in a log or a chat transcript.
From prototype to production
A working prototype is a weekend project. A server you would run for paying clients is a few weeks of careful work, and the gap is mostly error handling, token management, and tenant isolation. Budget for that. Paying a developer between $8,000 and $15,000 for a hardened, multi-tenant Xero MCP server is realistic, and it is a small figure next to the manual reporting hours it removes across a year.
If you would rather have this built and supported than maintain it in-house, that is the kind of work we do at Automata AI. You can book a short call to talk through your Xero setup and what a Claude connection would look like for your business.
