NetSuite Has an MCP
Most People Are Going to Use It Wrong.
NetSuite has built an MCP, a Model Context Protocol, which lets you connect Claude directly to your NetSuite instance. Claude can query your data, pull reports, surface discrepancies, and answer questions without anyone having to export a spreadsheet or raise a ticket.
That sounds brilliant. And in the right hands, for the right tasks, it is.
The problem is most businesses won’t use it in the right hands, for the right tasks. They’ll do what businesses always do with a shiny new capability: hand it to everyone and call it a transformation.
So before that happens, it’s worth understanding exactly how this goes wrong, because the failure mode isn’t subtle, and it’s one most finance and ops teams have already lived through once before.
You’ve already solved this problem. Don’t un-solve it.
Before proper ERP systems, most businesses ran on spreadsheets. Not one spreadsheet, dozens of them. The warehouse had their version of stock levels. Finance had theirs. The trading team had another. Nobody’s numbers matched, nobody agreed on whose version was right, and half the working week went on reconciling data that should never have diverged in the first place.
The whole point of an ERP, NetSuite included, was to fix that. One system, one version of the truth, everyone working from the same data.
The MCP, used badly, is a direct step backwards.
If everyone in your business starts pulling reports through a prompt, each prompt becomes its own spreadsheet. Different filters, different assumptions, different outputs. The FD is looking at one number, the ops director is looking at another, and neither of them knows why they don’t match. You’ve rebuilt the exact problem NetSuite was supposed to solve. You’ve just replaced Excel with a chat interface.
If you’re still running your business from actual spreadsheets and considering NetSuite, understand that this is the problem you’re trying to solve. Adding an AI layer on top of fragmented data doesn’t fix fragmented data. It just makes the fragmentation faster.
What the MCP is actually good for
None of this means the MCP isn’t useful. It is, in specific, bounded situations.
The sweet spot is one-off queries. A question you need answered today that you don’t have a saved search for. A quick check on something specific. Surfacing an anomaly you weren’t expecting. The kind of thing where you’d otherwise wait two days for a developer to build a report you’ll only ever need once.
That’s the job. It’s a fast-lookup tool, not a reporting strategy.
The moment it becomes your default way of getting data out of NetSuite, you’ve got a problem.
The script-writing use case is the underrated one
Less talked about, more genuinely valuable: using Claude to help write SuiteScripts, Restlets, and other NetSuite scripts.
This is useful whether you’re a developer who wants to move faster, or a functional person who understands what they need but can’t build it themselves. The iteration loop is quicker, and you can get to a working draft faster than going through a traditional development cycle.
The rules here are non-negotiable though. Keep scripts narrow, one script, one specific thing. Updating a field from a CSV. Syncing a value between two records. Don’t try to build something complex and push it straight out. Always build and test in sandbox first, because NetSuite has no undo for deleted records, and AI-written code is not production-ready by default. It needs reviewing by someone who knows what they’re looking at before it goes anywhere near live data.
The data question nobody’s answering properly
There’s a concern sitting underneath all of this that isn’t being addressed well by anyone in the NetSuite ecosystem right now.
When you use the MCP, your data leaves NetSuite and goes into Claude. What happens to it at that point? Who’s responsible for it? How is it handled?
A NetSuite rep was recently asked at SuiteConnect exactly this in front of a room of potential users. The answer wasn’t good enough. “Once it’s out of NetSuite we have zero control or responsibility of that data” (paraphrased).
That lack of clarity is making brands nervous, and it should, particularly for businesses in competitive categories where their operational data is genuinely valuable. In reality, that’s a question for another article or one to ask our OX Community.
The subtler risk is less obvious but worth thinking about: AI models learn from context. If you’re a consultant working across multiple brands in the same space, there’s a real question about whether the AI keeps client data properly separated, or whether patterns from one client’s operation start bleeding into thinking about another’s. Not maliciously. Not obviously. But the risk is there.
This isn’t a reason to avoid the MCP. It’s a reason to be deliberate about what you use it for and what data it touches.
The thing most people miss about AI and ERPs
There’s a distinction that gets lost in almost every conversation about AI in business systems, and it matters here.
There’s a difference between using AI to build automation and making AI the automation. The first is smart. You use Claude to write a script, test it, refine it, and then deploy something that runs reliably without needing AI involved every time. The second is expensive, inconsistent, and fragile, because you’re paying for a prompt every single time the process runs, and you’re dependent on the AI producing the same answer each time it does.
The goal should always be to use as little AI as possible in the final running solution. Use it heavily in the build. Use it lightly, or not at all, in the operation.
The MCP is a build tool and a one-off tool. The moment you start treating it as infrastructure, you’ve misunderstood what it’s for.
So what should you actually do?
Use the MCP for ad hoc queries where speed matters and repeatability doesn’t. Use Claude to help write and iterate on scripts. Keep anything that needs to be consistent, scheduled, or shared sitting on a proper process, saved searches, dashboards, reports that everyone pulls from the same place.
And if you’re still on spreadsheets: an AI that can query your data faster isn’t the answer to your data problem. Getting the data into one place first is.
The ERP exists to give everyone the same version of the truth. Don’t let a well-marketed AI feature talk you into giving everyone their own version again.