Yes, with two conditions. The ERP has to expose its actions as MCP tools over a public HTTPS endpoint, and the connection has to be made as a specific person, so that every tool Claude calls is checked against that person's permissions. Under those conditions Claude discovers the tools, chooses the ones a request needs, calls them in sequence, and reads the results back to decide what to do next. It can create an invoice, send it, record a payment, move a deal or book a task, and the record in the ERP is exactly what it would have been had a person done it.
The qualifications are real. Claude does not operate a system that only has screens; it needs tools. It operates within the authority of the person it signed in as, and no further. And the four Claude surfaces (the web and desktop app, Claude Code, Cowork and the Messages API) connect to MCP servers in slightly different ways with different controls, so which one you use changes what you get.
What operate has to mean
It is easy to get a weak yes to this question. Paste a CSV export into a chat and Claude will answer questions about your debtors. That is analysis, not operation. Operating a system means the model can find out what actions exist, call them with the right inputs, read what came back, and carry on until the outcome is reached, all without a person relaying anything between the two windows.
The mechanism that makes that possible is the Model Context Protocol. An MCP server publishes a list of tools, each with a name, a description and a JSON Schema for its inputs. A client such as Claude fetches that list with tools/list, hands it to the model, and when the model decides to act, sends tools/call with the tool name and arguments. The result comes back as content the model reads, with an isError flag when something went wrong so the model can correct itself and try again. The protocol is JSON-RPC over HTTP; the current specification revision is 2026-07-28 and the transport for remote servers is Streamable HTTP.
So the precise form of the question is: does your ERP publish its actions as MCP tools, and does the connection carry your identity? If the answer to both is yes, Claude can operate it. If the vendor offers only an assistant inside its own product, the answer is no, whatever the marketing says, because Claude cannot reach the actions from outside.
Which Claude can do it today
Anthropic ships several ways to reach an MCP server, and they are not interchangeable. The table is what each one supports as documented in September 2026.
| Surface | How you connect | Sign-in | Controls you get |
|---|---|---|---|
| Claude web and desktop app | Customize, then Connectors, then Add custom connector; paste the server URL | OAuth handled by Claude; it probes the URL and pre-fills what it detects | Per-tool permission including Blocked; Always allow for trusted servers; connectors toggled per conversation |
| Claude Code | claude mcp add --transport http <name> <url>, then /mcp to sign in | OAuth in the browser from the terminal; local, project or user scope | Approval prompts per tool; organisation controls of ask or blocked per tool; connectors added on claude.ai appear automatically |
| Messages API (MCP connector, beta) | mcp_servers entry plus an mcp_toolset in tools | You obtain the OAuth token yourself and pass it as authorization_token | Allowlist or denylist tools per request; only tool calls are supported, not resources or prompts; not covered by zero data retention |
| Team and Enterprise | An owner adds the connector under Organization settings; members then connect | Each member signs in on their own | Owners choose which connectors exist; members' calls run as themselves |
Custom connectors are available on Free, Pro, Max, Team and Enterprise plans (Free is limited to one). In every case the server must be reachable from Anthropic's cloud, so a system on a private network needs allowlisting; nothing runs from your laptop.
Two details matter more than the rest. Claude's own research features can call connector tools without asking, so Anthropic's guidance is to turn off write tools on a connector while using research. And on the Messages API the OAuth flow is your problem: the API takes a token you already hold, which is fine for a service you run and awkward for an end user.
The worked example
Here is one request, run through Claude connected to a Sois workspace as a finance user. The workspace is an MCP server at a single URL; the connection was made once through Add custom connector and an OAuth sign-in, and the tools Claude sees are the ones this user's role allows.
- Finding Acme Ltd and its key contacts
- Checking this workspace's VAT rates
- Draft invoice created from one line, twelve days at the day rate
- Sent to Sarah Cole with the PDF attached
- Payment chasing paused until 18 September
Five tool calls in sequence: searchContacts, listTaxTypes, createInvoice, sendInvoice and snoozeInvoiceChase. Claude chose the sequence; the workspace enforced who was allowed to make each call.
What Claude actually did is worth tracing, because it is the whole answer to the question. It first called searchContacts to resolve the customer to a record and pick up Sarah Cole as a key contact, because the invoice tool wants a contact identifier, not a name. It then called listTaxTypes, because the invoice tool's description says the tax rate must be set on each line and that the workspace's exact rates come from that call; a model reads descriptions, and a good description prevents an invoice going out with no VAT. It created the invoice with one line, quantity twelve, at the rate held on the customer's terms, and received the new invoice's identifier and number in the result. It passed that identifier to sendInvoice, which attaches the PDF and emails it, and finally to snoozeInvoiceChase with a date, so the bulk reminder tool skips this invoice until then.
No screen was opened. The person wrote one sentence and then read the log. The invoice, the sent email and the snooze are ordinary records in the workspace, indistinguishable from ones a person created by hand.
What Claude was allowed to do, and what would have stopped it
The reassuring part of the example is not that it worked; it is where it would have failed. The connection was made by a finance user. The list of tools returned to Claude was filtered by that role before Claude ever saw it, so an HR tool the user cannot use was never in the list. Every call was then checked again at execution, because a filtered list is a convenience, not a security boundary. If the same request had been made by a user without the right to create invoices, createInvoice would have returned a permission error rather than a draft, Claude would have reported that, and nothing would have been written. Access fails closed.
Every call from Claude passes through the permission layer before it reaches a module. Claude is offered the tools its user may use, and each call is checked again when it runs.
- Identity. The OAuth sign-in binds the connection to a person. Each tool call is attributed to that person in the log, not to a generic integration account.
- Scope. The MCP authorisation specification lets a server vary
tools/listby the credentials on the request, which is exactly how role filtering is implemented. - Budget. When the workspace's own agent does reasoning, spend is capped per integration. When Claude does the reasoning, as here, the workspace performs no AI on the user's behalf and charges nothing for it.
- Client-side controls. On top of the server's checks, Claude lets you block individual tools on a connector and decide per tool whether to approve each call.
Where it stops
A model with a good tool surface still needs judgement supplied from somewhere. The example ran cleanly because the request was unambiguous and the data was in order. Give it a customer with two similar records and a well-designed server will make Claude choose or ask rather than guess; Sois's contact search returns ranked matches and flags same-name duplicates for that reason. Approvals above the user's authority stop the run, and should. Long-running work that outlives a chat, such as a month-end sweep across two hundred invoices, is better handed to a scheduled task inside the workspace than driven turn by turn from a conversation.
Setting it up
For the web or desktop app, open Customize, then Connectors, choose Add custom connector, paste the workspace's MCP URL (for Sois that is the workspace address followed by /api/mcp), and complete the sign-in Claude opens. For Claude Code, run claude mcp add --transport http sois https://your-workspace.sois.ai/api/mcp, then /mcp to authenticate in the browser. Either way there is no token to paste and nothing to install on the server side, because the workspace already speaks the protocol.
Then give it one job that is routine and reviewable, read the log, and widen the scope as you trust it. A first request like the invoice above tells you within a minute whether the system you have is one Claude can operate, or one it can only talk about.
Questions people ask
Does Claude need a plugin or an app from the ERP vendor?
No. If the ERP exposes an MCP server, Claude connects to it directly as a custom connector or from Claude Code. Vendor directories exist for convenience, but a plain server URL is enough.
Can Claude delete or change records in the ERP?
It can do whatever the person it signed in as can do, and no more, provided the server checks permissions on every call. You can additionally block specific tools on the Claude side, and Claude asks for approval on tool calls unless you have chosen Always allow.
Does the ERP charge for Claude's reasoning?
On Sois, no. When your own agent does the reasoning the workspace performs no AI on your behalf and charges nothing for it; you pay your usual Claude subscription or API usage. Credits are only consumed when the workspace's own agent does the thinking.
Can I use the Messages API to build my own Claude ERP integration?
Yes, through the MCP connector beta: add the server under mcp_servers and an mcp_toolset under tools, and pass an OAuth access token you have obtained yourself. Only tool calls are supported on that path, and the server must be reachable over public HTTPS.
- Claude documentation: third party connectors with remote MCP how custom connectors are added, the sign-in options and the per-tool controls
- Claude Code documentation: MCP servers the claude mcp add command, scopes and OAuth via /mcp
- Claude API documentation: MCP connector the Messages API path, its beta header and its limits
- Sois documentation: the workspace MCP server the endpoint, the OAuth flow, role filtering and the tool reference used in the example
This article is reviewed when the products it describes change. Next scheduled review: 4 December 2026.