# Is there an MCP server for Infusion?

On 6 September 2026 we could not find a public MCP server for Infusion apart from Atso's, which reads the books and cannot write to them.

Published: 2026-09-07
Source: https://atso.ai/blog/infusion-mcp-server/

---

## 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](/blog/mcp-server-for-business-software/) 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](https://github.com/search?q=infusion+mcp&type=repositories)**, 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](https://infusion.nz/finance-accounting) 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](/blog/claude-multiple-xero-organisations/) 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.