Compliance runs on structured data: a material code per component, a weight in grams, a recycled content figure that is either a number or explicitly unknown. The data you receive is rarely in that shape. It arrives as a PDF specification sheet, a photograph of a label, a reply to an email that answers two of the five questions asked, or a spreadsheet laid out the way the supplier's own system exports it.

Someone has to read that material and key it into the system. For a range of a few hundred SKUs that is tedious. For several thousand, with a backlog of historic specifications and a reporting deadline every six months, it is the bottleneck that decides whether the data is ready on time.

The Model Context Protocol (MCP) changes how that step can work. This post explains what MCP is, why it is a better fit for compliance data than pasting documents into a chatbot, and where its limits are.

What MCP is

MCP is an open standard for connecting AI assistants to other systems. A system that supports it publishes a set of tools - look up a SKU, list its components, propose a component record, attach a document - each with a defined set of fields and types. An assistant connected to that system can call those tools, and only those tools, on behalf of the person using it.

The important part is the division of labour. The assistant does what language models are good at: reading a messy document, working out that "45g PET btl w/ PP cap + BOPP label" describes three components, and matching each to the right fields. The system does what it has always done: decide what a valid record looks like, check what is submitted against it, and record who submitted it and when.

Why not just paste the document into a chatbot?

Many teams already do something like this. They paste a specification into a general-purpose assistant, ask for a table, and copy the table into the system. It saves some reading time, but it keeps every problem the manual process had and adds a new one.

The output is still text that has to be rekeyed. The assistant does not know your material taxonomy, so it writes "aluminium" where your system needs a specific material code, and someone has to translate it. Nothing it produces has been validated until it is typed in, and there is no record linking the value in the system to the document it came from.

Template-based extraction tools have the opposite problem. They are precise for a known layout and break the moment a supplier changes theirs, which across a supplier base of any size is constantly.

With MCP the assistant works on the system's side of the boundary. It looks up the valid material codes rather than guessing them, it submits records through the same validation a person filling in a form would hit, and when a value fails it is told why and can correct it or flag it. What reaches the database is a structured record, not a transcript.

What it looks like in practice

A typical intake, starting from a supplier specification PDF for a new product, runs like this:

  • The user gives the assistant the document and names the SKU it relates to
  • The assistant looks up the SKU and any components already held against it, so it updates rather than duplicates
  • It reads the specification, separates it into components and maps each material to a value from the system's own taxonomy, asking the user where the document is ambiguous - a foil lid that may be a laminate, a board that may be coated
  • It shows the user what it intends to write. For a batch of rows, it runs the import as a dry run first: the system validates every row, reports what would be created, updated or rejected, and saves nothing
  • Fields the document does not answer should be left empty, not filled with a plausible guess. Recycled content that is not stated stays unknown, not zero - worth saying explicitly when you brief the assistant
  • Once the user is happy, the records are written, and the specification itself is uploaded and linked to each component as its evidence

The advantages

The obvious gain is time. Reading and keying a multi-component specification takes minutes per SKU by hand. Reviewing a proposed record that has already passed validation takes a fraction of that, and the saving compounds across a backlog of thousands. The less obvious gains matter as much for compliance:

  • One set of rules. Data entered through an assistant passes the same checks as data entered through a form, a supplier portal or a bulk upload. There is no second, looser route into the database
  • Suppliers keep their own formats. You do not need every supplier to adopt your template before their data becomes usable. A supplier that sends a PDF is no longer a supplier whose data waits in an inbox
  • Unknown can stay unknown. The record holds an empty value as distinct from zero, so the null-versus-zero distinction for recycled content survives intake as long as nothing is invented to fill the gap. A blank value in an import leaves what is already held rather than overwriting it
  • Mistakes are refused, not absorbed. A field name the system does not recognise is rejected with a reason rather than silently dropped, so a misnamed field cannot quietly lose a value
  • Provenance. The source document is held against the component it describes, and every tool call is written to the audit trail with the user it acted for. When a regulator or auditor asks where a weight came from, the answer is a document, not a recollection
  • Permissions can only narrow. The assistant acts for the signed-in user and can never do more than their role allows. Access is granted by scope, so an assistant can be given read-only access, or write access to components but nothing else
  • No lock-in to one assistant. MCP is an open standard, so the same connection works with whichever MCP-capable assistant your team already uses

What it does not do

A language model can misread a document. It can confuse a gross weight with a net weight, or take a figure from the wrong row of a table. That is why the design matters more than the model: validation catches values that are impossible, a dry run or preview lets a person see what will change before anything is saved, and the link to the source document makes checking a value quick.

It does not replace a supplier declaration. A value extracted from a specification sheet is your reading of the supplier's document. A supplier declaration is the supplier's own statement, made against a reference and a date. Where a declaration is required, an assistant can draft the request and fill in what is already known, but the supplier still makes it.

It should not decide regulated outcomes. Sorting labels and material codes are derived from component attributes by rules that can be shown to an auditor, and a recyclability grade is assessed against the relevant standard and recorded with its basis. The assistant's job is to get the attributes right. The rules then do what they always did.

Where it pays off first

The best starting point is usually the backlog: the folder of historic specification sheets that were never entered at component level because nobody had the time. It is a bounded job, the documents already exist, and the output is immediately useful for the next submission.

After that, new product launches and supplier changes, where a new specification arrives and needs to be in the system before the next reporting period. And the long tail of suppliers who will not use a portal, whose data otherwise arrives late or not at all.

How Merchant Packaging supports this

Merchant Packaging has an MCP server built on the same API as the application. Every write tool runs the same validation and the same business rules as the matching screen or API call, so there is no route in for an assistant that a person filling in a form would not also have. An assistant connected to it can look up products and components, read the taxonomy, create and update records, run imports as a dry run before committing them, and upload specifications and certificates as evidence linked to the components they describe.

Access is granted per person, through scoped tokens. Write access is only given when asked for, and only to someone whose role already allows it, and that role is checked again on every call. Each call is recorded in the audit trail, including calls that were refused, because what an assistant tried to do is as much part of the record as what it did. Suppliers can use it too, limited to their own components.

When a component change touches a product with a signed Declaration of Conformity, that declaration is re-checked, exactly as it would be after an edit made on screen. Sorting labels and PPWR material codes are derived from the component data by the same rules as everything else in the system, and red, amber or green ratings are applied when reports run.