DEV Community

Cover image for your supplier just raised prices. now what?
lofder.issac
lofder.issac

Posted on • Originally published at github.com

your supplier just raised prices. now what?

#ai #mcp #dropshipping #shopify

Last Tuesday one of my AliExpress suppliers bumped the price on an LED therapy mask from $18 to $26. Overnight. No warning. The product was already live on two Shopify stores with a $32 sell price — margin went from comfortable to barely breaking even.

If you run a dropshipping operation, this isn't news. Suppliers raise prices, go out of stock, or vanish. The standard fix is manual: open DSers, find the product, search for alternatives, compare SKU variants one by one, update the mapping. For 40+ products across multiple stores, that's a full afternoon gone. Every month.

So I built an MCP tool that does it automatically — supplier search, product scoring, variant matching, mapping update. Here's what went into it.

TL;DR — dsers_replace_mapping is a new MCP tool (v1.5.0 of @lofder/dsers-mcp-product) that takes a live DSers product, searches AliExpress for cheaper suppliers, scores candidates across 5 dimensions, matches SKU variants with a three-tier algorithm (exact → context → fuzzy), and optionally writes the new mapping. Auto-apply only fires when every variant match exceeds strict confidence thresholds. Works with Claude, Cursor, Windsurf, or any MCP-compatible AI agent.

Why automated supplier replacement is hard

Finding a cheaper supplier is the easy part. AliExpress has thousands of sellers for any given product. The hard part is making sure it's actually the same product with compatible SKU variants.

Take that LED mask. My current listing has two variants: "EU PLUG (220-240V)" and "US PLUG (100-110V)". A replacement supplier might list the same options as "European Standard" and "American Standard". Or "220V" and "110V". Or they might bundle the plug type with a "Ships From" option, creating a 2×3 variant matrix where I had 2×1.

If you get this wrong, a customer orders the EU plug version and receives a UK plug. Chargeback, bad review, account risk.

This is a supply chain matching problem, and it's messier than it looks.

How the product scoring pipeline works

I ended up building a multi-stage pipeline. First, normalize everything — strip the marketing noise from titles ("[2026 Trending] HOT SALE" becomes "led therapy mask with neck"), parse structured specs out of option values (extracting plug=eu plug and voltage=220v from "EU PLUG (220-240V)"), and ignore shipping axes entirely since "Ships From: China" tells you nothing about the product itself.

Then score candidates across five signals:

  • Structured spec overlap (35% weight) — quantity, capacity, plug type, voltage. These are the hard constraints. If the candidate has "UK Plug" and you need "EU Plug", it's a blocker regardless of everything else.
  • Option value coverage (25%) — what percentage of your current variant option pairs exist in the candidate.
  • Title token similarity (20%) — Jaccard similarity on cleaned title tokens.
  • Image similarity (10%) — basename comparison on product image URLs. Crude, but surprisingly effective on AliExpress where the same factory photo gets reused.
  • Market signals (10%) — stock availability, rating, order volume. A supplier with zero stock or 2-star rating isn't useful even if the product matches perfectly.

The whole scoring function is about 30 lines:

const productScore = roundScore(
  titleSimilarityScore * 0.2 +
    structuredSpecScore * 0.35 +
    optionCoverageScore * 0.25 +
    imageSimilarityScore * 0.1 +
    marketSignalScore * 0.1,
);
Enter fullscreen mode Exit fullscreen mode

Three-tier SKU variant matching

Product-level scoring gets you a ranked list of candidates. But you still need to map each variant from your current supplier to the new one. This is where most automation attempts fall apart.

I went with three tiers:

  1. Exact signature match — both sides normalize to plug=eu plug → instant 1:1 mapping, confidence = 1.0.
  2. Context match — use the ignored axes (like shipping origin) as tie-breakers when two variants share the same product signature but differ on logistics.
  3. Fuzzy match — for everything else, score option pairs (45%), context option pairs (25%), title tokens (15%), image similarity (10%), and price neighborhood (5%). Only accept matches above 0.6, and require a meaningful gap between the best and second-best match to avoid ambiguous pairings.

Auto-apply only triggers when every single variant maps with high confidence. One ambiguous match and the whole thing drops to "analysis only" — the tool shows you what it found, but won't touch your live mapping without human confirmation.

Running it as an MCP tool with AI agents

This whole pipeline became the 13th tool in my open-source MCP server for DSers dropshipping. The tool is called dsers_replace_mapping. You give it a product ID and store ID, it pulls the current mapping, searches for alternatives, scores them, matches variants, and returns a structured report.

An AI agent can use it like this:

Check product dp-8291 in store st-102.
If the supplier price went up more than 20%,
find a cheaper alternative and update the mapping.
Enter fullscreen mode Exit fullscreen mode

The agent calls dsers_my_products to get the current price, calls dsers_replace_mapping with auto_apply=false first to see the analysis, evaluates whether the top candidate is acceptable, and only then calls it again with auto_apply=true if everything checks out.

The response includes confidence scores, blocked reasons, variant match details, and a full mapping preview — enough for the agent (or a human) to make an informed decision.

Normalizing DSers API responses

Building the scoring was the fun part. The painful part was normalizing the wild variety of API response shapes from DSers.

The same product detail can arrive with variants under variants, skuList, variantList, or productSkuList. Prices might be in cents or dollars — sometimes in the same response. Option values sometimes live in optionsSnapshot, sometimes in options, sometimes both with different structures. I wrote a pickBestProductNode function that recursively scores every nested object in the API response and picks the one that looks most like a product.

Not elegant. But it works on every response shape I've thrown at it so far.

Scoring thresholds and test coverage

The feature adds about 1,500 lines of logic across three modules, plus 950 lines of tests covering normalization, scoring, variant matching, and the full flow with mocked API calls. Build passes, 312 tests green.

For the scoring thresholds: auto-apply requires product_score >= 0.88 at the product level, plus score >= 0.93 and score_gap >= 0.1 at the variant level. These numbers came from testing against ~30 real product pairs. They're conservative on purpose — false positives on supplier replacement cost real money.

This ships as v1.5.0 of @lofder/dsers-mcp-product. It's the first MCP server I know of that does automated supply chain supplier replacement with variant-level matching. If you're running a dropshipping operation and tired of the supplier treadmill, the tool might save you some afternoons.

If you've tried automating supplier matching in your own stack — what signals did you end up relying on? I'm especially curious whether anyone's gotten CLIP-based image matching to work reliably for e-commerce product comparison.

Top comments (0)