Finance asks for one small thing. Let them ask Claude what the aged payables look like, without waiting on a report. The ledger lives in Microsoft Dynamics 365 Business Central, and the request is reasonable. The worry runs the other way. An assistant that can read a ledger can usually post to it, and a posted journal entry is not something anyone undoes in a chat window.
Before you set up Dynamics 365 MCP access for Claude, three things get decided. They are: who authorizes the account, which tools the finance role may reach, and how you prove afterward that nothing was written. The first takes ten minutes. The second two are the playbook.
How do you set up Dynamics 365 MCP access for Claude?
You add Elaichi to Claude once, as a custom connector, and Business Central reaches Claude through Elaichi. Claude talks to Elaichi over MCP. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. The address is https://api.elaichi.ai/mcp, the same string for every organization. Which organization and which person a client reaches comes from the OAuth grant behind its token, not from the URL. A grant is the standing permission one AI client holds for one person in one organization.
On Claude Team and Enterprise plans, an Owner or Primary Owner adds a custom connector from Organization settings > Connectors. The path is Add, then hover over Custom, then Web (Anthropic's custom connector help article, checked October 2026). Each member then finds it under Customize > Connectors and clicks Connect to authenticate. On Pro and Max, each person adds it themselves.
Claude reaches the server from Anthropic's cloud rather than from the laptop. Anthropic's own authentication page puts that outbound traffic in the range 160.79.104.0/21, and says Claude sends a PKCE S256 code challenge on every authorization request (Claude connector authentication, checked October 2026). That is fine here, because Elaichi's endpoint is public.
Local MCP servers are a different mechanism, configured per device. On macOS, Claude Desktop reads them from ~/Library/Application Support/Claude/claude_desktop_config.json (the MCP project's local server guide, checked October 2026). One hosted endpoint avoids that file sitting on every finance laptop.
The click-by-click version lives in the Claude setup walkthrough. This post picks up after sign-in works.
Is Microsoft Dynamics 365 Business Central in Elaichi's catalog?
Check the connector catalog for your organization before you plan anything else. Elaichi's catalog holds 650+ connectors, in two kinds. Most are connectors Elaichi authors and runs itself. The rest are native MCP connectors, where the vendor builds and runs its own MCP server and Elaichi handles sign-in, access and audit in front of it. Each catalog connector gets its own page, with its category, tool count and tools; a neighboring cloud ERP, Acumatica, shows the shape.
If Microsoft Dynamics 365 Business Central is not listed, an organization can add it as its own connector. That needs the connector:create permission, which among the built-in roles only Org Owner and Org Admin hold. It also needs the custom-connector feature that the Gold plan includes. There are two shapes. One is a connector built from a JSON config, validated against Elaichi's config schema. The other is a remote MCP server: one that speaks MCP over Streamable HTTP and is reachable over public HTTPS. No IP literals, no internal hostnames. An organization can hold up to 25 of its own remote MCP connectors, and each one is private until somebody shares it.
Either way the rules that follow are identical. Restrictions, OAuth scopes and the audit log govern a custom connector exactly as they govern a catalog one. Running a vendor's own server behind Elaichi goes further into that path.
Whose Business Central account does Claude act as?
Every call through a connection uses the account that connection was made with, whoever is calling. A connection shared with the finance team therefore reaches Business Central as its owner, with that person's permissions in the app. Nothing about the caller's identity changes which credential is used.
That is a choice, not an accident. One shared connection gives the whole team one fixed permission set in Business Central, which is simple to reason about and simple to audit. Per-person connections keep each person's own app permissions instead. For the per-person shape, build a template and share it at use. Each member then stamps their own toolbox and picks their own connection for each app. A toolbox is a named list of tools, each pinned to one connected account.
For a ledger, the shared connection usually wins, on one condition: it belongs to someone who is staying. When the person who pinned a connection into a toolbox entry leaves, that entry stops resolving for everyone until someone re-pins it.
Two restrictions that stop a posted journal entry
A restriction says which connectors and tools a role or a member may reach. In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. A finance team is therefore governed through the role its members hold.
One: an allow rule naming the read tools. Write it on the finance role, naming the Business Central tools that list and get. Watch the blast radius. Once a role carries any allow rule, everything none of its allow rules names is blocked for that role. That holds across the whole catalog, not only the connector you were thinking about. So the same role needs whole-connector allow rules for every other app it uses. An allow rule that names nothing blocks everything for its target; its own summary reads "Allows nothing. Every connector and tool is blocked."
Two: a block rule naming the tools that post, void or delete. Within a layer, all blocks merge into one blocklist, and a block always beats an allow. This matters because of how the two rule types match. Allow rules match the operation Elaichi pinned when the rule was saved, never the label. Block rules match by name or by operation, so renaming a tool cannot slip it past a block. A block on a connector also covers every fork that declares descent from it. Why blocks and allows match differently is worth five minutes before you write either one.
One thing a restriction will not do: it cannot be replaced by a consent checkbox. No scope on Elaichi's consent screen holds a client to reading a connected app. "Run your connected tools" covers the app's writes and deletes as well as its reads. "Delete data and remove access" is about Elaichi's own data, not Business Central's. Read-only comes from restrictions, or from picking toolboxes made only of read tools at consent.
Role, team and restriction changes reach every surface within about two minutes. Revoking a share or disconnecting an account takes effect on the caller's next call, and so does removing or suspending a member.
Freeze the company so an answer cannot come from the wrong ledger
If the connector's tools take an argument that names the company, environment or ledger, lock it on the toolbox entry. Frozen parameters are argument values written into an entry that a caller cannot override. At execution they are merged over the caller's arguments, so passing the key anyway changes nothing. Elaichi also removes the frozen keys from the input schema the client is shown.
Two honest limits. The model can still see what is frozen, and often the value. Elaichi prefixes the tool description with a note such as (frozen: company=Acme-UK), and a client that reads the toolbox gets every frozen value in full. It cannot change them. And a freeze holds only on calls that run through the entry carrying it. Anyone who can use the connection themselves has the same tool unfrozen in their All tools toolbox. To make the freeze the only path, keep the connection unshared, pin it into the toolbox entry, and share the toolbox at use instead. Locking a tool argument covers the pattern in more detail.
Every frozen key must name a real argument of the tool, or the write is refused with a message listing the valid ones. That is also a useful check that you understood the tool.
The audit query that proves the restrictions hold
Every connected-tool call that reaches execution writes one audit row, whether it came from Claude, from another MCP client or from Elaichi's own surfaces. The row records the acting person, the toolbox, and the tool's advertised and catalog names. It also records the connector, the connection the call actually reached, the tool's classification, how approval was given, the surface, the MCP client's id and the outcome.
To prove the finance role read and never wrote:
- Open the organization's audit log. With
audit:view, held by Org Owner, Org Admin and Auditor, you see every event. Everyone else sees their own events plus events on connections they own or can edit. - Filter by category Assistant. Connected-tool calls sit there because their action is
assistant.toolbox_tool. The MCP category holds grant events, not tool calls, which is the trap most people hit first. - Set the actor to the member and the range to Last 7 days.
- Search the connector name. Free text matches each word anywhere in the action, resource type, resource id, acting user id and the row's metadata.
- Open a row. The summary opens with where the call ran, for example "Using Claude, ...". A "What it did" line reads Read data, Changed data or Deleted data. The Approval line for a call from an MCP client reads "Allowed by the access Claude was granted".
The evidence is that every row for that connector reads Read data. Export the view as CSV with the filters applied; an export beyond 10,000 entries stops rather than saving a partial file.
One caveat to state in the ticket, not hide. A call a restriction withheld writes no row at all, because the refusal happens before any executor runs. The log proves what ran, not what was attempted. Elaichi keeps 90 days of audit history; for longer, export to your own Datadog comes with the Black plan, which is launching soon. What an AI audit log has to capture sets out the fields worth checking in any tool, not just this one.
What Claude's own per-tool controls can and cannot do here
Claude connector tool permissions take one of three settings: Always allow, Needs approval or Blocked. Each applies to a whole connector, a category of its tools or a single tool (Anthropic's connectors article, checked October 2026). That is genuinely useful, and it is not where Business Central gets governed.
The reason is in Elaichi's tool list. In Elaichi, connected tools are never listed one by one, however few there are. A client finds them with search_tools and runs them through execute_tool, plus run_code where Code Mode is on. So a per-tool setting in any client sees one execute_tool carrying every connected app, and cannot tell Business Central from Slack. Per-app and per-tool control belongs in Elaichi, as restrictions.
Over MCP, Elaichi asks nobody per call: the grant a person approved on Elaichi's consent screen is the approval. Any per-call prompt a user sees is the client's own. The layers of human approval sets out which layer does what.
Connecting from the Anthropic API rather than the Claude app
The endpoint is the same for an agent you build as for the desktop app. Elaichi keeps no list of approved MCP clients. Anything that supports OAuth dynamic client registration, PKCE with S256 and a browser sign-in can connect, and every client goes through the same registration, sign-in and consent. Registration happens at POST https://api.elaichi.ai/oauth/register and needs no Elaichi credential.
The constraint to design around is unattended use. Elaichi's MCP sign-in supports only the authorization-code grant with PKCE, plus refresh. There is no device-code and no client-credentials grant, so a new grant always needs a person approving a consent screen in a browser. A refresh token lasts 30 days and each refresh issues a new one, so a long-running agent must keep refreshing or connect again. Test any client you have not used before, because what differs between them is only where their settings take the URL.
When one person reading one ledger does not need any of this
If exactly one controller wants to read Business Central from Claude, and nothing else, a governed endpoint is more machinery than the problem deserves. Connect the app however your Microsoft administrators prefer, keep the account read-only on their side, and revisit this when the second person asks.
The case for one address and one rule set starts later. It starts when the finance role touches a second and third app, when someone asks which of those calls changed anything, or when a leaver's access has to end in one action instead of five. When you do not need an MCP gateway yet draws that line more carefully.
For the wider model behind roles, restrictions and grants, start with MCP governance. For a neighboring ledger with the same read-only shape, see Xero in Claude without letting it edit invoices. For the choice between blocking one tool or a whole app, read six cases for per-tool versus per-app restrictions. The governance use case is laid out at /use-cases/governance/.
