What is an MCP server for Infusion?
An MCP server is the piece that lets an AI chat read a business system directly, so nobody has to export a spreadsheet first. MCP is the Model Context Protocol, an open standard for connecting AI assistants to outside tools and data. An MCP server for Infusion would let Claude ask Infusion for a customer, a job or a stock item and get structured data back instead of a screenshot. The longer answer to what an MCP server for business software is sits in its own post.
Atso is one MCP connection that lets the AI chats your team already uses, Claude, ChatGPT and Gemini, read your business software across every account and organisation you own, with control over who can see what. Atso runs an Infusion connector. That connector can only read.
Infusion describes itself as “one connected platform for your financials, inventory, purchasing, sales and operations”, and as 100% New Zealand owned and operated. It is the kind of software an engineering shop, a trade business or a rural supplier runs the whole company on, and it sits outside the group of global platforms that AI tooling tends to cover first.
Is there an MCP server for Infusion?
On 6 September 2026 we could not find a public MCP server for Infusion, other than Atso’s. That is a search result on one date, not a proof that nothing else exists. Anyone can publish an MCP server tomorrow, and plenty are never listed anywhere.
Here is what we checked on that date, so you can repeat it:
- The Glama MCP registry, which indexes more than 82,000 servers. A query for “infusion” returns Enfusion and Arma Reforger modding servers, and no accounting server.
- GitHub, scoped to “Infusion Business Software” and to infusion.nz alongside “mcp server”. Nothing came back.
- Infusion’s own website: the home page, the FAQ page, the finance and accounting page and the desktop integrations page. None of them mention MCP, AI, or an AI assistant.
The integrations page is the interesting one. It lists about twenty named integrations, including Xero data transfer, Xtracta, Shopify, Windcave and payroll. Every one of them moves data between two business systems. None of them connects an AI chat.
Why does this search return a game engine?
Because Enfusion, with an E, is the engine behind Arma Reforger, and modding it with AI is a genuinely popular use of MCP. The top result for “infusion mcp server” is an MCP server for “Arma Reforger / Enfusion engine modding”, which promises to create mods from natural language.
That single letter is why the question is hard to answer by searching. The first page of results answers a question about video games. A reader running a wholesale business in Hamilton has to scroll past all of it and then guess.
Why can this connector not write to your books?
Because Infusion has no test or demo company, so every request goes against a real client’s live books. There is no safe place to be wrong.
That constraint is not a detail, it decides the design. When a developer builds against a big platform, there is usually a sandbox: a fake company with fake invoices, where a bad request costs nothing. Without one, the first time any code touches Infusion, it touches somebody’s actual general ledger, actual debtors and actual stock levels.
A connector that cannot write cannot damage those books. It cannot post a journal by mistake, cannot half-create an invoice when a request times out, and cannot be talked into a write by a cleverly worded prompt. The worst case for a read-only connector is that it returns the wrong number and a person notices, which is a very different worst case from a ledger that needs repairing.
The trade is real, and it is worth saying plainly: you cannot ask Claude to raise an invoice in Infusion through Atso, and that is not a limitation we plan to remove quietly.
How is read-only enforced rather than promised?
It is enforced in code. The HTTP client is built so it can only send a GET request, and a test counts the outbound call sites so that stays true as the code grows.
Most “read-only” claims in integration documentation are a promise about intent. Somebody decided not to call the write endpoints. That holds until the day a developer in a hurry adds one, because nothing in the system objects.
Two mechanisms make it stronger here. The first is the client itself: there is one way out to Infusion and it does not take a verb, so there is no POST, PUT, PATCH or DELETE to reach for. The second is the test that counts the call sites. If someone adds a second way to make an outbound request, the count changes and the test fails, so a new escape route has to be a deliberate, reviewed decision rather than an accident.
What can Claude actually answer about Infusion data?
It can list records, open a single record in detail, and then do the arithmetic itself. The connector exposes three tools: one that lists the Infusion connections an owner has attached, one that lists records for a resource, and one that fetches a single record in full.
Fifteen resources can be listed, and twelve of them can be opened in detail.
That shape follows Infusion’s cloud API, which offers per-resource list and get endpoints rather than ready-made reports. So the report is assembled at the AI’s end. You ask a question in plain language, Claude pulls the records it needs, and the summary comes from those records rather than from a reporting screen somebody built in advance. That is the part people tend to like: the question does not have to match a report that already exists.
It also means the answer is only as good as the records it read, and a large question can mean a lot of small reads. A question about one month of a single resource is quick. A question that spans years of transactions is not.
Infusion’s own FAQ page notes that Infusion Online is a cloud based system and all data is stored in a private cloud based in New Zealand. If your business cares where the books live, that is worth reading in full before you connect anything to them, ours included.
How does this compare with an MCP server for Xero or Zoho Books?
The big platforms ship write-capable servers, and on a platform with no sandbox the responsible version is narrower on purpose. Zoho’s own writing on the subject sets the expectation clearly: with an accounting MCP server, “whether it’s creating transactions, doing bank reconciliations, or interpreting your financial reports, your AI assistants can now do much more than answer questions.”
That is a reasonable thing to build when there is a sandbox to test against, a large engineering team behind the API, and a support path when a write goes wrong. Infusion is a smaller regional platform, which is one reason nobody had connected it to an AI chat before, and one reason the version that exists is careful.
There is a New Zealand precedent for the narrow approach. An MCP server for Akahu, the New Zealand open banking service, exposes that data to AI agents like Claude with no write operations at all. Bank feeds are not the ledger, so it does not answer the Infusion question, but it shows the same judgement: on financial data, reading is the useful part and writing is where the damage lives.
Atso’s Xero side is wider, because Xero is wider. It covers nine tools, several organisations at once, and grouped reporting across them. The Infusion side is three tools and no writes. Both sit behind the same connection, and the difference between them is the platform, not a change of principle.
What should you ask before connecting an AI chat to your accounting system?
Ask what it can change, and how that limit is enforced. “It only reads” is a sentence. “The client cannot send anything but a GET, and a test fails if that changes” is a mechanism. The difference matters most on the systems where nobody is watching a sandbox.
Two more worth asking. Who holds the tokens, and can you see and revoke every AI client that holds one? In Atso an owner can see every AI client with a token on the Agents page and revoke it, and the revocation takes effect on that client’s next call.
If you run Infusion and you have been searching for this because you wanted the answer, the answer on 6 September 2026 is that one connector exists, it reads your books, and it is built so it cannot do anything else.