Forem: lofder.issac

your supplier just raised prices. now what?

lofder.issac — Thu, 09 Apr 2026 19:45:48 +0000

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,
);

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:

Exact signature match — both sides normalize to plug=eu plug → instant 1:1 mapping, confidence = 1.0.
Context match — use the ignored axes (like shipping origin) as tie-breakers when two variants share the same product signature but differ on logistics.
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.

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.

pull requests aren't dying. your review process is.

lofder.issac — Thu, 09 Apr 2026 14:09:47 +0000

There's a take going around that pull requests are dying. Cognition, OpenAI, half of AI Twitter — everyone seems to agree that PRs can't survive the age of coding agents.

I've been reading the research they're citing. The data is real. The conclusion isn't.

The bottleneck is real

Faros AI analyzed 1,255 engineering teams and 10,000+ developers. The numbers are hard to argue with: teams using AI coding tools merged 98% more PRs, but code review time went up 91%. PR size increased 154%. Bug rate went up 9%.

So yes — if your team adopted Copilot or Cursor or Codex and suddenly every engineer is producing twice the output, your reviewers are drowning. That part is true.

But "reviewers are drowning" and "PRs are dying" are very different statements.

What's actually broken

The problem isn't the pull request as a concept. It's that most teams never built their review process to handle variable throughput.

Think about it. Before AI tools, your team probably had an unspoken rhythm — maybe 2-3 PRs per developer per day, each one a few hundred lines. Reviewers could keep up because the input rate was roughly constant. Nobody designed it that way, it just settled into a natural pace.

AI broke that pace. Now one developer can produce 5-8 PRs in a day, some of them 500+ lines. The review process didn't change, so it buckled.

But that's a process problem, not a format problem. You don't throw away email because you got too many of them. You build filters, labels, priorities. Same applies here.

Three things the "PR is dead" crowd gets wrong

1. They assume every team has this problem.

Faros studied high-AI-adoption teams — the ones pushing the hardest on agent-driven development. Most engineering teams in 2026 are not there yet. They're using autocomplete and chat, not autonomous coding agents producing hundreds of lines unsupervised. For them, PRs work fine. The bottleneck doesn't exist.

The "PR is dead" narrative takes a frontier problem and projects it onto the entire industry.

2. They ignore compliance.

In fintech, healthcare, defense, and any industry with SOC 2 / ISO 27001 / HIPAA requirements, human code review isn't optional. It's a regulatory checkbox. You can make it faster, you can augment it with AI, but you can't eliminate it. An AI agent approving another AI agent's code doesn't satisfy an auditor.

Nobody in the "kill the PR" camp mentions this. Probably because most of them work at AI startups where compliance means adding a checkbox to the settings page.

3. They understate the cost of alternatives.

Devin is $500/month per seat. Running a Managed Agent is $0.08/hr plus token costs. OpenAI's Symphony requires Elixir infrastructure and a team that understands agent orchestration. Specification-driven development with BDD requires rewriting your entire planning process.

These aren't free upgrades. For a 5-person startup or a 20-person agency, "just adopt Devin Review and Symphony" is not a realistic answer to "my PRs take too long to review."

What actually works

I've been running an open-source MCP server that handles dropshipping automation — product sourcing, imports, supplier replacement, pushing to Shopify. It generates structured, deterministic output from well-defined tool calls. When my AI agent calls dsers_replace_mapping, the result is a JSON payload with confidence scores, variant matches, and blocking reasons. A reviewer can scan that in 30 seconds.

Compare that to a coding agent that rewrites 400 lines of business logic. The review burden is completely different.

The pattern I keep seeing in teams that don't have a review bottleneck:

Smaller PRs. Not because of policy — because the tools produce focused, scoped changes. MCP tools, well-structured agent tasks, single-responsibility operations. If your agent is producing 500-line PRs, your task decomposition is the problem, not your review process.
Machine-checkable constraints. Architecture rules in linters, type systems, CI checks that catch structural issues before a human ever sees the diff. Can Boluk showed that just changing the editing format improved 15 LLMs by 5-14 percentage points. The right harness reduces review load more than any review tool.
Human review for intent, not syntax. The OpenAI Harness Engineering experiment got this right — engineers review the plan, the spec, the acceptance criteria. The code is validated by machines. But this doesn't mean PRs go away. It means the PR contains a spec + test results + a diff, and the human reviews the first two.

The actual future

PRs will evolve. They'll carry richer metadata — agent confidence scores, test coverage deltas, architectural impact summaries. The diff will become one section of a larger review artifact, not the whole thing.

Some teams will move to trunk-based development with post-merge verification. Some will adopt tiered review where low-risk changes get auto-merged with monitoring. Some will keep traditional PR review because their domain requires it.

What won't happen is a universal replacement. The "after the pull request" framing assumes there's a single successor. There isn't. There's a spectrum of review strategies, and teams will pick based on their risk tolerance, compliance requirements, and team size.

The Kevlin Henney quote keeps getting thrown around — "describing a program in unambiguous detail is programming." It's true, and it's exactly why specification-driven development won't replace code review either. Writing a perfect spec is as hard as writing perfect code. We'll need review at every level of abstraction, just with different tools.

If your review process is drowning, fix your review process. Break PRs into smaller pieces. Add machine checks. Move intent review upstream. But don't throw away the mechanism — it's one of the few things in software engineering that actually works at scale across every team size and industry.

PRs survived waterfall, survived agile, survived microservices. They'll survive AI agents too. They just need better tooling around them, not a funeral.

What's your team's experience — are you actually hitting the review bottleneck, or is this still a theoretical problem for you?

Anthropic just mass-produced the agent. who's building the hands?

lofder.issac — Thu, 09 Apr 2026 13:30:34 +0000

Yesterday Anthropic shipped Claude Managed Agents. If you haven't seen it yet — they're now hosting the full agent runtime for you. Session persistence, sandboxed execution, error recovery, tool orchestration. You define what the agent should do, they handle everything underneath.

It's a big deal. But I think most people are looking at the wrong part.

Everyone's talking about the brain. Nobody's talking about the hands.

Managed Agents gives you a brain that can reason, plan, and recover from failures across long-running sessions. It gives you bash, file I/O, web search. The infrastructure layer is genuinely impressive — $0.08/hr per agent, auto-recovery on disconnect, built-in prompt caching.

But here's what it can't do out of the box: anything domain-specific.

It can't check if your AliExpress supplier went offline. It can't search for a replacement. It can't compare SKU variant mappings between two suppliers who call the same color "Navy Blue" and "深蓝色" respectively. It can't push a product to your Shopify store.

The brain is there. The hands are missing.

That's where MCP servers come in. Managed Agents natively supports MCP — you declare your servers in the agent config, and the agent discovers and calls your tools like it would call bash or web search. No extra plumbing.

What I actually plugged in

I've been building an open-source MCP server for dropshipping automation — it connects to DSers and handles everything from product sourcing to store push. Last week I added a supplier replacement tool that searches for alternatives, scores candidates, matches SKU variants, and optionally swaps the mapping. The kind of supply chain operation that used to take a seller 2-3 hours of manual work per product.

Connecting it to Managed Agents took about 12 lines:

from claude_agent_sdk import query, ClaudeAgentOptions

async for message in query(
    prompt=(
        "Check product dp-8291 in store st-102. "
        "If the current supplier's price increased more than 20%, "
        "find a cheaper alternative and update the mapping."
    ),
    options=ClaudeAgentOptions(
        mcp_servers={
            "dsers": {
                "command": "npx",
                "args": ["-y", "@lofder/dsers-mcp-product"],
            }
        }
    ),
):
    print(message)

That's it. The agent picks up the MCP tools, figures out the right call sequence — fetch current mapping, search suppliers, score candidates, match variants, apply if confidence is high enough — and runs it autonomously. If the session disconnects, Managed Agents picks up where it left off.

Why this matters for supply chain automation

Dropshipping supply chains break constantly. Suppliers vanish, prices spike overnight, stock runs dry on your best-selling variants. Traditionally you find out when a customer complains. Or if you're diligent, you check manually every few days.

With a Managed Agent running 24/7, you can set up something like: "every 6 hours, scan my top 50 products, flag any supplier that's down or 15%+ more expensive, and auto-replace if a high-confidence alternative exists." The agent handles the scheduling loop, the MCP server handles the domain logic. You pay $0.08/hr for the runtime and whatever tokens the model consumes.

Honestly, the token cost is the part I'm still watching. My supplier replacement tool does a lot of API calls — search, detail fetch, scoring, variant matching — and each of those round-trips adds context. For a single product check it's fine. For 50 products on repeat, I haven't done the math yet. That's going to depend heavily on how well Managed Agents handles context compaction between iterations.

The interesting tradeoff nobody's mentioning

Managed Agents is opinionated about architecture. Anthropic hosts the brain, the sandbox, the session. You bring the tools. This is great if you want to move fast — you don't build an agent loop, you don't manage containers, you don't deal with state persistence.

But it also means your agent only runs on Claude. You can't swap the model. You can't self-host. You're renting the runtime from Anthropic and paying per-hour plus per-token.

For my use case that's acceptable — dropshipping sellers already pay for Shopify, DSers, ad platforms. Adding $0.08/hr for an agent that monitors their supply chain is cheap compared to losing a best-seller for 3 days because the supplier silently went 404.

But if you're building something where model portability matters, or where you need to run in your own VPC for compliance, Managed Agents isn't the answer. The MCP server still works everywhere else — Cursor, Claude Desktop, any MCP-compatible client. The Managed Agents integration is just one more deployment target.

What's still missing

A few things I ran into during setup:

No cron/schedule primitive. You can't tell a Managed Agent "run this every 6 hours." You'd need an external scheduler (Lambda, cron job, whatever) that creates sessions on a timer. Seems like an obvious addition they'll probably ship soon.
MCP auth in the sandbox. My MCP server uses OAuth — the user runs npx @lofder/dsers-mcp-product login once locally and the token persists. In the Managed Agents sandbox, you'd need to inject the token via environment variables or mount a credentials file. Workable, but not as smooth as the local experience.
Observability. I can see events in the Claude Console, but I want structured logs — "agent checked 50 products, replaced 3 suppliers, skipped 2 due to low confidence." Right now I'd have to parse that from the event stream myself.

None of these are blockers. They're the kind of rough edges you expect from a beta that launched literally yesterday.

The bigger picture

MCP servers have been around for a while, but they've mostly lived in developer tools — Cursor, Claude Desktop, VS Code. Managed Agents changes the distribution model. Now an MCP server isn't just a dev tool plugin. It's a building block for autonomous business processes.

A supply chain monitoring agent. An inventory rebalancing agent. A competitive pricing agent. These are all just "a brain + the right MCP tools + a schedule." Managed Agents handles the first part. The tools are what make it useful.

If you're building MCP servers, I think this is worth paying attention to. The surface area for your tools just got a lot bigger.

The MCP server is open source: github.com/lofder/dsers-mcp-product. The supplier replacement tool (dsers_replace_mapping) ships in the next release. If you're running dropshipping on DSers, it works today with Cursor and Claude Desktop, and now with Managed Agents too.

Curious if anyone else has tried plugging production MCP servers into Managed Agents — what was your experience? I'm especially interested in how token costs scale for long-running sessions.

I Killed My OpenClaw — Built the Memory, the Gateway, the Patches. Then the Token Bill Arrived.

lofder.issac — Wed, 08 Apr 2026 16:18:57 +0000

What I Actually Built

Between March and April 2026, I shipped 3 projects around the OpenClaw ecosystem. Not forks. Original work.

1. Engram — Scope-Aware Memory for Multi-Agent AI

Repo: lofder/Engram

The problem with OpenClaw's memory was simple: it's file-driven. You write a SOUL.md, you manually curate skills as markdown files, and the AI loads everything into context every single time. More memories = more tokens = more money. And nothing gets cleaned up automatically.

I built Engram as the fix. It's a full memory architecture powered by Mem0 + Qdrant + MCP:

Scoped memory — global, group:project-x, dm, agent:coder. Different memory pools for different contexts. Your coding preferences don't pollute your email agent's memory.
7 memory types — preference, fact, procedure, lesson, decision, task_log, knowledge. Not just "remember this" — structured categories that the retrieval system can filter on.
Self-cleaning — duplicates merge automatically. Old task logs get summarized into compact knowledge. Stale entries fade. The AI manages its own memory instead of you maintaining files.
Forgetting logic — this is the part nobody else does. Remembering is easy. Knowing what to forget is the hard problem. Engram tracks memory age, access frequency, and relevance decay. A task log from 3 weeks ago that was never recalled again? It gets compressed into a one-line summary, then eventually dropped. A preference you stated on day 1 that gets recalled every session? It stays forever. The AI doesn't just accumulate — it curates. Without this, every memory system eventually drowns in its own context, and you're back to paying for 12K tokens of stale history on every request.
Trust scoring — high / medium / low. User-stated preferences are high trust. AI inferences are low trust. When memories conflict, trust breaks the tie.
5 MCP tools — mem0_add, mem0_recall, mem0_search, mem0_delete, mem0_compact. Any MCP-compatible client can call them.

The design philosophy:

OpenClaw:  You write rules.md → AI reads it → you update rules.md → repeat forever
Engram:    AI remembers on its own → compresses over time → you never maintain a file

When Hermes Agent launched with "self-improving procedural memory" as its headline feature, I had a moment. Because Engram already did this — and more. Hermes stores skills as markdown files and uses LLM summarization for compression. It remembers, but it doesn't forget. There's no decay, no lifecycle, no "this memory is 3 weeks old and was never useful — drop it." Engram has typed memory categories, vector-based semantic retrieval, trust scoring, scope isolation, forgetting logic, and automatic lifecycle management.

But Engram ran on OpenClaw. And OpenClaw ran on tokens. And tokens ran on money I didn't have.

2. Durable Gateway Runtime — Multi-Channel Architecture

Repo: lofder/durable-gateway-runtime

OpenClaw's gateway is its core — the long-running Node.js process that connects WhatsApp, Telegram, Slack, etc. to the AI. But the architecture docs were scattered, and the execution model had gaps when you tried to scale beyond a single instance.

I wrote a full architecture document for a multi-channel gateway and execution model:

Ingress normalization — how to standardize messages from different platforms into a unified format
Execution skeleton — the task queue, context assembly, and tool execution pipeline
State durability — how to persist conversation state across restarts without losing context
Channel routing — how to route different groups/users to isolated agent instances

This was meant to be the "how to actually run OpenClaw in production" guide. Not just npm start on your laptop — real multi-tenant, crash-recoverable deployment.

I never finished the implementation. The architecture docs are public. The code is experimental. The reason I stopped? Same as everything else: tokens.

3. Gateway Stability Patch — Production Hotfix Toolkit

Repo: lofder/openclaw-gateway-stability-patch

This one came from pain. I was running OpenClaw with multiple channels, and the gateway kept crashing. WebSocket handshake races. Connect-challenge timeout drift. Retryable pre-connect closes that weren't actually being retried.

So I built a proper overlay toolkit:

Rule-based patches — configurable handshake timeout, connect-challenge timeout, bounded retry for loopback failures
apply/check/rollback CLI — not "edit the file and hope." A proper workflow with backups, manifests, and integrity checks
Version-strict — refuses to patch if the runtime version doesn't match. No silent breakage
Idempotent — run apply twice, get the same result. No duplicate patches stacking up

Pure Python, zero dependencies, MIT licensed. It's the kind of boring infrastructure work that nobody stars on GitHub but everybody needs in production.

The Token Bill That Killed It All

Let me tell you how it feels to watch money evaporate.

You build something you're proud of. Engram is humming. The gateway is stable (thanks to your own patches). Three channels are connected. You go to bed thinking "this is finally working."

You wake up. Check the API dashboard.

$14.37 overnight. While you slept.

Your agent was alive. Heartbeating. Checking for tasks every 5 minutes — 288 API calls through the night. Each one loading the full conversation history + system prompt + all loaded skills + Engram memories into context. Even when there was literally nothing to do, each "nothing to do" cost tokens. Your AI was awake at 3am, spending your money to confirm that nobody had messaged it.

That was the moment I started doing math I didn't want to do.

Why OpenClaw Eats Tokens Like It's Starving

OpenClaw's architecture is fundamentally, structurally, by design token-hungry. It's not a bug. It's how it works.

Context loading — the silent killer. Every single request ships the FULL conversation history + system prompt + loaded skills + memory. Not a summary. Not the relevant parts. Everything. A 20-message conversation with 3 loaded skills hits 8K-12K tokens per request — just for context, before the AI thinks a single thought. And context tokens count on every request. So message #21 pays for all 20 previous messages again. And again. And again.

Heartbeat — paying to breathe. OpenClaw checks for scheduled tasks periodically. Each heartbeat is a full API call with full context loading. Even "nothing to do" costs tokens. At the default 5-minute interval:

288 heartbeats/day × 2K tokens (minimum context) = 576,000 tokens/day
                                                  = just to exist
                                                  = ~$1.73/day on Sonnet
                                                  = $52/month for NOTHING

That's $52/month before you even talk to it. Just for the privilege of having it sit there, awake.

Tool chains — compound interest, but bad. A simple task like "check my email and summarize" involves: read email (tool call + response tokens) → parse content (inference) → summarize (inference) → store to Engram (tool call) → compose response (inference). That's 4-5 inference rounds. Each round loads the growing context. One email check = ~15K tokens. Do that 3 times a day and you're burning 45K tokens on email alone.

Model pricing — the real knife.

Claude Opus:    $15/M input, $75/M output
Claude Sonnet:  $3/M input, $15/M output  
Claude Haiku:   $0.25/M input, $1.25/M output

OpenClaw defaults to the best model available. If you have Opus access, it uses Opus. For everything. Including heartbeats. Including "nothing to do." I watched $0.47 disappear on a single heartbeat that concluded "no pending tasks." Forty-seven cents to think about nothing.

My Actual Spend

Week 1:  Just exploring, light usage              $12
Week 2:  Added Engram + 3 channels, getting real   $47
Week 3:  Gateway stability testing, lots of restarts $38
Week 4:  Desperate optimization, model fallback     $29
──────────────────────────────────────────────────────
Total:   4 weeks                                   $126

$126. For a personal AI assistant. That crashed. Regularly. And needed me to SSH in and restart it.

Let me put that in perspective:

$126 = 8 months of Netflix
$126 = my phone bill for 3 months
$126 = ChatGPT Plus for 6 months (which just works, no crashing)

And this was the optimized version. I had already:

Switched heartbeat to 30-minute intervals
Set up model fallback (Haiku for simple, Sonnet for complex)
Pruned context aggressively
Disabled 2 of 5 skills to reduce context size

The unoptimized version? People report $200-1000+/month. There's a famous post on Zhihu: "25 sentences cost nearly $20." That's not rage-bait. That's Tuesday with OpenClaw on Opus.

The Moment

I was sitting at my desk. It was a Wednesday afternoon. I opened the Anthropic billing dashboard and saw the week-to-date: $31.40. For 4 days. My bank account had $847 in it.

I did the math. At this rate, OpenClaw would eat 15% of my remaining savings in a month. For a side project. That I was building for fun.

I opened the terminal. I typed:

/stop

Then:

docker stop openclaw && docker rm openclaw

Then I closed the tab and went for a walk.

That walk lasted about an hour. I came back and started thinking about what I could build that would cost $0 to run.

Hermes Agent: The Thing I Almost Built

Two weeks after I killed my OpenClaw, Hermes Agent dropped. And the tech community went wild.

"Self-improving AI agent!" "Procedural memory!" "Model-agnostic!" "The OpenClaw killer!"

I read the architecture docs. I looked at the feature list. And I felt... recognition.

Here's what Hermes Agent launched with, mapped to what I already had:

Hermes Agent (launched)	My stack (built earlier)
Procedural memory — auto-generates skills from experience	Engram — 7 memory types, trust scoring, auto-compression, scope isolation
Session history with FTS5 search	Engram — Qdrant vector search + Mem0 semantic retrieval
Model-agnostic runtime	Was already using model fallback in my OpenClaw config
CLI + TUI + messaging platforms	Durable gateway runtime — multi-channel architecture with ingress normalization
Pre-execution security scanner	Gateway stability patch — version-strict apply/check/rollback
Cron-based scheduled tasks	OpenClaw heartbeat (the thing that ate my tokens)

I'm not saying Hermes copied anything. They didn't. But the problems they're solving? I was already there. The difference: Hermes is backed by Nous Research with (presumably) a budget for running their own models. I was a solo developer paying retail API prices.

Where Hermes genuinely does better:

Python-native (easier to hack on for ML people)
The do-learn-improve loop is cleaner than my separate Engram + OpenClaw integration
Zero telemetry by default is a strong stance
Better documentation and community

Where my design was ahead:

Forgetting logic — this is the big one. Hermes remembers. It doesn't forget. Every memory system that only accumulates eventually collapses under its own weight — context bloat, token waste, contradictory old entries polluting new decisions. Engram tracks age, access frequency, and relevance decay. It knows when to compress, when to merge, and when to let go. Knowing what to forget is harder than knowing what to remember, and Hermes doesn't even try.
Engram's scoped memory (global / group / dm / agent) is more granular than Hermes' flat note system
Trust scoring on memories (high/medium/low) — Hermes doesn't distinguish between user-stated facts and AI inferences
The gateway stability patch addresses real production issues that Hermes hasn't faced yet (because it's still young)

The honest truth: architecture doesn't matter if you can't afford to run it.

The Pivot: From Token Burn to Zero-Cost MCP Tooling

That walk after docker rm openclaw changed how I think about building AI tools.

The question wasn't "what's the coolest thing I can build?" anymore. It was: "what can I build that doesn't need me to feed it money every month just to exist?"

The answer was MCP tools. Not agents. Not platforms. Tools.

The insight: I don't need to build the agent. Claude is an agent. Cursor is an agent. ChatGPT is an agent. Millions of people already pay for these. What they need is tools that plug in — domain-specific logic that runs locally, costs nothing, and returns results in milliseconds.

That's how DSers MCP Product happened — 12 tools and 4 prompts for dropshipping automation. And sku-matcher — a pure-algorithm SKU matching engine that runs in milliseconds with zero model dependency.

The irony is almost painful:

OpenClaw era:
  Built: memory system + gateway + patches
  Users: 0
  Cost:  $126/month
  Status: dead

MCP era:
  Built: dsers-mcp-product + sku-matcher
  Users: 25 stars, 3900+ npm downloads
  Cost:  $0/month
  Status: growing

My $0/month MCP tools, running inside Claude or Cursor as the host agent, deliver more practical value than my entire $126/month OpenClaw setup ever did. The host agent handles conversation, memory, and orchestration. My tools just do the domain-specific work. No token bill. No gateway crashes. No heartbeat burning money at 3am while I sleep.

The lesson: don't build the platform. Build the tool. Let someone else's platform run it. Let someone else pay the token bill.

What I'd Tell Past Me

The "self-hosted AI agent" dream is a tax on enthusiasm. Everyone who sets up OpenClaw feels like Tony Stark for the first 48 hours. Then the invoice arrives. Until local models reach cloud API quality for complex tasks, "self-hosted" just means "you pay retail token prices with no negotiating power." OpenClaw + Claude Opus is a $100+/month commitment for basic utility. That's a subscription you didn't sign up for, to a service that crashes.
Beautiful architecture is worthless if you can't keep the lights on. Engram's design is solid. I still believe scoped, typed, trust-scored memory is the right approach. But nobody cares about your memory architecture when you're explaining to your bank why there's a $47 charge from "Anthropic PBC" this week.
If you can't afford the runtime, the architecture doesn't ship. I still think about Engram's design. It's good work. But good work sitting in a stopped container is just a GitHub repo with a nice README.

The Projects Live On (Sort Of)

Everything is still public on GitHub:

Engram — the memory architecture. If someone wants to build on it, the design is there.
durable-gateway-runtime — the architecture docs. Good reading material if you're designing multi-channel AI systems.
openclaw-gateway-stability-patch — the stability toolkit. Still useful if you're running OpenClaw in production and hitting WebSocket issues.

And what came after:

dsers-mcp-product — dropshipping automation via MCP. 25 stars, 3900+ npm downloads, zero token cost. The thing that actually works.
sku-matcher — SKU variant matching engine. Pure algorithm, no model, millisecond response. Being integrated into DSers MCP as automated supplier replacement.

Honestly?

I miss it.

I miss having an AI that knew me across sessions. That remembered I prefer TypeScript over Python, that I hate verbose logging, that my deployment always goes to the staging branch first. Engram made the AI feel like a colleague who'd been working with me for months, not a stranger I had to re-brief every morning.

I miss the gateway routing — different channels for different contexts, the Telegram bot for quick notes, the Slack integration for work stuff. It felt like having a real assistant with a real presence, not just a text box I paste into.

I don't miss the crashes. I don't miss the $14 overnight surprise. I definitely don't miss the $0.47 heartbeat that thought about nothing.

But the thing is — I didn't kill OpenClaw because I wanted to. I killed it because I couldn't afford it. There's a difference. If someone handed me an API key with unlimited tokens tomorrow, I'd docker run openclaw before they finished the sentence. Engram is still the best memory architecture I've designed. The gateway runtime is still the most thoughtful multi-channel AI system I've documented. The stability patches still solve real problems.

I just can't pay $126/month for the privilege of running them.

So this article is partly a portfolio piece, partly a technical comparison, and partly me venting into the void. If you're thinking about building on OpenClaw, or Hermes, or any self-hosted AI agent — read the pricing page before you read the architecture docs. Calculate the monthly token cost before you write the first line of code. The "self-hosted AI agent" dream is real. The bill is also real.

And if you're from Nous Research reading this — Hermes is good. But add forgetting logic. Your users will thank you in 3 months when their memory stores aren't 50,000 entries of stale garbage.

I'll be here, building $0/month MCP tools, waiting for the day token prices drop enough that I can bring my OpenClaw back to life.

Related reading:

5 Ways to Match AliExpress Product Variants — LLM, Embedding, Vision, Rules, and Why I Chose None of Them Alone

lofder.issac — Wed, 08 Apr 2026 13:20:19 +0000

TL;DR — I compared 5 technical approaches for matching product variants across AliExpress suppliers: string rules, vector embeddings, LLM prompting, vision models (CNN/CLIP), and hybrid algorithmic. Each has clear trade-offs in accuracy, speed, cost, and tolerance for real-world naming chaos. I ended up building a hybrid algorithm — no model, no GPU, no API call — specifically designed to run inside MCP tool calls where latency and determinism matter. This article breaks down each approach with real AliExpress examples so you can choose what fits your stack.

The Problem: Supplier Replacement Is a Matching Problem

When a dropshipping supplier goes down — dead link, out of stock, price spike — you need to find a replacement and remap every SKU variant to the new supplier.

That sounds simple until you see what AliExpress variant data actually looks like:

Supplier A (current)         Supplier B (replacement)
───────────────────────      ─────────────────────────
Color: Navy Blue             颜色: Dark Blue
Size: XL                     尺码: XL
Ships From: China            (no Ships From option)
100*130cm                    1x1.3m
4PC-32x42cm                  4pcs 32*42
Warm White                   暖光
Color: 03                    Color: C

The "Color" field might contain phone models, material types, or bare numbers. Dimensions come in every format imaginable. Languages mix within a single listing. Quantities are embedded in size strings. This is normal on AliExpress.

The question is: which technology handles this chaos best, and at what cost?

I tested and compared 5 approaches. Here's what I found.

Approach 1: Rule-Based String Matching

How it works: Compare variant values using exact match, Levenshtein edit distance, Jaccard similarity, or TF-IDF cosine. Set a threshold — if similarity > 0.8, it's a match.

Tools: Python difflib, fuzzywuzzy, RapidFuzz, custom regex.

Strengths:

Extremely fast (~0.01ms per pair)
Zero infrastructure — runs anywhere, no dependencies
Predictable behavior, easy to debug

Weaknesses:

Fails on synonyms. "Navy Blue" vs "Dark Blue" → Levenshtein distance = 5, cosine similarity ≈ 0.3. Not a match by any threshold that doesn't also false-positive "Dark Red" and "Dark Green."
Fails on cross-language. "红色" vs "Red" → zero string overlap.
Fails on units. "100*130cm" vs "1x1.3m" → completely different strings, same dimensions.
Fails on composite values. "4PC-32x42cm" vs "4pcs 32*42" → edit distance says these are unrelated.

Verdict: Fine for exact or near-exact matches. Falls apart the moment suppliers use different naming conventions — which is almost always on AliExpress.

Scorecard
⚡ Speed: ~0.01ms/pair — blazing fast
💰 Cost: $0 — zero infrastructure
🎯 Accuracy: ██░░░░░░░░ 30-45%
🌐 Cross-language: ❌
📐 Unit conversion: ❌
🔮 Naming chaos: ❌

Approach 2: Vector Embeddings (Sentence-BERT, MiniLM)

How it works: Encode variant names into high-dimensional vectors using a pre-trained model. Compute cosine similarity between vectors. Semantically similar texts end up close in vector space.

Tools: sentence-transformers, multi-qa-MiniLM-L6-cos-v1, FAISS for fast retrieval, Milvus for production scale.

Strengths:

Handles synonyms well — "Navy Blue" and "Dark Blue" are close in embedding space
Handles some cross-language matching if using multilingual models (e.g., paraphrase-multilingual-MiniLM-L12-v2)
Scales well with vector databases for large catalogs

Weaknesses:

Struggles with units and dimensions. Embeddings encode semantic meaning, but 100*130cm and 1x1.3m are not semantically related in training data — they're formatted numbers, not natural language.
Opaque codes are random noise. "03" and "C" have no semantic content. Embeddings can't help.
Requires a model. MiniLM is small (~80MB), but you still need to load it, and inference isn't free — ~5ms per encoding on CPU, more for batches.
False positives on short strings. "S" (small) and "M" (medium) are very close in embedding space because they frequently co-occur, but they're different sizes.
Composite values are opaque. "4PC-32x42cm" embeds as a chunk — the model doesn't parse it into count=4, dimensions=32×42, unit=cm.

Verdict: Significantly better than string matching for natural language variant names. But AliExpress data is often structured (numbers, units, codes), not natural language — and that's where embeddings struggle.

Scorecard
⚡ Speed: ~5ms/pair — fast enough
💰 Cost: ~$0 self-hosted, 80-200MB model RAM
🎯 Accuracy: ████░░░░░░ 50-65%
🌐 Cross-language: ⚠️ with multilingual model
📐 Unit conversion: ❌
🔮 Naming chaos: ⚠️ synonyms yes, units/codes no

Approach 3: LLM Prompting (GPT-4o, Claude)

How it works: Send a prompt to an LLM with both variant lists and ask it to produce a mapping. The model uses its world knowledge to understand that "Navy Blue" = "Dark Blue", parse units, and handle cross-language text.

Tools: OpenAI API, Anthropic API, any LLM with function calling.

Example prompt:

Given these store variants and supplier variants,
produce a JSON mapping of best matches with confidence scores.
Store: ["Navy Blue / XL", "Warm White / 100*130cm"]
Supplier: ["Dark Blue / XL", "暖光 / 1x1.3m"]

Strengths:

Best accuracy for natural language. LLMs understand that "Warm White" = "暖光" = "3000K" across languages and domains.
Can handle novel cases. If a supplier uses unusual terminology, the LLM's world knowledge often covers it.
Can reason about composite values. A good LLM can parse "4PC-32x42cm" into count + dimensions.

Weaknesses:

Slow. A single API call for 40×40 variants takes 3-10 seconds. If you're evaluating 10 candidate suppliers, that's 30-100 seconds just for matching.
Expensive. Variant matching for one product replacement burns 2K-5K tokens. At GPT-4o pricing, that's ~$0.01-0.03 per product. For a catalog scan of 500 products, that's $5-15 per run.
Non-deterministic. Same input can produce different outputs across calls. Temperature=0 helps but doesn't eliminate variance. You can't reliably cache or pre-compute results.
Rate limits. Hitting OpenAI or Anthropic API limits when doing batch operations is a real operational concern.
Latency kills MCP tool calls. If sku matching runs inside an MCP tool (where an AI agent is already waiting for a response), adding another LLM call creates a nested latency chain. The agent's context window is burning tokens while waiting.

Verdict: Most accurate for one-off matching. But too slow, too expensive, and too non-deterministic for high-volume automated pipelines — especially inside MCP tool calls where the AI agent is already using an LLM for orchestration.

Scorecard
⚡ Speed: 3-10s/product — slow (API roundtrip)
💰 Cost: $0.01-0.03/product — adds up at scale
🎯 Accuracy: ███████░░░ 75-90%
🌐 Cross-language: ✅
📐 Unit conversion: ⚠️ can reason, but not reliable
🔮 Naming chaos: ✅ best at novel cases
⚠️ Deterministic: ❌ — different output each call

Approach 4: Vision Models (CNN / CLIP / VLM)

How it works: Compare product images instead of (or in addition to) text. Use a CNN (ResNet, MobileNet), CLIP, or a Vision-Language Model to extract image features and compute similarity.

Tools: CLIP (OpenAI), ResNet/MobileNet (TorchVision), Google Lens API, AliExpress reverse image search.

Strengths:

Solves the opaque code problem. When "Color: 1, 2, 3" maps to red, blue, green — only images tell you which is which.
Cross-supplier visual match. Same factory product sold by different suppliers usually shares identical or near-identical product photos.
Handles language-agnostic matching. Images don't have a language barrier.

Weaknesses:

Heavy inference. CLIP embeddings: ~50-100ms per image on GPU, ~500ms on CPU. For 40 variants with images × 10 candidates = 400 images to process.
GPU dependency. Running CNN/CLIP inference on CPU is 10× slower. Production use requires GPU infrastructure.
Image quality varies wildly. Supplier photos range from professional studio shots to blurry phone photos. White background vs lifestyle context vs composite images with text overlays.
Can't distinguish size/quantity. A photo of a placemat set looks the same whether it's 2-pack or 6-pack. Vision models can't read text in images reliably for unit differentiation.
Overkill for most matching. When "Navy Blue" and "Dark Blue" can be matched by a synonym table, launching a vision model is using a cannon to kill a fly.

Verdict: Essential for the specific case of opaque color codes (numbers or letters instead of color names). But too expensive and slow to be the primary matching method. Best used as a fallback layer.

Scorecard
⚡ Speed: 50-500ms/image — heavy inference
💰 Cost: ~$0 self-hosted, but GPU required
🎯 Accuracy: █████░░░░░ 60-80% (visual only)
🌐 Cross-language: ✅ images have no language
📐 Unit conversion: ❌ can't read quantities from photos
🔮 Naming chaos: ⚠️ images yes, units/quantities no

Approach 5: Hybrid Algorithmic (sku-matcher)

How it works: A purpose-built matching engine that combines multiple lightweight techniques in layers, designed specifically for AliExpress variant data patterns.

Tools: sku-matcher — open-source, single TypeScript file, ~1200 lines.

Three matching layers:

Layer 1: Text matching with synonym tables

Exact match, case-normalized match, substring containment
Synonym lookup covering 5 languages (English, Chinese, French, German, Russian) for colors, sizes, materials
Opaque code detection — recognizes that bare "A", "B", "01", "02" carry low information and scores accordingly
Option name alignment — maps "Color" ↔ "颜色", "Emitting Color" ↔ "颜色", "Size" ↔ "尺码"

Layer 2: Unit-aware parsing and conversion

Parses composite values: 4PC-32x42cm → qty:4, dimensions:32×42cm
Converts between unit systems: g↔kg, cm↔m↔mm↔inch, ml↔L, pcs↔pieces↔片↔件
Dimension matching with tolerance: 100*130cm matches 1x1.3m (both = 1000×1300mm)
Area-equivalent detection: 100×200cm matches 200×100cm (same area, different order)
Unit-family alignment: if 80%+ of one option's values are weights (g/kg/oz), it aligns with any other option that's also weights

Layer 3: Image matching via dHash

Perceptual hashing (dHash): resize to 9×8 grayscale, compare adjacent pixels → 64-bit fingerprint
Hamming distance comparison: ≤5 = same image, ≤10 = highly similar, ≤15 = likely match
Only 1 dependency (sharp for image processing), no GPU, no model
Used as auxiliary signal, not primary — adds bonus points to text-based score

Additional signals:

Price proximity (within 5% or 15% adds bonus points)
Logistics dimension filtering ("Ships From" automatically excluded from matching)
Same-product detection (identical image URLs across suppliers)
Unit-price analysis (detects "4-pack at $6.20" vs "1-piece at $2.83" as same unit price)

Scorecard
⚡ Speed: ~1.5ms/product — 100×100 pairs in 150ms
💰 Cost: $0 — ~5MB RAM, zero GPU, zero API
🎯 Accuracy: ██████░░░░ 70-85%
🌐 Cross-language: ✅ 5 languages built-in
📐 Unit conversion: ✅ g↔kg, cm↔m↔inch, AxB dimensions
🔮 Naming chaos: ✅ built specifically for it

Head-to-Head Comparison

Performance & Cost

Approach	Speed	Cost / product	GPU?	Model size
String Rules	⚡⚡⚡ ~0.01ms	$0	—	None
Embeddings	⚡⚡ ~5ms	~$0	optional	80-200MB
LLM Prompting	⚡ 3-10s	$0.01-0.03	—	API key
Vision (CLIP/CNN)	⚡ 50-500ms	~$0	yes	200MB-2GB
Hybrid (sku-matcher)	⚡⚡⚡ ~1.5ms	$0	—	None

Matching Capabilities

Which real-world AliExpress scenarios can each approach actually handle?

Scenario	Rules	Embed	LLM	Vision	Hybrid
`Grey` → `Gray`	✅	✅	✅	—	✅
`Navy Blue` → `Dark Blue`	❌	✅	✅	—	✅
`红色` → `Red`	❌	⚠️	✅	—	✅
`100*130cm` → `1x1.3m`	❌	❌	⚠️	❌	✅
`4PC-32x42cm` → `4pcs 32*42`	❌	❌	⚠️	❌	✅
`Warm White` → `暖光` / `3000K`	❌	⚠️	✅	—	✅
`Color: 03` → `Color: C`	❌	❌	⚠️	✅	⚠️
`Ships From: China` → (filtered)	❌	❌	❌	—	✅
`500g` → `0.5kg`	❌	❌	⚠️	❌	✅
2-pack vs 6-pack (same photo)	—	—	✅	❌	✅

✅ = handles well ⚠️ = partial / unreliable ❌ = fails — = not applicable

Architecture Fit

Factor	Rules	Embed	LLM	Vision	Hybrid
Deterministic output	✅	✅	❌	✅	✅
MCP tool-call ready	✅	⚠️	❌ slow	❌ slow	✅
No external dependency	✅	❌	❌	❌	✅
Works offline	✅	✅	❌	✅	✅
Handles novel terms	❌	⚠️	✅	—	⚠️

Accuracy on Real AliExpress Data

String Rules    ██░░░░░░░░░░░░░░░░░░  30-45%
Embeddings      █████░░░░░░░░░░░░░░░  50-65%
Vision (CLIP)   ██████░░░░░░░░░░░░░░  60-80%
Hybrid (ours)   ██████████░░░░░░░░░░  70-85%
LLM Prompting   ████████████░░░░░░░░  75-90%  (but 2000× slower)

Why I Chose the Hybrid Approach — and Why It Matters for MCP

The comparison above shows an interesting pattern: LLM prompting is the most accurate, but the least suitable for automated pipelines.

When you're building an MCP tool that an AI agent calls during a conversation, the matching engine is just one step in a larger workflow:

Agent (LLM) → dsers_import_list → dsers_find_product
           → sku_matcher (matching) → present results → dsers_supplier_replace

The agent is already an LLM. Adding another LLM call for matching creates:

Nested latency — the outer LLM is waiting (and burning tokens) while the inner LLM processes
Cost multiplication — orchestration tokens + matching tokens for every candidate
Non-deterministic chains — two layers of randomness make debugging harder
Rate limit risk — two concurrent API consumers from the same pipeline

The hybrid algorithmic approach eliminates all of this. It runs in the same Node.js process as the MCP server, returns in milliseconds, and produces identical results every time.

Where it's honestly weaker:

Novel terminology that's not in the synonym tables (LLM handles these better)
Truly ambiguous cases where reasoning is needed (e.g., "is this a phone case color or phone model?")
First encounter with a completely new product category

How we compensate:

The three-tier confidence system (auto / review / unmatched) routes uncertain cases to human review
The agent (which is already an LLM) handles the review cases — it can look at the low-confidence matches and apply reasoning
Category-level scoring overrides let you tune the engine per product type

This is the key insight: use the right tool at the right layer. Deterministic algorithms for the 70-85% of cases that follow patterns. LLM reasoning (from the orchestrating agent) for the remaining 15-30% that need judgment.

FAQ

Which approach should I use for a small store (< 100 products)?
LLM prompting (Approach 3) is likely fine. The cost and latency are manageable at small scale, and the accuracy is highest. If you're already using an AI agent via MCP, the agent itself can handle matching through prompting.

What about a large catalog (1000+ products) with frequent supplier changes?
Hybrid algorithmic (Approach 5) or embeddings (Approach 2) as a first pass, with LLM as fallback for low-confidence matches. The key constraint is cost and speed at scale — $0.03 × 1000 products × 10 candidates = $300 per scan with pure LLM.

Can I combine approaches?
Yes, and that's what production systems do. A common stack: string rules for exact matches → embeddings for semantic recall → LLM for final verification. sku-matcher combines rules + unit parsing + image hashing in a single call, but you can layer LLM verification on top for the review cases.

Why not just use CLIP for everything?
CLIP is powerful but slow (requires GPU for production) and can't distinguish quantities, dimensions, or unit conversions. A placemat photo looks the same whether it's a 2-pack or 6-pack. You'd still need text matching for attribute comparison.

Is sku-matcher open-source?
Yes. github.com/lofder/sku-matcher — single TypeScript file, 8 test scenarios. It's being integrated into DSers MCP Product as the dsers_supplier_match tool.

How does this relate to DSers MCP Product?
DSers MCP Product is an open-source MCP server (12 tools, 4 prompts) for dropshipping automation. sku-matcher is being integrated as the matching engine behind three new tools: dsers_supplier_match, dsers_supplier_replace, and dsers_supplier_scan. Available on npm, Smithery, Glama.ai, and GitHub.

Try It

DSers MCP Product (dropshipping automation via AI agents):

npx -y @lofder/dsers-mcp-product

Or use the Remote MCP endpoint (no install):

{
  "mcpServers": {
    "dropshipping": {
      "url": "https://ai.silentrillmcp.com/dropshipping/mcp"
    }
  }
}

sku-matcher (variant matching engine):

git clone https://github.com/lofder/sku-matcher.git
cd sku-matcher && npm install && npm test

Also in this series:

Your AliExpress Supplier Just Died — Here's How AI Will Auto-Replace It

lofder.issac — Tue, 07 Apr 2026 08:22:09 +0000

TL;DR — I'm building an automated supplier replacement pipeline for dropshipping sellers. It detects dead links and stock-outs, searches AliExpress for alternatives, runs a zero-model SKU matching algorithm to remap variants, and swaps the supplier — all orchestrated by an AI agent via DSers MCP Product. The matching engine (sku-matcher) is open-source, designed to run inside MCP tool calls — lightweight, no model dependency, millisecond response.

Every dropshipper knows the feeling. You wake up, check your dashboard, and see it: your best-selling product's supplier page returns a 404. Or worse — it's still live, but every variant says "out of stock."

Now you're stuck manually finding a new supplier, and then comes the real pain: remapping every single SKU variant. The new supplier calls "Navy Blue" → "Dark Blue." Their sizes are in Chinese. The dimensions are in a different format. You have 40 variants. It's going to take hours.

I've been building tools to automate this entire workflow — from detection to replacement — and I want to share what's coming.

The Dropshipping Supplier Problem

If you run a Shopify or Wix dropshipping store powered by DSers, supplier instability is a constant risk:

AliExpress listings get taken down without warning — one day the URL works, the next it 404s or redirects to a category page
Stock runs out on your best-selling variants — not the whole product, just the popular sizes and colors
Prices spike overnight, killing your margins
Suppliers silently change SKUs — the listing looks the same, but internal SKU codes shift, breaking your mapping
Shipping times change when suppliers switch warehouses or lose logistics partnerships

And then there's the remapping nightmare. You find a new supplier, open both listings side by side, and discover they live in completely different naming universes.

How Bad Is the AliExpress Naming Chaos, Really?

If you've never dealt with this, let me show you what real AliExpress product listings actually look like. It's not just "Grey vs Gray" — it's way worse.

Colors that aren't colors. Suppliers routinely label the "Color" attribute with things that have nothing to do with color. You'll see model numbers (K1-B Yellow), nonsense codes (jiamgunshue, xcvvb), or just bare numbers (01, 02, 03). One supplier's "Color" dropdown is actually phone models. Another's is material types. The attribute name means nothing — you have to look at the images to figure out what each option actually is.

"Ships From" as a variant dimension. Many AliExpress listings include the warehouse location as a product variant alongside color and size. So you get variants like Red / M / China, Red / M / France, Red / M / US Warehouse — tripling your SKU count for what's effectively the same product. When you switch suppliers, the new one might ship from different warehouses, have fewer options, or not use "Ships From" at all.

Dimensions in every format imaginable. One supplier writes 100*130cm. Another writes 1x1.3m. A third writes 100×130. A fourth writes W100xH130cm. They're all the same size, but good luck pattern-matching that by hand across 40 variants. It gets worse with composite values: 4PC-32x42cm means "4 pieces, each 32×42cm" — but the next supplier writes 4pcs 32*42 or 4片-32x42厘米.

Quantities that look like sizes. 30x40cm1pcs — is that a size or a quantity? It's both. 6PC-32x42cm — is "6" the variant count or part of a product code? These composite formats are everywhere in home goods, placemats, wall art, and craft supplies.

Mixed languages within the same listing. Not just Chinese vs English across suppliers — within a single listing you'll find Color: 红色/蓝色, or size options labeled S码, M码, L码 mixed with XL, XXL. Some listings freely mix French (couleur), German (größe), and Russian (цвет) in their option names depending on the seller's region.

The "reset product" death spiral. DSers and other tools have a "Reset Product" function to re-sync with AliExpress. Sounds helpful — except it reverts any custom attribute names you've set back to the supplier's original chaos. Your carefully renamed "Color: Red, Blue, Green" becomes "Color: 01, 02, 03" again. And sometimes the reset introduces NEW attribute slugs that duplicate your existing ones, creating ghost variants that break your store's filters.

This is the reality. Not a clean mapping of Grey → Gray. It's jiamgunshue → Red, 03 → Navy Blue, 4PC-32x42cm → 4pcs 32*42, and a "Color" dropdown that's actually phone models.

That's what sku-matcher is built to handle.

The Automated Pipeline

I'm building a 4-step pipeline that turns supplier replacement from hours of manual work into a one-click confirmation:

Step 1: Detect — Is something broken?

Before you can fix anything, you need to know something broke. Three signals to watch:

Dead links — supplier page returns 404 or redirects to a category page
Stock depletion — all variants hit zero, or key sizes/colors are gone
Price spikes — supplier raised prices beyond your margin threshold

This is the trigger. When any of these fire, the pipeline kicks in automatically.

Step 2: Search — Find alternative suppliers

This is where DSers MCP Product does the heavy lifting. It's an open-source MCP server with 12 tools and 4 prompts for dropshipping automation. The dsers_find_product tool searches the AliExpress supplier catalog by keyword or — and this is the good part — by image. Upload the product photo, get visually similar products back. Way more reliable than keyword search for finding the exact same product from a different seller.

What is DSers MCP Product? It's an open-source MCP server that connects AI agents (Claude, Cursor, Windsurf, etc.) to the DSers dropshipping platform. You can import products from AliExpress/Alibaba, set pricing rules, push to Shopify/Wix stores, manage inventory — all through natural language. It supports both local (npm/stdio) and remote (Streamable HTTP + OAuth) connections, and is listed on npm, Smithery, MCP Registry, and Glama.ai.

The search returns candidates with pricing, ratings, and shipping info. Filter by minimum stock, acceptable price range, ships-from country.

Step 3: Match — Map SKU variants automatically

This is the hard part, and where I spent most of the engineering time.

I built sku-matcher — a pure-algorithm matching engine designed specifically to run inside MCP tool calls, not as a standalone service. No LLM, no ML model, no GPU, no external API dependency. Just deterministic rules that execute in milliseconds.

Why zero-model? Because it's built for MCP. An MCP tool call needs to return a result fast — the AI agent is waiting. You can't send 40×40 variant pairs to an LLM for every candidate supplier. The matching has to be:

Fast — 150ms for 100×100 variant pairs. An agent might evaluate 10 candidate suppliers in one conversation turn
Deterministic — same input, same output, every time. No temperature, no prompt drift
Lightweight — runs in the same Node.js process as the MCP server. Zero cold start, zero API cost, zero token burn
Offline-capable — works without internet access after install. The synonym tables, unit conversion rules, and scoring logic are all local

The engine handles the real-world naming chaos described above:

Your supplier              New supplier
────────────────────────   ──────────────────────────
Grey                    →  Gray
Navy Blue               →  Dark Blue
红色                    →  Red
jiamgunshue             →  (needs image match → Red)
03                      →  (opaque code → low confidence)
90 for 12-18M           →  90
Color                   →  颜色
Emitting Color          →  颜色
4pcs                    →  4 Pieces / 4片
100*130cm               →  1x1.3m
4PC-32x42cm             →  4pcs 32*42
W100xH200cm             →  100×200cm
Warm White              →  暖光 / 3000K
Red/M/China Mainland    →  Red/M  (Ships From filtered)

Three matching layers:

Text matching — exact, normalized, synonym tables covering 5 languages (English, Chinese, French, German, Russian), substring, opaque-code detection
Unit-aware matching — parses and converts between measurement systems. 500g matches 0.5kg. 32x42cm matches 320x420mm. Composite values like 4PC-32x42cm split into count(4) + dimensions and match both parts independently
Image matching — dHash perceptual hashing for when text fails (e.g., supplier uses "Color: 1, 2, 3" instead of actual color names)

Each variant gets scored 0-100. Above 50 = auto-match. 25-50 = needs human review. Below 25 = unmatched.

A real matching example:

Current: "Navy Blue-XL-China Mainland"
         ↓
Step 1: Align dimensions
  Color ↔ 颜色 (synonym)
  Size ↔ 尺码 (synonym)
  Ships From → filtered (logistics, not product attribute)

Step 2: Score values
  "Navy Blue" → synonym → "Dark Blue"    score: 25
  "XL" → exact → "XL"                    score: 40

Step 3: Normalize
  avg(25, 40) / 40 × 80 = 65

Step 4: Auxiliary signals
  +5 (price within 15%) = 70

Result: 70 ≥ 50 → auto match ✓

Step 4: Replace — Swap the mapping

Once matching is done, the results look like this:

{
  "summary": {
    "auto_matched": 35,
    "needs_review": 3,
    "unmatched": 2,
    "total": 40
  }
}

35 out of 40 variants matched automatically. 3 need a quick human check (usually opaque color codes where the algorithm isn't confident enough). 2 variants don't exist at the new supplier.

The seller reviews the 3 uncertain matches, confirms or corrects them, and the mapping is applied. 40 variants remapped in under a minute instead of hours.

How AI Agents Tie It All Together

Here's where MCP (Model Context Protocol) makes this powerful. An AI agent in Claude, Cursor, or any MCP-compatible client can orchestrate the entire flow with a single instruction:

"Check my import list for products running low on stock and find replacements."

The agent:

Calls dsers_import_list → identifies low-stock items
Calls dsers_find_product → searches alternatives by image
Runs sku-matcher → maps variants with confidence scores
Presents results → "35 auto-matched, 3 need your review"
After confirmation → executes the swap via dsers_supplier_replace

The human stays in the loop for the final decision, but the tedious research and mapping work is fully automated. That's the promise of AI agents in e-commerce — not replacing human judgment, but eliminating the busywork around it.

FAQ

Can sku-matcher handle products with 50+ variants?
Yes. The engine matches 100×100 variant pairs in under 150ms. It uses greedy assignment (highest score first, no reuse) so scaling is smooth.

What if the new supplier uses completely different option names?
The dimension alignment system handles this. "Color" maps to "颜色" via synonym tables. If names are completely novel, unit-family detection kicks in — if all values under "Capacity" are in ml/L, it aligns with any other option that has the same unit family.

Does it work with Alibaba and 1688, not just AliExpress?
The matching engine itself is supplier-agnostic — it works on variant data structures. The DSers MCP tools (dsers_find_product, dsers_product_import) support AliExpress, Alibaba, and Accio.com sources.

Is the matching engine open-source?
Yes. sku-matcher is open-source on GitHub. Single TypeScript file, ~1200 lines, 8 test scenarios. The DSers MCP integration will be part of dsers-mcp-product.

Why build it as a local algorithm instead of an LLM call?
Because it runs inside MCP tool calls. When an AI agent calls dsers_supplier_match, the matching engine executes in the same Node.js process — no API roundtrip, no token cost, no latency. The agent can evaluate 10 candidate suppliers in a single conversation turn without burning through rate limits or racking up costs. Synonym tables, unit conversion, and scoring logic are all bundled locally.

How is this different from DSers' built-in supplier optimizer?
DSers' built-in tool suggests alternative suppliers but doesn't auto-map variants. You still remap manually. This pipeline closes the gap — from finding the replacement to applying the mapping, with variant-level confidence scoring.

What's Next

I'm actively integrating sku-matcher into DSers MCP Product. The planned new tools:

Tool	What it does
`dsers_supplier_match`	Run the matching engine against a candidate supplier
`dsers_supplier_replace`	Execute the variant mapping swap
`dsers_supplier_scan`	Batch-scan your catalog for stock/link/price problems and auto-find replacements

Try DSers MCP Product today:

Local (stdio):

npx -y @lofder/dsers-mcp-product

Remote MCP (no install, just add the URL to your MCP client):

{
  "mcpServers": {
    "dropshipping": {
      "url": "https://ai.silentrillmcp.com/dropshipping/mcp"
    }
  }
}

Available on: npm · GitHub · Smithery · MCP Registry · Glama.ai · Apify

Explore the matching engine:

git clone https://github.com/lofder/sku-matcher.git
cd sku-matcher && npm install && npm test

If you're building dropshipping automation or dealing with SKU mapping problems, I'd love to hear your use cases. Drop a comment or open an issue on GitHub.

Also in this series:

How to Automate AliExpress to Shopify Product Import with AI — Step-by-Step Guide
DSers MCP Product on GitHub — 12 tools + 4 prompts for dropshipping automation

I Convinced DSers to Add OAuth 2.1 — Dropshipping MCP Server v1.4.0

lofder.issac — Fri, 03 Apr 2026 16:34:14 +0000

TL;DR: DSers MCP Product v1.4.0 — convinced DSers to add official OAuth 2.1, replaced 600 lines of browser hacking with 200 lines of clean auth. Added 3 new tools (browse imports, search suppliers, view store products). Shipped a hosted remote server at ai.silentrillmcp.com. 12 tools, 298 tests, open source. GitHub

Why Build This?

If you're doing dropshipping with DSers and Shopify, you know the routine — find a product on AliExpress, open DSers, click import, manually edit the title, set the markup, push to store, repeat fifty times. It's not hard, it's just slow.

I built this MCP server so I could tell my AI agent "import these 10 products, mark them up 2.5x, clean up the titles, push to my store" and go do something else. It handles AliExpress, Alibaba, and Accio.com product links. Supports Shopify and Wix through DSers.

The tool is free, open source, and works with Claude Desktop, Cursor, Windsurf, or any MCP-compatible client. You can run it locally via npm or connect to the hosted version without installing anything.

For anyone evaluating dropshipping automation tools — this isn't a SaaS with a monthly fee. It's an MCP server you run yourself (or use hosted for free). No vendor lock-in, no subscription tiers. The code is on GitHub, MIT licensed.

I've been building an open-source MCP server that automates dropshipping product imports — AliExpress to Shopify, through DSers. If you missed the earlier posts, the short version: paste a product link, tell your AI agent what markup to apply, and it handles the rest.

But authentication has been my biggest headache since day one.

The Authentication Problem

When I first built this tool, DSers didn't have an OAuth flow designed for third-party integrations. So I went with what I could — automating a browser login via Chrome DevTools Protocol to capture the session.

It got the job done, but it wasn't pretty. I had to handle Chrome on Mac, Edge on Windows, Safari as a fallback, and a terminal prompt for headless servers. Four different login strategies, ~600 lines of browser automation code, and the whole thing depended on having a Chromium browser installed.

And sessions expired every 6 hours. Users would be halfway through a bulk import, and suddenly — "session expired, please run login again."

I knew there had to be a better way.

Getting DSers on Board

I reached out to the DSers team about building OAuth support for MCP integrations. They were receptive — the MCP ecosystem is growing fast, and they could see the value in letting AI tools connect properly instead of relying on browser session workarounds.

We went through a few rounds of designing the scope model, endpoint structure, and token lifecycle. I built a proof-of-concept proxy to validate the flow before committing to a full integration. There were the usual bumps — some gateway routes needed configuring, a few scope-to-endpoint mappings to sort out — but the DSers team was responsive and we got it all working.

Credit where it's due: they built a solid OAuth 2.1 authorization server with PKCE, dynamic client registration, and refresh tokens. Proper stuff.

What Login Looks Like Now

npx @lofder/dsers-mcp-product login

Browser opens. You click "Authorize" on DSers's own page. Done.

Behind the scenes: PKCE code challenge, authorization code exchange, access token + refresh token saved to an encrypted local file. When the access token expires (every 2 hours), the refresh token renews it silently. No user interaction needed.

I deleted all 600 lines of CDP code. The new OAuth module is about 200 lines. And it just works — no Chrome dependency, no cookie extraction, no platform-specific browser detection.

The token file format is shared with DSClaw (our web app). If a user authorizes through DSClaw, the MCP server picks up the same token automatically. One login for everything.

The Remote Server Is Live

With OAuth working, I could finally ship a hosted MCP server that doesn't require any local installation.

{
  "mcpServers": {
    "dropshipping": {
      "url": "https://ai.silentrillmcp.com/dropshipping/mcp"
    }
  }
}

Add that to your MCP client config and you're connected. No npx, no Node.js, nothing to install. The server runs on Vercel, authenticates via the OAuth Bearer token, and isolates each user's data by extracting the sub claim from the JWT.

Getting this to work on Vercel had its own challenges — the mcp-handler library initializes the MCP server before the request context is available, so the token wasn't ready when tools were being registered. Took a few iterations to land on the right pattern: create a fresh handler per request with the token baked in, cache only the job store across requests for the same user.

New Tools for Browsing and Sourcing

The original 9 tools covered the import-to-push pipeline. But there was an obvious gap: "what's already in my import list?" was unanswerable without opening the DSers website.

v1.4.0 adds three new tools:

dsers_import_list pulls your staging list with enriched data — cost ranges, sell prices, markup status, and low stock warnings. Each item gets a separate API call for variant-level detail, running in parallel.

dsers_my_products shows what's already been pushed to your Shopify or Wix store, with supplier links for re-importing.

dsers_find_product searches the DSers product pool by keyword or image. Each result includes an import_url you can feed directly into dsers_product_import.

The workflow is now: search → import → edit → push. All from your AI client.

Under the Hood

The codebase got a full restructure. provider.ts was 1,700 lines — one file handling everything. A bad commit in v1.3.5 accidentally reverted 6 different bug fixes because it was all tangled together.

Split into 6 modules under provider/ and 7 under service/. Added ESLint + Prettier. Tests went from 195 to 298.

Other fixes:

tags_add was validated but never actually written to the API — one line was hardcoded to null
compare_at_price inversions now auto-cleared instead of just warned about
Replaced execSync with spawnSync for browser launch to prevent command injection

What's Next

More product pool search filters (categories, price ranges, ship-from)
A few DSers OAuth scope rules still being configured
Order tracking tools (the Python version already has them)

Open source: github.com/lofder/dsers-mcp-product

Install: npx @lofder/dsers-mcp-product

Hosted: https://ai.silentrillmcp.com/dropshipping/mcp

Dropshipping Automation Tools Compared: DSers MCP vs AliDropify vs AutoDS vs AeroDrop (2026)

lofder.issac — Thu, 02 Apr 2026 07:33:48 +0000

TL;DR: There are two fundamentally different approaches to dropshipping automation in 2026: traditional web-based tools (AliDropify, AutoDS, AeroDrop) that give you a dashboard with buttons to click, and AI-native tools (DSers MCP Product) that let you automate workflows through conversation with an AI agent. This post breaks down the features, pricing, and trade-offs of each approach.

If you're running a dropshipping store in 2026, you've probably Googled "best dropshipping automation tool" at least once this week. The options are overwhelming — every tool claims to automate everything, save you hours, and practically run your store for you.

I've used several of these tools over the past couple of years. Some are genuinely good. Some are expensive for what they do. And one category is completely new — AI-native tools that don't have a dashboard at all.

Here's an honest comparison of the four tools I've actually used or evaluated in depth.

The Contenders

Tool	Approach	Starting Price	Product Sources	Platforms
DSers MCP Product	AI-native (MCP server)	Free (open-source)	AliExpress, Alibaba, 1688, Accio	Shopify, Wix
AliDropify	Web dashboard + Chrome extension	$39.99/mo	AliExpress, Alibaba, Temu, Shein	Shopify
AutoDS	Web dashboard + automation suite	$26.90/mo	40+ suppliers	Shopify, eBay, Amazon, Wix
AeroDrop	Shopify app	Free (limited) / $18/mo	AliExpress	Shopify

How They Work (The Fundamental Difference)

Traditional tools: You click buttons

AliDropify, AutoDS, and AeroDrop all follow the same model: you open their website or Shopify app, browse products, click "import," adjust settings through their UI, and click "push to store."

This works. It's visual, it's intuitive, and most dropshippers are comfortable with it. But you're still doing the work manually — just in a more efficient interface.

AI-native: You describe what you want

DSers MCP Product takes a completely different approach. There's no dashboard. Instead, you connect it to an AI client (Cursor, Claude Desktop) and tell your AI agent what to do in plain English:

"Import this product from AliExpress, mark up 2.5x, rewrite the title for SEO, and push to my US store as a draft."

The AI agent calls the right tools in the right order, shows you previews, asks for confirmation, and executes. You're describing outcomes instead of clicking through steps.

Feature Comparison

Product Import

Feature	DSers MCP	AliDropify	AutoDS	AeroDrop
One-click import	Via conversation	Chrome extension	Dashboard	Shopify app
Bulk import	Yes (unlimited URLs)	Yes	Yes (plan limits)	Yes (plan limits)
AliExpress	Yes	Yes	Yes	Yes
Alibaba	Yes	Yes	Limited	No
1688	Yes (with DSers auth)	No	No	No
Temu / Shein	No	Yes	Yes	No

Verdict: AutoDS wins on supplier breadth (40+ sources). DSers MCP wins on depth for AliExpress/Alibaba workflows. AliDropify covers the most consumer platforms (Temu, Shein).

Pricing Rules

Feature	DSers MCP	AliDropify	AutoDS	AeroDrop
Markup multiplier	Yes (e.g. 2.5x)	Yes	Yes	Yes
Fixed markup	Yes (e.g. +$5)	Yes	Yes	Yes
Compare-at / sale price	Yes	Limited	Yes	No
Per-variant pricing	Yes	No	Yes	No
Pricing conflict detection	Yes	No	No	No

Verdict: DSers MCP and AutoDS are the most flexible. DSers MCP's pricing conflict detection is unique — it blocks pushes when your MCP rules conflict with DSers store-level pricing rules, preventing silent price overrides.

Store Push

Feature	DSers MCP	AliDropify	AutoDS	AeroDrop
Shopify	Yes	Yes	Yes	Yes
Wix	Yes	No	Yes	No
WooCommerce	Via DSers	No	Yes	No
eBay	No	No	Yes	No
Multi-store push	Yes (one command)	No	Yes	No
Pre-push safety checks	Yes (auto-blocks below-cost)	No	No	No

Verdict: AutoDS has the most platform coverage. DSers MCP has the best safety nets — it automatically blocks zero-price, below-cost, and zero-stock pushes.

AI & SEO

Feature	DSers MCP	AliDropify	AutoDS	AeroDrop
AI title rewriting	Yes (via AI agent)	No	Yes (AI feature)	Yes (Premium)
AI description rewriting	Yes (via AI agent)	No	Yes (AI feature)	Yes (Premium)
Title cleanup	Yes (built-in)	Basic	Basic	Basic
Custom content rules	Yes (prefix, suffix, keep_first_n images)	No	Limited	No

Verdict: DSers MCP and AutoDS both offer AI content features. The difference is that DSers MCP uses your own AI client (Claude, GPT) so the quality depends on the model you're using — and you can give it specific instructions like "write this title for the US hiking market." AutoDS uses its built-in AI which is more limited but requires no setup.

Pricing Breakdown

Plan	DSers MCP	AliDropify	AutoDS	AeroDrop
Free tier	Yes (fully free, open-source)	No	No	Yes (500 products, 200 orders)
Entry paid	N/A	$39.99/mo	$26.90/mo	$18/mo
Mid tier	N/A	$99.99/mo	$66.90/mo	$48/mo
Per-order fees	No	No	$0.30-0.50/order (auto-fulfillment)	No

DSers MCP is completely free. MIT license, no subscription tiers, no per-order fees, no usage limits. The only requirement is a DSers account (which also has a free plan supporting 3,000 products and 3 stores).

AeroDrop's free tier is decent for testing but caps at 200 orders/month. AliDropify is the most expensive entry point at $40/mo. AutoDS has hidden costs — the auto-fulfillment credits ($0.30-0.50 per order) add up fast on high-volume stores.

Security

Feature	DSers MCP	AliDropify	AutoDS	AeroDrop
Password in config file	No (zero-password login)	N/A (web login)	N/A (web login)	N/A (Shopify OAuth)
Open-source (auditable)	Yes	No	No	No
Security scan score	92/100 (SafeSkill)	N/A	N/A	N/A

DSers MCP is the only tool in this list where you can read every line of code that touches your data. Authentication uses browser-based login — your password never touches the tool. I wrote a detailed post about the security model if you're interested.

Who Should Use What

Use DSers MCP Product if:

You already use Cursor, Claude Desktop, or another MCP client
You want full automation through conversation, not clicking
You want a free, open-source tool with no usage limits
You care about code transparency and security
Your main sources are AliExpress and Alibaba

Use AutoDS if:

You sell on eBay or Amazon (not just Shopify)
You need 40+ supplier sources
You want a fully managed solution and don't mind paying
You don't use AI coding tools

Use AliDropify if:

You import from Temu or Shein (not just AliExpress)
You prefer a Chrome extension workflow
You're on Shopify only

Use AeroDrop if:

You're just starting out and want a free Shopify app
Your volume is under 200 orders/month
You want the simplest possible setup

The Bigger Picture

These tools aren't really competing with each other — they represent two different eras of e-commerce tooling.

Traditional tools (AliDropify, AutoDS, AeroDrop) are mature, feature-rich, and designed for people who want a visual dashboard. They're better at order fulfillment, inventory sync, and platform breadth.

AI-native tools (DSers MCP Product) are new, focused on the import-to-push workflow, and designed for people who are already using AI assistants daily. They're better at flexible automation, custom rules, and conversational workflows.

My prediction: within a year, every major dropshipping tool will have an MCP server or similar AI integration. The tools that figure this out first will have a significant advantage.

Links:

DSers MCP Product: github.com/lofder/dsers-mcp-product (free, open-source)
Tutorial: How to Automate AliExpress to Shopify with AI
Technical deep-dive: I Built an MCP Server to Automate Dropshipping Product Imports

How to Automate AliExpress to Shopify Product Import with AI (Step-by-Step Guide)

lofder.issac — Wed, 01 Apr 2026 10:17:16 +0000

If you run a dropshipping store, you already know the pain: find a product on AliExpress, copy the title, download the images, clean up the description, set your margins, push it to Shopify. Do that 20 times and your evening is gone.

I got tired of doing this manually, so I built a tool that lets an AI agent handle the whole thing. You type one sentence — "import this product, mark it up 2.5x, push to my store" — and it just happens. No scripts, no browser extensions, no Zapier glue.

This guide walks you through setting it up. It takes about 5 minutes, and you don't need to write any code.

TL;DR: You can automate AliExpress-to-Shopify product imports using a free, open-source tool called dsers-mcp-product. Install with npx @lofder/dsers-mcp-product login, add a 3-line JSON config to Cursor or Claude Desktop, and start importing products with plain English commands like "import this product, mark up 2.5x, push to my store." No coding needed, no passwords in config files.

What You'll Need

Before we start, make sure you have:

A DSers account (free plan works) with at least one Shopify or Wix store connected
Cursor or Claude Desktop — these are AI coding assistants that support MCP (Model Context Protocol), the standard this tool uses to talk to AI
Node.js 22 or later — if you don't have it, grab it from nodejs.org

What you don't need: coding experience, API keys, or any paid subscription beyond what you already have.

Step 1: Log In (One Time, 30 Seconds)

Open your terminal and run:

npx @lofder/dsers-mcp-product login

Your browser opens to the official DSers login page. Log in the way you normally do. That's it — the tool picks up your session automatically.

Your password never touches this tool. You're logging in on DSers's own website. The MCP server only receives a session token, which is encrypted and stored locally on your machine. No passwords in any config file, ever.

Sessions last about 6 hours. When one expires, your AI agent will tell you and ask you to run login again. Takes 10 seconds.

Step 2: Connect to Your AI Client

If you use Cursor

Add this to your .cursor/mcp.json:

{
  "mcpServers": {
    "dsers-mcp-product": {
      "command": "npx",
      "args": ["-y", "@lofder/dsers-mcp-product"]
    }
  }
}

If you use Claude Desktop

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "dsers-mcp-product": {
      "command": "npx",
      "args": ["-y", "@lofder/dsers-mcp-product"]
    }
  }
}

Restart your client. You should see "dsers-mcp-product" appear in the connected tools list. That's the setup — everything else happens in conversation.

Step 3: Import Your First Product

Open a chat with your AI agent and type something like:

"Import this product and push it to my Shopify store as a draft: https://www.aliexpress.com/item/1005006372921430.html"

Behind the scenes, the agent will:

Discover your connected stores (which Shopify/Wix shops you have)
Import the product from AliExpress into your DSers workspace
Preview the result — showing you the title, price, variants, and images
Push it to your store as a draft listing

You'll see the preview before anything gets pushed. The agent asks for your confirmation at each step, so nothing happens without your say-so.

Works with product links from AliExpress, Alibaba.com, and Accio.com (Alibaba's AI sourcing tool). Just paste the URL and the agent figures out the rest.

Step 4: Bulk Import with Pricing Rules

One product is nice. But the real power is batching. Try this:

"Import these 5 products, mark up the price by 2.5x, and push them all as drafts: [URL1] [URL2] [URL3] [URL4] [URL5]"

The agent imports all five, applies a 2.5x markup to every variant, and pushes them in one go.

Pricing options you can use

Multiplier: "mark up 2.5x" — sell price = supplier cost × 2.5
Fixed markup: "add $5 to each variant" — sell price = supplier cost + $5
Compare-at price: "set compare-at to 3x supplier cost" — shows a crossed-out "original" price on your store
Combination: "2x markup with compare-at at 3x" — both at once

You can also mix it into natural language:

"Import this product. Set the sell price to 2x supplier cost, add a compare-at price at $29.99, and only keep the first 5 images."

The agent understands all of these and translates them into the right tool parameters.

Step 5: Push to Multiple Stores

If you run stores in different markets, this saves a lot of time:

"Push this product to all my connected stores"

The agent calls store.discover to find every Shopify and Wix store linked to your DSers account, then pushes to each one. You can also be selective:

"Push to my US store with 2.5x markup and my EU store with 3x markup"

Per-store pricing, per-store visibility — one conversation.

Step 6: SEO Before You Push

AliExpress product titles are usually keyword-stuffed garbage. Before pushing, you can ask the AI to clean things up:

"Import this product, rewrite the title and description for SEO, then push to my store"

The agent will:

Import the product
Generate a clean, search-friendly title and description
Show you the rewritten version for approval
Push after you confirm

You stay in control — it won't publish anything without showing you first.

Safety Nets Built In

One thing that kept me up at night with manual imports was accidentally pushing a product with wrong pricing. The tool has automatic safety checks:

Hard blocks (push won't go through):

Selling below supplier cost
Zero sell price on any variant
All variants out of stock

Warnings (push goes through, but you get a heads-up):

Profit margin below 10%
Stock under 5 units
Sell price under $1

Pricing rule conflict detection: If your DSers store already has its own pricing rule enabled (basic/standard/advanced), and you also set pricing through the MCP tool, the push gets blocked — not just warned. The agent shows you two options: accept the store's pricing rule, or disable it in DSers settings to use your MCP pricing instead. No more silent price overrides.

If you're 100% sure about an edge case, you can tell the agent to force_push. But the default is to protect you from mistakes.

What's Under the Hood

The tool is called dsers-mcp-product — it's open source, built in TypeScript, and uses 9 specialized tools and 4 workflow prompts to handle the full import-to-push pipeline. It's published on npm, the official MCP Registry, Smithery, Glama (AAA rated), and several other directories.

If you're curious about the architecture and the decisions behind the tool design, I wrote a separate technical post: I Built an MCP Server to Automate Dropshipping Product Imports.

Quick Reference

Install:

npx @lofder/dsers-mcp-product login

Config (Cursor / Claude Desktop):

{
  "mcpServers": {
    "dsers-mcp-product": {
      "command": "npx",
      "args": ["-y", "@lofder/dsers-mcp-product"]
    }
  }
}

Common commands:

What you want	What to say
Import one product	"Import this product: [URL]"
Import with markup	"Import this, mark up 2.5x: [URL]"
Bulk import	"Import these products: [URL1] [URL2] [URL3]"
Push to store	"Push this product to my Shopify store"
Push to all stores	"Push to all my stores"
SEO rewrite	"Rewrite the title for SEO, then push"
Clean up titles	"Clean up the AliExpress title"
Check push status	"Did that push go through?"

Links:

GitHub: github.com/lofder/dsers-mcp-product
npm: npmjs.com/package/@lofder/dsers-mcp-product
MCP Registry: registry.modelcontextprotocol.io

If you run into any issues, open a GitHub issue — I'm actively fixing bugs and adding features. This is still early days, and feedback from actual store owners is what makes it better.

Your MCP Server Shouldn't Need Your Password

lofder.issac — Wed, 25 Mar 2026 13:54:44 +0000

TL;DR: MCP servers shouldn't require users to put plaintext passwords in config files. dsers-mcp-product uses browser-based zero-password login — you authenticate on the official DSers website, and the tool picks up an encrypted session token. Your password never touches the MCP server.

The Awkward Config Block

If you've set up any MCP server that connects to a third-party service, you've probably seen something like this:

{
  "mcpServers": {
    "some-tool": {
      "env": {
        "SERVICE_EMAIL": "you@example.com",
        "SERVICE_PASSWORD": "hunter2"
      }
    }
  }
}

Your password. In a JSON file. On your disk. Possibly synced to a dotfiles repo.

I shipped exactly this in v1.0 of dsers-mcp-product, my MCP server for automating DSers dropshipping imports. (If you missed the backstory, I wrote about building it from scratch here.) It worked fine. Import from AliExpress, apply pricing rules, push to Shopify — all through Claude or Cursor.

But every time someone set it up, that DSERS_PASSWORD line bothered me.

Why It Matters More Than You Think

MCP servers run locally. They have access to your filesystem, your environment variables, your network. When you put a plaintext password in a config file, you're trusting every other tool on your machine, every extension in your editor, every sync service that touches that directory.

For a tool that manages your store inventory and can push products to live Shopify stores, that's not a risk I wanted users to carry.

Some MCP servers solve this with API keys or tokens that have limited scope. DSers doesn't offer that for individual users. Your DSers credentials are your DSers credentials. So I needed a different approach.

Browser Login: Let DSers Handle Authentication

The fix in v1.1.5 was to get out of the credential chain entirely:

npx @lofder/dsers-mcp-product login

This opens your default browser to the DSers login page. You log in normally — with whatever method you use (email/password, Google, whatever). The tool captures the session cookie through a local callback, encrypts it with AES-256-GCM, and stores it on disk.

Your password never touches the MCP server. Never appears in a config file. Never gets logged.

The MCP config becomes:

{
  "mcpServers": {
    "dsers-mcp-product": {
      "command": "npx",
      "args": ["-y", "@lofder/dsers-mcp-product"]
    }
  }
}

That's it. No env block. No credentials.

The session lasts roughly 6 hours. When it expires, the tool prompts you to re-login. Could be smoother, but it's a lot better than a plaintext password.

Push Guards: Because AI Makes Mistakes

While I was rethinking security, I also added something I'd been meaning to build: pre-push safety checks.

Before any product gets pushed to your store, the server now automatically blocks:

Zero-price products — variants with $0.00 price
Below-cost pricing — sell price lower than supplier cost
Zero-stock items — out-of-stock variants about to go live

These checks run before the push reaches DSers. The AI gets a clear error it can act on — fix the pricing, drop the variant, or ask you what to do.

Here's a real scenario: I imported a product with 12 variants. Two had a supplier cost of $8.50 but the pricing rule somehow set the sell price at $6.00. Without push guard, those would have gone live on Shopify at a loss. With it, the push gets blocked and the model sees:

{Error: "Below-cost pricing", Cause: "2 variants priced below supplier cost", Action: "Review pricing rule or exclude variants"}

This isn't about not trusting the AI. It's about not trusting the data. Supplier feeds have garbage in them all the time — prices that lag behind, stock counts frozen at zero, variants with placeholder data. A human would catch these by eyeballing the preview. The push guard catches them automatically.

What Changed Since v1.0

If you read the first post, the core workflow is the same — tell your AI to import a product, set pricing, push to Shopify or Wix. But v1.1.5 added a few things beyond the login change:

Push guards (covered above)
Accio.com support — same import flow, one more supplier source alongside AliExpress and Alibaba
A fourth prompt (seo-optimize) for AI-rewriting titles and descriptions before push
Stock data in previews — so you can see inventory before committing
Better error messages — clearer cause descriptions for import failures, JSON validation guidance, transient push state handling
CLI --help flag — npx @lofder/dsers-mcp-product --help now works
Prompts from 3 → 4, tools still at 7, now on 9 platforms

Try It

# One-time login (opens browser)
npx @lofder/dsers-mcp-product login

# Add to your MCP client — no password needed

GitHub: github.com/lofder/dsers-mcp-product
npm: @lofder/dsers-mcp-product

Free, open source, MIT license. If you're running dropshipping stores and using an MCP client, give it a spin. Issues and feedback welcome.

Previously: I Built an MCP Server to Automate Dropshipping Product Imports

Your AI Agent Has Amnesia — Here's How to Fix It (MCP + Mem0 + Qdrant)

lofder.issac — Tue, 24 Mar 2026 15:12:53 +0000

Every AI agent you have ever built forgets everything the moment the conversation ends.

I run a fleet of AI agents on Feishu (think of it as the Chinese Slack) and Telegram. A main orchestrator, a devops agent, a content writer, half a dozen specialized workers. One day my content agent asked me, for the fifth time, what writing style I preferred. The devops agent had no idea we had already debugged the same DNS issue last week. Every morning, each agent woke up as a blank slate.

That is not a feature. It is a bug. So I built smart-memory-gateway to fix it.

This article is a conceptual deep-dive into the architecture decisions behind it. You do not need to know what MCP or Mem0 is. You just need to have felt the pain of stateless agents.

The Memory Hierarchy Your Agent Is Missing

If you have taken a computer architecture class, you know the CPU cache hierarchy:

Access speed    +-----------+    Capacity
  fastest       |  L1 Cache |    smallest
                +-----------+
                |  L2 Cache |
                +-----------+
                |  L3 Cache |
                +-----------+
                |    RAM    |
                +-----------+
                |   Disk    |    largest
  slowest       +-----------+

AI agents have an equivalent hierarchy, but most developers only build two of the three layers:

Layer    | Analogy   | What It Is                        | Properties
---------|-----------|-----------------------------------|--------------------
L1       | L1 Cache  | Context window (conversation)     | Fast, small, gone when chat ends
L2       | L2 Cache  | Persistent semantic memory         | THIS IS THE MISSING PIECE
L3       | Disk      | Files, databases, wikis           | Slow to search, huge, unstructured

L1 is what every agent already has: the conversation history. It is fast and relevant, but it vanishes when the session ends (or when the context window fills up and older messages get evicted).

L3 is what people reach for first when they want "memory": dump everything into a vector database, a folder of markdown files, or a RAG pipeline over your documents. It works for reference material, but it is cold storage. Searching for "what does the user prefer" across thousands of documents is slow and imprecise.

L2 -- persistent semantic memory -- is what sits between them. It stores extracted facts, preferences, lessons, and decisions. It is small enough to search quickly, structured enough to filter precisely, and persistent across every conversation. This is what smart-memory-gateway provides.

The key insight: your agent does not need to remember every word of every conversation. It needs to remember the conclusions -- the user prefers concise writing, the production database is on port 5433, we decided to use Redis for caching last Tuesday.

Why Scope Matters More Than You Think

Here is a concrete problem. I run two agents on the same Feishu platform:

A devops agent that manages servers, monitors logs, and runs deployments
A content agent that drafts articles, manages social media, and writes ad copy

Without scope isolation, here is what actually happened: the content agent started referring to "the cluster" in marketing copy. The devops agent once suggested we should "A/B test the nginx configuration." Their memories had bled into each other.

The solution is a 4-scope model:

                        +-----------+
                        |  global   |  Shared across all agents and chats
                        +-----+-----+  (user facts, cross-cutting preferences)
                              |
              +---------------+---------------+
              |               |               |
        +-----+-----+  +-----+-----+  +-----+-----+
        | group:oc01 |  | group:oc02 |  |    dm     |  Per-chat / per-group
        +-----+-----+  +-----+-----+  +-----+-----+  (project context, group decisions)
              |               |               |
        +-----+-----+  +-----+-----+  +-----+-----+
        | agent:devops  | agent:writer  | agent:...  |  Per-agent private
        +-----+-----+  +-----+-----+  +-----+-----+  (agent-specific procedures)

Every memory is tagged with exactly one scope at write time. Every search merges results from the current scope and global, so agents always have access to cross-cutting knowledge (like user preferences) without seeing each other's operational details.

The config makes this concrete. Here is the permission model from the actual config.yaml:

agents:
  main:
    read: [global, "group:*", dm, "agent:*"]
    write: [global, "group:*", dm]
    allowed_types: [preference, fact, procedure, lesson, decision, task_log]
  devops:
    read: [global, "group:*", dm, "agent:*"]
    write: [global, "group:*", dm, "agent:*"]
    allowed_types: [preference, fact, procedure, lesson, decision, task_log]
  writer:
    read: []
    write: ["agent:writer"]
    allowed_types: [procedure, task_log]

default_agent_policy:
  read: [global]
  write: []
  allowed_types: []

The main orchestrator can read and write broadly. Specialized workers like writer can only write to their own private scope. And by default, unknown agents get read-only access to global memory and cannot write at all.

This is not just about data hygiene. It is about trust boundaries. If an agent gets compromised or hallucinates, the blast radius is contained.

The MCP Interface: Why Not Just a REST API?

MCP stands for Model Context Protocol -- it is an open standard for connecting AI agents to tools and data sources. You might be wondering: why not just expose memory as a REST API?

The answer is ergonomics. With a REST API, you need to write custom integration code in every agent: HTTP client setup, authentication, response parsing, error handling. With MCP, your agent calls memory tools the exact same way it calls any other tool -- file operations, web search, code execution. The model already knows how to use tools. Memory becomes just another tool in the toolbox.

smart-memory-gateway exposes 5 tools through FastMCP:

Tool	Purpose
`mem0_add`	Store a memory with scope, type, trust level, provenance
`mem0_search`	Semantic search with scope isolation and dual-query merge
`mem0_get_all`	List all memories, optionally filtered by scope
`mem0_status`	Health check: memory counts, scope distribution, backend status
`mem0_maintenance`	Trigger daily/weekly maintenance cycles

Here is what a real conversation flow looks like. When my agent starts a new chat, it does not ask "what do you like?" again. It searches memory first:

User: Help me write a product description for the new headphones.

Agent (internal): call mem0_search(
    query="user writing style preferences",
    scope="group:oc_marketing",
    limit=5
)

Memory returns:
  - "User prefers concise, no-fluff writing style" (trust: high)
  - "Product descriptions should lead with the benefit, not specs" (trust: medium)
  - "Avoid exclamation marks in copy" (trust: high)

Agent: Here's a draft in your preferred concise style,
       leading with the benefit...

And after the conversation, the agent stores the conclusion, not the whole chat:

Agent (internal): call mem0_add(
    content="Headphone product line uses the tagline format:
             [benefit] + [one technical proof point]",
    scope="group:oc_marketing",
    mem_type="decision",
    source="user_approved",
    trust="high"
)

I also built a separate MCP server for dropshipping product imports that consumes this memory as a client. When that agent processes a new product, it queries memory for supplier preferences, pricing rules, and past decisions -- all scoped to the relevant workspace.

The Write Path Trade-off: Fast vs. Smart

This was the single most impactful architecture decision in the project, and I almost got it wrong.

Mem0 has a built-in feature where every add() call passes through an LLM to extract structured entities and relationships from the raw text. It is smart. It is also slow.

Write with LLM extraction (infer=True):     5-8 seconds
Write with embedding only  (infer=False):   ~1.3 seconds

In a real-time chat, 5-8 seconds of latency on every memory write is unacceptable. The user is waiting for a response while the agent is quietly making an API call to Claude or GPT to analyze the memory content.

The solution is a hot/cold split inspired by the MAPLE paper:

                HOT PATH (real-time)              COLD PATH (scheduled)
                ~1.3s per write                   Runs at 3:00 AM

User talks  ──> mem0_add(infer=False) ──>  Qdrant    <── maintenance.py
to agent        Embedding only                         │
                No LLM extraction                      ├── Opus re-extraction
                No classification                      ├── Dedup (0.92 threshold)
                                                       ├── Classification
                                                       ├── Conflict detection
                                                       └── Decay scoring

During the day, writes are fast: embed the text, store it with metadata, move on. The infer=False flag tells Mem0 to skip the LLM extraction step:

result = mem.add(content, user_id="default", metadata=metadata, infer=False)

At 3 AM, the maintenance script wakes up, pulls all of today's memories, and re-processes them through a high-quality model (Claude Opus) for proper entity extraction, deduplication, and classification. It is the same data, but now with rich structure.

This means there is a window -- roughly from when a memory is written until the next maintenance run -- where the memory exists but is not fully classified. In practice, this rarely matters because semantic search works on the embedding regardless. But if you needed a memory classified as procedure vs task_log for filtering, you would have to wait until maintenance runs.

The fallback chain also deserves a mention. If Mem0 is unavailable at write time, the server does not drop the memory. It queues it:

if mem is None:
    entry = {"write_id": write_id, "content": content, "metadata": metadata}
    with open(WRITE_QUEUE_PATH, "a") as f:
        f.write(json.dumps(entry) + "\n")
    return {"queued": True, "reason": "Mem0 unavailable, cached for replay"}

On the next successful write, the queue gets replayed. Writes are never lost, even when the backend crashes.

Keeping Memory Alive: Decay, Consolidation, and Conflict

Here is something most "memory for AI" projects get wrong: they treat memory as write-once-read-forever. Store it and forget about it (no pun intended).

But memory decays. Memory conflicts. Memory fragments. If you have used your system for three months, you have duplicates, contradictions, and a pile of task logs from February that nobody will ever query again. Without maintenance, search quality degrades as noise drowns out signal.

The smart-memory-gateway maintenance system has four cognitive engines, and each one draws from a different idea about how memory works.

Decay: The Forgetting Curve

Inspired by Bjork's storage-retrieval strength theory and the FadeMem paper, each memory gets an importance score that decays exponentially over time:

I(t) = exp(-lambda * effective_age)

where:
  effective_age = age_days / (1 + min(log(1 + access_count), cap))
  lambda = ln(2) / half_life_days

The crucial detail: access_count slows the decay. A memory that gets retrieved often decays slower than one that was written and never read again. This mirrors how human memory works -- the more you recall something, the harder it is to forget.

Different memory types have different half-lives:

Type	Half-life	Rationale
`task_log`	30 days	"Deployed v2.1 to staging" -- useful for a month, noise after that
`procedure`	90 days	"Restart command is X" -- lasts longer but can become stale
`fact`, `preference`, `lesson`	Never decays	"User's name is Y" -- these are permanent

When importance drops below 0.10, the memory gets archived -- not deleted. It is soft removal. You can always un-archive if needed.

Consolidation: Turning Fragments Into Knowledge

After a week of conversations, you might have 15 task_log entries about debugging the same service. Individually, they are noise. Together, they contain a lesson.

The consolidation engine groups related memories, sends them through an LLM, and produces a single knowledge summary. The original fragments get an accelerated decay but are not deleted -- provenance is tracked through a consolidated_from field.

Conflict Resolution: When Memory Contradicts Itself

"User prefers dark mode" and "User prefers light mode" -- stored two months apart. Which one is true?

The conflict engine identifies same-type memories within the same scope that might contradict each other, then uses an LLM to judge: are they actually contradictory, or just about different topics? If contradictory, the newer one wins (with a superseded_by marker on the loser).

Putting It Together

The maintenance runs on a two-tier schedule:

Daily (3:00 AM):
  1. Re-extract today's memories with Opus (high-quality LLM)
  2. Deduplicate (cosine similarity > 0.92 = auto-merge)

Weekly (Sunday):
  3. All daily steps, plus:
  4. Conflict detection and resolution
  5. Consolidation of fragmented task_logs
  6. Decay scoring and archival

A typical weekly report (sent to Feishu automatically) looks like: 4 memories re-extracted, 2 duplicates merged, 1 conflict resolved, 3 task_log groups consolidated into knowledge, 7 old entries archived. Total: 142 active memories across 6 scopes.

What I Would Do Differently

No project survives contact with production unchanged. Here is what I learned.

The classification cascade was over-engineered early on. I built a two-layer classifier (keyword rules + LLM fallback) before I had enough data to know which memory types actually mattered. In practice, the keyword layer catches about 70% of cases and the remaining 30% default to task_log until maintenance reclassifies them. If I started over, I would ship with keywords-only and add the LLM layer only after accumulating a month of production data.

Scope granularity hit a sweet spot. I initially considered per-message scoping, which would have been too fine-grained. The 4-scope model (global / group / dm / agent) turned out to be exactly right. Every memory naturally fits one of these, and I have never needed a fifth scope.

The write queue was a late addition that saved me multiple times. I did not plan for Qdrant downtime when I started. The first time Qdrant crashed during a conversation, memories were silently lost. Adding the JSONL write queue with replay-on-next-write was a 30-line change that made the system genuinely resilient. Build your degradation path early.

Real-time LLM extraction is a trap for multi-agent systems. Every article about Mem0 shows the infer=True default, where the LLM enriches memories on write. That works for a single-user chatbot. With 8 agents generating memories throughout the day, those 5-8 second writes would have serialized everything. The hot/cold split was the right call. If you are building for multiple agents, start with infer=False.

What surprised me most: how quickly semantic search quality improves once you add scope filtering. Without scopes, searching "deployment process" returns a mix of devops procedures and content publishing workflows. With scope, the results are precise and relevant immediately. Scoping is not just an access control feature; it is a search quality feature.

Getting Started

The full source is at github.com/lofder/smart-memory-gateway. It runs as a standard MCP server -- plug it into any MCP-compatible framework.

If you want to see a real-world consumer of this memory system, check out my dropshipping product import MCP server, which queries memory for supplier preferences and pricing rules every time it processes a product.

The stack is intentionally simple: Python + FastMCP + Mem0 + Qdrant. No Kubernetes. No microservices. Just a single-process MCP server that starts with python src/server.py and a Qdrant instance you can run from a single binary.

Your agents do not have to start every conversation from scratch. Give them memory. They will thank you -- and more importantly, your users will stop repeating themselves.

I Built an MCP Server to Automate Dropshipping Product Imports

lofder.issac — Mon, 23 Mar 2026 06:38:33 +0000

I Built an MCP Server to Automate Dropshipping Product Imports

TL;DR: dsers-mcp-product is a free, open-source MCP server (TypeScript) that automates dropshipping product imports from AliExpress/Alibaba to Shopify & Wix via DSers. 9 tools, 4 workflow prompts, zero-password auth, pre-push safety checks. Install: npx @lofder/dsers-mcp-product login. No coding required.

The Problem That Wouldn't Go Away

I've been running dropshipping stores on and off for a couple of years. If you've done it, you know the drill: find a product on AliExpress or a supplier platform, copy the title, download images, tweak the description, set your margins, push it to your Shopify store. Repeat. Fifty times. Every week.

It's not hard work. It's just tedious work. And tedious work is where mistakes happen — wrong prices, missing variants, broken image links. I tried automating bits of it with scripts, browser extensions, even some Zapier flows. Nothing stuck. The workflows were too fragmented.

Then MCP happened.

If you haven't been following, the Model Context Protocol is Anthropic's open standard for connecting AI models to external tools and data. When I first read the spec, I had one of those "wait, this is exactly what I need" moments. Instead of building a full app with a UI, authentication flows, and all that overhead, I could build a tool server that any MCP-compatible client (Claude Desktop, Cursor, etc.) could talk to.

So I built dsers-mcp-product — an MCP server that handles the entire product import pipeline for DSers, from discovering products to pushing them to your connected stores.

Why MCP and Not Just a REST API?

Fair question. I could have built a CLI tool or a REST service. But MCP gives you something those don't: conversational orchestration.

With a traditional API, you write the glue code. You decide the order of operations, handle edge cases in your scripts, build retry logic. With MCP, the AI client becomes your orchestrator. You tell Claude "import this product and push it to my US store with a 2.5x markup" and it figures out which tools to call, in what order, and handles the back-and-forth.

That's not a gimmick. For a workflow that has real branching logic (what if the product has 47 variants? what if some images fail to load? what if the store has listing rules that reject certain categories?), having an intelligent orchestrator is genuinely useful.

The Architecture

The server is built in TypeScript using the official MCP SDK. Here's the high-level picture:

Claude / Cursor / Any MCP Client
        │
        ▼
┌─────────────────────────┐
│   dsers-mcp-product     │
│   (MCP Server)          │
│                         │
│  ┌─────────┐            │
│  │  Tools  │ ← 9 tools  │
│  └─────────┘            │
│  ┌─────────┐            │
│  │ Prompts │ ← 4 prompts│
│  └─────────┘            │
│                         │
│  Transport: stdio/SSE   │
└────────────┬────────────┘
             │
             ▼
       DSers Platform

Nothing fancy. stdio transport for local clients like Claude Desktop, SSE for remote/web integrations. The server itself is stateless per-request — all state lives on the DSers side.

I went with TypeScript because the MCP SDK has first-class TS support and because I wanted strong typing for the tool schemas. When you're defining tool parameters that an AI model will be calling, you really want those schemas to be precise. Vague schemas lead to vague tool calls.

The 9 Tools

Each tool maps to a distinct step in the product import workflow. I spent a lot of time thinking about granularity here — too few tools and each one becomes a god function with too many parameters; too many and the AI wastes tokens figuring out which to use.

Here's what I landed on:

product.import

The core tool. Takes a product URL or identifier and imports it into your DSers workspace. This handles fetching product data, images, variants, and specs. The heavy lifting.

product.preview

Returns a structured preview of an imported product — title, price, images, variant matrix. This exists because I wanted the AI to be able to "look" at a product before deciding what to do with it. It's the equivalent of a human opening the product page and scanning it.

product.update_rules

Incrementally edits pricing, content, image, or variant rules on a product that's already been imported. Before this existed, changing one rule meant re-importing the entire product. Now the AI can say "change the markup from 2x to 3x" without touching anything else. This was one of the most requested improvements — it makes the edit-then-push loop much tighter.

product.visibility

Controls which variants and options are visible/active. Dropshipping products often come with 30+ variants and you only want to list 5-6. This tool lets you toggle visibility without deleting anything.

product.delete

Removes a product from the DSers import list entirely. This is irreversible, so the tool requires explicit confirmation before proceeding. Useful for cleaning up test imports or products you've decided not to list.

store.discover

Lists your connected stores with their status and capabilities. Before pushing a product, the AI needs to know where it can push to and what each store supports.

store.push

Pushes a product to one or more connected stores. This is where pricing rules, category mapping, and store-specific formatting happen.

rules.validate

Validates a product against a store's listing rules before pushing. Does the title exceed the character limit? Are all required fields populated? Are the images the right dimensions? Better to catch this upfront than get a rejection.

job.status

Some operations (especially bulk imports) are async. This tool checks the status of running jobs. Simple but necessary.

Why This Split?

The key insight was separating read operations from write operations. product.preview, store.discover, rules.validate, and job.status are all read-only. The AI can call them freely to gather information and make decisions. product.import, product.update_rules, product.visibility, product.delete, and store.push are the write operations that actually change state.

This matters because MCP clients can implement approval flows for write operations. You might want the AI to auto-discover and preview products but require your confirmation before actually importing or pushing.

The 4 Prompts

MCP prompts are pre-built conversation templates. Think of them as recipes that encode common workflows:

quick-import — Single product, single store. The "I just want this product in my store" flow. Calls import → preview → validate → push in sequence.

bulk-import — Multiple products from a search or category. Handles pagination, deduplication, and batch status tracking.

multi-push — One product to multiple stores with per-store pricing and customization. Useful when you run stores in different markets.

seo-optimize — Import a product, then let the AI rewrite the title and description for better search rankings before pushing. For sellers who want search-optimized listings without manual copywriting.

These aren't magic. They're just well-structured prompt templates that guide the AI to use the tools in the right order. But they save a ton of back-and-forth compared to starting from scratch every time.

Publishing to 8 Platforms (and What I Learned)

Building the server took about two weeks of evenings. Publishing it took... also about two weeks. That surprised me.

Here's where dsers-mcp-product is listed now:

npm — The obvious first step. npx @lofder/dsers-mcp-product just works. Getting the package.json right for an MCP server that supports both stdio and SSE took some fiddling.

MCP Registry — Anthropic's official directory. Straightforward submission, but you need good documentation. They actually review what you submit.

Smithery — Probably the most developer-friendly MCP directory right now. Their submission process is smooth and they have nice testing tools.

Glama — This one has an automated quality scoring system. dsers-mcp-product scored AAA, which I'm pretty proud of. Their criteria push you to have good error handling, proper schema definitions, and comprehensive tool descriptions.

mcp.so — Community-driven directory. Quick to list, good for visibility.

mcpservers.org — Another community directory. Similar process.

punkpeye/awesome-mcp-servers — The canonical awesome-list for MCP servers on GitHub. Opened a PR, got merged. The maintainers are responsive.

Product Hunt — Listed as Dropshipping MCP DSers. Another channel for discoverability outside the developer bubble.

What I Wish I Knew Before Publishing

Documentation is everything. Each platform wants slightly different things. Some want a README focused on installation, others want use-case examples, others want GIFs showing it in action. I ended up writing three different versions of the docs.

Schema quality matters more than you think. Glama's AAA rating pushed me to tighten up every tool's input/output schema. Better descriptions, stricter validation, more helpful error messages. This wasn't busywork — it directly improved how well AI clients used the tools.

The npm package name matters. I went with @lofder/dsers-mcp-product under my scope. If I could redo it, I'd think harder about discoverability. People search for "mcp dropshipping" or "dsers mcp", not my username.

Cross-platform testing is a time sink. Claude Desktop on macOS, Cursor, and various web-based MCP clients all have slightly different behaviors. stdio transport works everywhere but SSE had quirks in some clients. Budget time for this.

What Actually Changed in My Workflow

Before this project, importing 20 products and pushing them to two stores was a full evening's work. Now it's a conversation:

"Import the top 5 products from [category], skip anything under 4 stars, apply 2.5x markup for the US store and 3x for the EU store, and push them."

Claude calls the tools, shows me previews, validates against store rules, and pushes. I review and approve. The whole thing takes maybe 15 minutes, and I'm mostly just reading summaries and saying "yes."

Is it perfect? No. Sometimes the AI picks weird variants to feature. Sometimes the pricing logic needs a nudge. But it's a 10x improvement over clicking through web UIs.

What's new in v1.3

Since the initial launch, a few things changed significantly:

Zero-password authentication. The old setup required putting your DSers email and password in a config file. That always felt wrong. Now you run npx @lofder/dsers-mcp-product login — your browser opens the official DSers website, you log in there directly, and the tool picks up the session automatically. Your password never touches the MCP server. This alone made me much more comfortable recommending the tool to others.

Incremental rule editing. Before v1.3, changing a pricing rule meant re-importing the product from scratch. Now product.update_rules lets you tweak rules on an already-imported product — change the markup, adjust the title prefix, swap out images — without losing any work.

Pre-push safety checks. The server now automatically blocks pushes that would result in below-cost pricing, zero sell price, or all-variants-out-of-stock. It also detects conflicts between MCP pricing rules and your DSers store-level pricing rules, and tells you exactly how to resolve them.

Takeaways for MCP Server Builders

If you're thinking about building an MCP server, here's what I'd tell you:

Start with the workflow, not the API. Map out what a human actually does, step by step. That's your tool list.

Separate reads from writes. Let the AI gather info freely but gate mutations behind explicit tools.

Invest in tool descriptions. The model reads them to decide which tool to call. Vague descriptions → wrong tool calls → bad UX.

Ship to multiple directories early. Each platform has different audiences. Glama's scoring system alone made my server better.

TypeScript + the official SDK is the path of least resistance. It works. Don't fight it.

The code is open source at github.com/lofder/dsers-mcp-product. If you're in the dropshipping space and want to try it, npx @lofder/dsers-mcp-product login gets you set up in 30 seconds. Issues and PRs welcome.

And if you're building MCP servers for other e-commerce workflows, I'd genuinely love to hear about it. This ecosystem is still early and there's a lot of low-hanging fruit.

Looking for a hands-on setup guide? I wrote a step-by-step tutorial for store owners who want to get started without reading code: How to Automate AliExpress to Shopify Product Import with AI

Find me on GitHub or my blog.