MCPs for Amazon software: Are they worth it?

Everyone’s shipping MCP servers right now. Helium 10, Jungle Scout, SellerSprite, AMZScout, MerchantSpring.

The pitch is clean: pull your data into one AI chat instead of logging into seven dashboards. Same data, no tabs.

We built six ourselves at Threecolts.

Then we tested them against real seller catalogs, and the results changed how we think about AI for Amazon software entirely.

What an MCP server actually is

Quick context for anyone who hasn’t been drowning in this acronym: Model Context Protocol (MCP) is an open standard, originally introduced by Anthropic in late 2024, that gives an AI model a standardized way to connect to outside tools and data sources instead of needing a custom integration built for every single combination. 

That’s exactly why it caught on. By late 2025, Anthropic had donated it to the Linux Foundation, and pretty much every major AI platform, Claude, ChatGPT, Gemini, Copilot, had native support for it.

For an Amazon seller tool, shipping an MCP server means an AI assistant like ChatGPT or Claude can read your data directly instead of you exporting a spreadsheet and pasting it into a chat window. That’s the whole pitch above, and it’s a genuinely good one for a narrow slice of work. 

It’s the rest of the job where things fall apart. Here are my observations:

1. Every MCP demo is a read.

Pull my BSR. Show me competitor pricing. Summarize last week’s ad spend.

Nice. But that’s not where your hours go.

Your hours go into pushing 5,000 products to 6 marketplaces, each with its own category tree and required attributes. Syncing price and inventory across all of them before Prime Day. Fixing 12,000 suppressed ASINs. Working through thousands of orders and reviews to catch the handful that actually need you.

Bulk action is the job. Therefore, that’s the test.

You can see the same pattern across every Threecolts product. 

A wholesale seller running Tactical Arbitrage against a supplier manifest isn’t asking “Is this product profitable?” They’re running that check against a few thousand line items at once, then deciding which hundred to actually buy. 

A seller on SmartRepricer isn’t asking “What’s my price on this ASIN?” They’re auditing which strategy won or lost the Buy Box across a thousand listings and adjusting the ones that are bleeding margin. 

A seller using InventoryLab isn’t asking “What’s in this batch?” They’re building the batch: products, quantities, costs, prep owner, boxing, and labels, all before a single box gets shipped. 

And a brand running UniCon across Amazon, Walmart, and TikTok Shop isn’t asking, “What does my catalog look like on Walmart?” They’re mapping thousands of attributes from one marketplace’s schema to another’s, then keeping inventory and orders synced as both catalogs keep changing underneath them.

None of that is a read. All of it is bulk action, and bulk action is exactly what an MCP demo never shows you.

2. The context math doesn’t survive a real catalog.

In MCP, every row flows through the model’s context window.

One product record with the fields you need to work on it—title, bullets, attributes, identifiers, price, inventory—runs about 200 tokens.

10,000 products in = 2M tokens

The same rows back out with your changes = another 2M

More tokens = more budget burnt, and that’s one run of one task.

That’s one operation. And 10,000 isn’t a big catalog. Plenty of our customers run past 100,000.

But the token bill is the least interesting problem.

To publish 10,000 records, the model has to write out 10,000 records. It can map the wrong attribute to the wrong channel, or quietly skip 300 of them. No errors. Nothing flags it. You find out when a channel suppresses the listings a week later.

And if it dies halfway through, did 7,000 publish or none? There’s no way to test it first, no preview of what’s about to change, and no undo. You’re round-tripping 10,000 listings through a token generator to change a category ID.

Scale that math to a real ICP and it gets worse fast. A brand expanding from Amazon into Walmart and TikTok Shop with UniCon isn’t reconciling 10,000 rows once. They’re reconciling a live catalog against every marketplace’s category tree, every time a supplier updates a spec sheet or a channel changes a required field. 

A private label seller running InventoryLab across a few hundred SKUs and multiple prep centers is generating shipment plans, cost allocations, and labels continuously, not once a quarter. None of that fits inside a chat window without the token bill (and the error rate) climbing right alongside it.

3. It hallucinates more, not less.

We assumed real data would ground the model. The more servers we connected, the worse it got.

7 servers means dozens of overlapping tools. Therefore, it picks the wrong ones.

Truncation reads as completeness. It gets page 1 of 40 and reports a total like it saw everything.

Margin across 400 rows gets predicted, not calculated. It’s usually close. But close is the worst failure mode, because it passes the sniff test and lands in a decision.

That’s what happens when you make a probabilistic system your integration layer, your query engine, and your calculator at the same time.

We saw this firsthand connecting our own tools together. 

Ask a model wired up to FeedbackWhiz and SmartRepricer through separate MCP connections which ASINs lost the Buy Box last week and also picked up a negative review, and it has to correctly route that single question across three tools with three different schemas and no shared idea of what “last week” or “ASIN” even means between them. 

It’ll usually give you an answer. It’s the confidence of that answer that should worry you, not the absence of one.

What actually wins? A tightly coupled harness.

MCP’s whole virtue is that it’s loosely coupled. Any model, any tool, a generic schema, no shared context required. That’s exactly what makes it a good standard.

But loosely coupled means nothing is shared. No common identity graph. No agreed definition of margin or cost or period. No shared guardrails. Every turn re-derives it from scratch, so every turn is a fresh chance to get it wrong.

E-commerce needs the opposite. The model, the tools, the skills, and the knowledge base are all built against the same domain model.

Tightly coupled means the model directs the work instead of performing it. It never touches your rows. It gets a schema and a handle, then writes the operation that runs against them in code, where arithmetic is executed instead of predicted, and failures throw errors instead of plausible wrong numbers.

Your 3,000-row product attribute sheet works the same way. It lands as data, not as tokens.

There’s no version of “attach this 40MB file and reconcile it against 60,000 live listings” that works as a chat tool call.

Tight coupling costs more per integration. You give up plugging in anything you want. But when a wrong price runs live on Amazon for six hours, that’s a trade we’ll take every time.

So, is it worth setting one up?

MCP is fine. It’ll be everywhere. But it’s a connection standard, not an architecture.

And if every tool ships one within 6 months, MCP is table stakes. Table stakes are never a moat.

Shipping an MCP server is what you do when you want a model to read your data.

Building a harness is what you do when you want it to run your business.

That’s the bet we’re making with AI Operator.

AI Operator isn’t just another MCP server bolted onto Seller 365. Instead of one generic connection point that has to guess its way through every tool’s schema, AI Operator runs specific roles inside each product. 

• A matching agent checks a sourcing lead against the live Amazon listing and drops it if it’s a pack-size or look-alike mismatch, before you spend a dollar on it. 
• A pricer moves your min and max in SmartRepricer the moment you tell it to, inside the rules you already set. 
• A stock manager reads your reports and builds an entire InventoryLab batch, products, quantities, costs, prep owner, boxing, and labels, without you leaving the chat. 
• A watcher monitors the listings and reviews you choose in FeedbackWhiz and flags problems before they cost you. 

Each of those roles is built against its own tool’s actual data structure, with the guardrails already in place, instead of reasoning its way through a generic schema from a cold start every single time.

If you’re already using Tactical Arbitrage, InventoryLab, SmartRepricer, and FeedbackWhiz across your Amazon business, that’s exactly the stack AI Operator runs inside instead of around.

And if you’re not there yet, AI Operator is one more reason to get on Seller 365 today instead of waiting on an MCP roadmap to catch up.