Skip to main content
Glama

SKU-level Supplier Replacement

dsers_sku_remap
DestructiveIdempotent

Replace supplier for dropshipping products using SKU-level variant matching. Use strict mode with a specific URL or discover mode with reverse-image search to find alternatives when suppliers are out-of-stock.

Instructions

Replace the supplier on a store product with SKU-level variant matching. DEFAULTS TO mode='preview' which is read-only and safe to call without confirmation — only mode='apply' actually writes to DSers. TWO discovery paths: (A) STRICT — caller provides new_supplier_url and the tool swaps to that exact supplier; (B) DISCOVER — omit new_supplier_url and the tool reverse-image-searches the DSers pool using seed images from the current product, ranks candidates via sku-matcher + multi-factor scoring, and auto-picks the best replacement. Use discover mode when the current supplier is broken/out-of-stock and you don't have a specific replacement URL in hand. WORKFLOW: (1) Call with mode='preview' to see the match plan, scoreBreakdown, tier-isolated top_candidates and the planned pool[] history additions — nothing is written. (2) Review the diffs, then call again with mode='apply' and the same params to persist. auto_confidence threshold defaults to 70 (conservative). Lower at your own risk — DSers does NOT validate supplier payload correctness; data errors only surface at order fulfillment time. Returns: path (A_strict or B_discover), summary (swapped/kept_old/unmatched/skipped counts), mapping_type, diffs (per-variant decision + before/after), discovery.top_candidates (discover mode only), pool_additions (PoolEntry[] that apply will append to mapping.pool[] as history), warnings, errors. When applied: also returns process_status from DSers post-write polling. Requires the product:mapping OAuth scope. Get store_id from dsers_store_discover first.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dsers_product_idYesDSers product ID of the store product whose supplier you want to replace. Get from dsers_my_products. Must be a numeric string that fits in a signed int64 (max 9223372036854775807) — the schema's maxLength:19 + numeric pattern allow up to 19 digits but values above the int64 ceiling are rejected at the MCP boundary.
new_supplier_urlNoOPTIONAL. AliExpress / Alibaba / 1688 URL of the replacement supplier. Provide to use STRICT mode (exact swap). Omit to use DISCOVER mode (reverse-image search to auto-find the best replacement). Must be a valid http/https URL — plain text / non-URL strings are rejected at the MCP boundary. URL scheme is normalized to lowercase (HTTPS:// → https://) per RFC 3986 before the candidate fetch.
store_idYesStore ID from dsers_store_discover. Required. Must be a string (DSers backend rejects integer storeId due to int64 precision). Must be a numeric string that fits in a signed int64 (max 9223372036854775807) — the schema's maxLength:19 + numeric pattern allow up to 19 digits but values above the int64 ceiling are rejected at the MCP boundary.
modeNopreview (default — read-only, no DSers writes, safe to call repeatedly) or apply (persist the swap; verify diffs in preview first).preview
countryNoTarget country code for candidate fetch. Default US.US
auto_confidenceNoMinimum sku-matcher confidence (0-100) for a variant to be auto-swapped. Default 70.
max_candidatesNoDISCOVER mode only. Max candidates to fetch full variant detail for and rank. Default 5. Ignored in STRICT mode.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeYes
dsers_product_idYes
source_urlYes
mapping_typeYes
pathYes
degradedNo
summaryYes
diffsYes
discoveryNo
pool_additionsYes
warningsYes
errorsYes
appliedNo
process_statusNo
process_errmsgNo
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds substantial behavioral context beyond annotations: it explains the default safe mode ('preview'), the two discovery paths (STRICT vs DISCOVER), the workflow sequence, the auto_confidence threshold implications ('DSers does NOT validate supplier payload correctness; data errors only surface at order fulfillment time'), and OAuth scope requirements. While annotations cover basic hints, the description provides rich operational details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is information-dense but well-structured with clear sections (DEFAULTS, discovery paths, WORKFLOW, Returns, requirements). Every sentence adds value, though the length pushes it toward comprehensive rather than concise. The front-loaded safety warning about mode='preview' is particularly effective.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (7 parameters, destructive operation, multiple modes) and the presence of both annotations and output schema, the description provides excellent completeness. It covers the operational workflow, safety considerations, mode differences, practical usage scenarios, and OAuth requirements. The output schema handles return values, so the description appropriately focuses on behavioral context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the baseline is 3. The description adds meaningful context about parameter interactions: it explains how 'new_supplier_url' determines the mode (STRICT when provided, DISCOVER when omitted), clarifies that 'max_candidates' is DISCOVER-mode only, and provides practical guidance about 'auto_confidence' thresholds. However, it doesn't add syntax or format details beyond what the schema already documents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the verb ('Replace') and resource ('supplier on a store product') with specific scope ('SKU-level variant matching'). It clearly distinguishes this tool from siblings by focusing on supplier replacement rather than product discovery, import, deletion, or rule management.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use each mode: 'preview' for safe read-only analysis and 'apply' for actual writes. It also distinguishes between STRICT mode (when you have a specific supplier URL) and DISCOVER mode (when the current supplier is broken/out-of-stock and you need auto-discovery). The workflow section gives clear step-by-step instructions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/lofder/dsers-mcp-product'

If you have feedback or need assistance with the MCP directory API, please join our Discord server