A note on what this is. This example is reconstructed from shipped SKULayer workflows. The store, its details and the figures are illustrative unless a cited evidence note says otherwise. The tools, previews and safeguards described are the real product behaviour.
Picture an outdoor retailer with a few thousand items serving Google Shopping. The operator connects their AI assistant to SKULayer over MCP, asks “what’s wrong with this feed?”, reads the answer, and types two words: fix it.
What follows is how that exchange plays out with the shipped tools, and then the part we care about most: an honest annotation of every decision the assistant makes, including the ones it declines to make.
What does the assistant see?
The audit, first. SKULayer’s MCP server gives it the same findings a human sees on the audit page. In this example: a set of titles over Google’s 150-character limit, a group of items with no brand, GTIN, or MPN, and a few items missing images outright, which in a picture format means disapproval.
Then the human says fix it, and the assistant reports back:
Two changes were proposed: disable the title rule, and fill missing brands only where the catalogue provided a reliable match.
The “add Free Delivery to title” rule was sat there enabled but hadn’t fired yet. The next run would have pushed titles even further over the 150-character limit for zero benefit (Google doesn’t need “Free Delivery” baked into the title, that’s what shipping settings are for). Disabled, not deleted, so it’s recoverable if you know why it was there.
The brand rule fills brand from the title when it’s blank, matched against your actual brand list rather than guessing off the first word, which would have mislabelled generic items.
Two things a rule can’t fix, need your call:
The over-long titles are naturally verbose, full spec-dump titles. Blind truncation would chop mid-sentence. These want shortening at source, front-loading brand and product type.
A few items have a genuinely empty image field. Not something a feed rule can invent. Check whether the image just isn’t mapped for that supplier or the source is actually missing it.
The audit also surfaced a couple of descriptions over the 5,000-character limit. Wasn’t in your original ask, flagging since it showed up.
What does it actually change?
Two things, and both survive scrutiny.
The rule it disables is the better story. That “add Free Delivery to title” rule was real, enabled, and sitting at the top of the stack, left over from an earlier session and forgotten. The assistant has no way of knowing why. It reads the rule, works out the effect, connects it to the title-length findings it has just seen, and proposes switching it off with its reasoning attached. It chooses disable over delete, on the explicit logic that someone might know why the rule existed. That is the judgment call you would want from a careful colleague.
The rule it adds is guarded the way a careful human would guard it. Fill brand from title, but only when brand is empty, and only from the list of brands the catalogue actually carries, matched as whole words. The lazy version of this fix copies the first word of the title into the brand field and mislabels every generic accessory in the catalogue. The assistant says no to that approach, out loud, before anyone asks.
Net effect on the audit: the identifier gap shrinks, the finding count drops, and the feed Google fetches only changes once the new version has passed every check.
What stops it shipping something reckless?
Not good intentions. Design.
A rule an assistant creates goes through exactly the same gate as a rule typed into the app. It comes back as an impact report against your real items: how many match, which fields change, what gets excluded, and a warning in bright letters if it would empty a required field or drop a chunk of the catalogue. A rule that carries a danger-level warning lands disabled, so nothing destructive can reach the feed without a person seeing the warning first. You see the report in the conversation, and the decision sits with you.
And because every change lands as an ordinary rule you can read, the cost of a wrong call is one click. Rules switch off. Every version is restorable. Your live feed only changes when a new version passes every check.
We wrote about the design in our MCP docs: reads work with any token, writes need a write-scoped token, and nothing changes a feed silently, whoever, or whatever, asked.
What does it refuse to pretend?
This is the part that makes the example worth writing up.
The assistant does not truncate the verbose titles. It explains why blind truncation would be the wrong fix: chopping a title mid-sentence loses the keywords that matter instead of front-loading them. The right fix is at source, and it hands that decision back to the human.
It does not invent images for the items whose image field is genuinely empty, because no feed tool can. It says where to look instead.
And it flags a finding nobody asked about, descriptions over the 5,000-character limit, rather than quietly staying inside the brief.
An assistant that reports what it cannot do is worth ten that claim they can do everything. The same is true of feed tools.
What does this mean if you run feeds?
That the “AI will manage your product data” conversation stopped being hypothetical, at least for the boring, valuable middle of the work: reading the audit, drafting the fix, showing the impact, running the feed, and reporting honestly on the leftovers. A person stays in the loop for every write, and the whole exchange takes minutes on a phone-sized screen.
If you want to try it on your own catalogue, the path is short: connect the feed you already have, run the first audit, then connect Claude or any MCP client. A read-only connection is enough to ask what’s wrong. Grant write access when you have seen enough previews to trust the gate.
A catalogue worked this way ends the session with fewer problems than it started with, an audit trail of every change, and the source-data decisions correctly routed to a human. That is what fixed means.