What a read-only connector to your ERP does, and what it doesn't

What it does

Your team asks Claude, Anthropic's AI assistant, the questions they would otherwise send to whoever knows the ERP: has this order shipped, what's open on this account, how much of this do we have in stock. Claude asks the ERP through the connector and answers from what comes back, in plain English.

Nobody learns a new screen, and the questions no longer wait for the one person who knows where to look. Which questions come up most also tells you something: it points at the process worth an agent next.

What it can't do

It can't change anything. It reads; it cannot write. Writing back to your systems is a separate decision, made later and one action at a time, if you want it at all.

It can't show anyone more than they could already see. Each person signs in with their own work account, and the ERP applies that person's own permissions.

It doesn't keep your data. It runs in your own cloud tenant. We don't host it, and no copy of your ERP data sits with us.

Claude sees the answers it's given. Each answer goes into the Claude conversation that asked for it, so it's held by Anthropic under the terms of the Claude plan your team uses. On Anthropic's business plans and its API, Anthropic says (opens in a new tab) it doesn't train its models on your conversations unless someone chooses to send it feedback. Which plan fits, and what your IT team needs to approve, is worth settling before anything is connected.

It doesn't hide anything. Every question leaves a line in your own logs: who asked, which tool, and whether it worked. Never the data that came back.

Doesn't Microsoft make one already?

For Business Central, yes. Business Central online now includes an MCP server (opens in a new tab) that Claude can connect to, read-only by default and limited to what each person can already see. If the answers your team needs sit in its standard API pages, start there. We'd rather set that up with you than build something you don't need.

It stops short when you run Business Central on your own servers or run another system; when the answers sit in custom fields and tables that the standard API pages don't expose; when you want tools shaped around the questions people actually ask, with rules about what each one returns; or when a question crosses two systems. That's when a connector is worth building. Either way, the connector is becoming the standard part. The work is in what you point it at. The longer answer is in the FAQ.

What it took the one time we measured it

For a specialty chemical manufacturer running Microsoft Dynamics 365 Business Central, it went live within a week of the first working session: the time log runs from 3 to 8 September 2026.

Their finance lead ran every step in his own tenant from a written runbook, so the person who would own it understood how sign-in, permissions and the audit trail fit together. It has been live with a small pilot group since September. How much time it saves hasn't been measured yet.

One thing we got wrong first: the first working version answered through a single shared login. That's fine for a demo and wrong for a certified shop, because nobody could say who had asked what. The rebuild put a real identity behind every question, and the shared login was deleted the day it went live. The full write-up is on Results.

When it isn't the right thing to build

If the answers your team keeps asking for aren't in any system yet, a connector has nothing to read. That's worth finding out before anything is built, and it's one of the things the first call is for.