MCP and apparel ERP: what changes when AI reads your live operational data.

What MCP actually is

The Model Context Protocol is an open standard for connecting an AI model to an external system through defined tools. Rather than a person exporting data, pasting it into a chat window and hoping the model reads it correctly, the model calls a function - query sales orders for this date range - and receives structured data back from the live system, under that user’s existing permissions.

That sounds like plumbing, and it is. But the plumbing is the point. Almost every disappointing encounter a merchandiser has had with AI on business data traces back to the same root cause: the model was working from a snapshot that was already stale, stripped of structure, and detached from the system that could verify it. Change the connection and a large class of those failures disappears.

The distinction worth holding onto is between AI that has been told about your business and AI that can read it. The first is a research assistant with a good memory of a spreadsheet. The second is closer to an analyst with a database login.

Why apparel data defeats generic AI

Apparel punishes systems that think in flat SKUs, and it punishes AI layered on top of them in exactly the same way. A model asked which styles need reordering will return a confident, well-formatted, arithmetically correct answer that is commercially wrong - because the thing that mattered was never in the data it read.

Three structures cause most of it. The first is the style-colour-size matrix: 400 units on hand means nothing without knowing that 380 of them are XS and XXL. The second is the difference between on-hand and available-to-sell, where the same physical unit may be committed against a wholesale pre-book, sitting in an inbound purchase order, or genuinely free - and only one of those is sellable today. The third is the seasonal calendar, where comparing this June to last June is only meaningful if the model knows both belong to the same phase of two different ranges.

None of that is an AI problem. It is a data-model problem that AI makes visible. An ERP that stores a size run as a matrix, prepacks as first-class objects and availability as a forward calculation gives a model something worth reading. One that flattens all of it into rows gives the model a very fast way to be wrong.

What changes when the model reads the live record

The honest answer is that it does not create capabilities nobody had. A good analyst with SQL access could always produce these answers. What changes is the cost and the latency of asking - and when the cost of asking a question falls far enough, people ask questions they previously did not bother with.

In practice the questions that get asked look like this. Sell-through against buy, by style, colourway and size, mid-season rather than in the post-mortem - which is when it is still actionable. Year-on-year by rep, brand or category, with gainers, decliners and lost accounts surfaced rather than hunted for. Over-buy detection, where core solids bought at two times last season are quietly under-performing while a novelty print sells out in three weeks. Coverage flags, where a handful of SKUs are under two weeks of cover and a reorder needs drafting now, not at the next review.

The second category is document work, which is less interesting and probably worth more money. Wholesale orders arrive as PDFs, spreadsheets, email bodies and scans; bills of lading, packing lists and QA reports arrive in equally inconsistent formats. Parsing these into structured records without rekeying removes a genuine and expensive category of manual work, and it is the use case most likely to pay for itself in the first quarter.

What this does not do is remove the need for someone who understands why the numbers moved. It removes the three days of preparing the numbers so that person can start.

What the output actually looks like

Abstract claims about AI are cheap, so it is worth being concrete about what comes back. The examples below are drawn from reports generated against a demonstration apparel dataset - an apparel brand with wholesale and D2C channels - using exactly the query tools described above.

Dead and aging stock. On-hand inventory compared against trailing 90-day and 12-month sell-through, mid-peak-season, filtered to styles still active in the system rather than discontinued. The top ten alone accounted for $443K of tied-up capital across 19,134 units, six of them with zero sales in twelve months, and four T-shirt styles carrying more than ten years of supply at current velocity - one at roughly twenty-one years. None of that is a hard question. It is a question nobody had time to ask, phrased as a report nobody had time to build.

Broken size runs. Styles where core sizes have sold out while tail sizes still sit in stock, ranked by sell-through against units sold. This is the analysis that is structurally impossible on flat-SKU data - the style shows healthy units on hand, and every one of them is an XS or a 3XL. Reading a genuine size matrix, the same catalogue returns a ranked list of styles that look fine on the stock report and cannot actually be sold.

Account health. Wholesale accounts flagged from sales-order, cancellation and credit-note activity together, with D2C excluded so the signal is not diluted. The pattern that surfaced was not declining revenue - that one is easy - but accounts where cancelled value exceeded net invoiced sales. That is a relationship in trouble, and it is invisible in a sales report because the cancellations live in a different table.

Open WIP and purchase-order coverage. Every open production job and PO against the full horizon of open demand, flagging overdue POs and styles where stock plus inbound no longer covers commitments.

That last one is where auditability earns its keep. Open demand is easy to understate - exclude a purchase-order status that carries large retail EDI commitments, or double-count lines already allocated from stock, and the coverage picture is wrong in a way that looks entirely plausible. Any analyst can pick the wrong filter; the difference is whether anyone can tell. When the query behind a number is visible, a wrong filter is a fifteen-minute fix. When it isn’t, the number simply circulates.

The same discipline applies to false positives. A week-over-week deceleration rule will flag most of a wholesale catalogue as collapsing, because wholesale ships in large batches - one big shipment week followed by a quiet one produces a dramatic drop on a perfectly healthy style. A report that says so at the top, and points to a four-week trend as the reliable signal instead, is more useful than one that presents sixteen alarms with equal confidence.

Three kinds of “AI” in an ERP - and why the distinction matters

Vendor marketing collapses three different things into one word, and the differences determine what you actually get.

Automation applies rules and pattern-matching to repetitive work: parsing documents, routing exceptions, suggesting allocations. It is the most mature, the most reliable, and usually the fastest payback. Most “AI features” in ERP today are this.

Analysis reads the live record and answers questions about it. This is where MCP-style connections matter, and where the value depends entirely on the quality of the underlying data model.

Prediction - demand forecasting, delay risk, trend response - is a different problem with a different reliability profile. It can be genuinely valuable and it is also where the most optimistic claims cluster. Treat automation and analysis as things to verify in a demo, and prediction as something to verify against your own history before you rely on it.

A vendor who can tell you clearly which of the three each of their features is, and which are live in production versus on a roadmap, is telling you something useful about how they build.

What it does not do

It does not fix bad data. A model reading a costing field that was set wrong two seasons ago will report the wrong figure fluently and without hesitation. Connecting AI to an ERP raises the value of clean data and raises the cost of dirty data at the same time.

It does not replace judgement. Knowing that a category is down 18% is not the same as knowing that a key account changed buyers in March. The system can surface the first far faster than a human can; the second still lives with people.

It should not act unsupervised by default. Reading data and writing to it are different permissions and should be treated as such. Drafting a reorder is not the same as placing one.

It does not make a non-apparel system apparel-native. If the ERP underneath cannot express a size curve, no amount of intelligence on top will recover the information that was never stored.

Permissions, keys and auditability

Three governance questions decide whether this is deployable in a real business.

Whose account, whose data? The cleanest architecture is one where the brand connects its own AI account to its own ERP, the data stays within systems already under contract, and no separate AI vendor relationship or third-party data store is introduced. Ask explicitly where queries and results are stored, and for how long.

Whose permissions? An AI layer that reads with full database rights is a data-leak surface with a friendly interface. Queries should be scoped to the permissions of the person asking, so a sales user cannot retrieve margin data they could not open in the ERP itself.

Can you check the work? Every number should trace back to the specific query that produced it. This matters less for the impressive demo and enormously for the Tuesday morning when a figure looks wrong and somebody has to determine whether the model erred or the data did. If outputs are not auditable, you have bought a confident black box.

How to evaluate a vendor’s claim

• Run it on your data, not a demo tenant. Prepared datasets are prepared. Bring a real season with its real mess.
• Ask an ambiguous question deliberately. A well-built system asks what you meant; a poorly-built one picks an interpretation and presents it as fact.
• Ask where a number came from. If the answer is not a specific query against specific records, you cannot audit it.
• Ask what is live versus roadmap - and which named customers are running the live capability in production today.
• Ask what happens when it is wrong. Can you see the query, correct the source, and re-run?
• Check the data model first. Ask the system a question that only makes sense in apparel - a broken size curve, availability against a pre-book - and see whether the structure supports an answer.

The last one is the tell. AI capability is increasingly commoditised; every vendor will have some. What is not commoditised is whether the system underneath stores your business in a shape worth reading.

Frequently asked questions