DSers Official MCP Server

Name: DSers Official MCP Server
Author: dsers

The DSers Official MCP Server is a hosted remote Model Context Protocol server that allows MCP-compatible AI clients to work with DSers dropshipping workflows, including product import, product optimization, variant editing, pricing rules, store publishing to Shopify, Wix, and WooCommerce, and supplier replacement.

该来源不提供完整文件导出（国内平台多为平台内托管），仅存元数据与原链

接入信息

传输形态: http
鉴权方式: 鉴权未知
端点: https://dsers-mcp-server.run.tools

鉴权方式未标注，请核对官方文档后再接入——不要直接使用以下片段

{
  "mcpServers": {
    "DSers Official MCP Server": {
      "url": "https://dsers-mcp-server.run.tools"
    }
  }
}

能力清单

工具	说明
apply_ai_mapping	\[Store Products\] \[What it does\] Applies one already-completed and user-confirmed AI Mapping task result to a product's live supplier variant mapping used for future fulfillment. \[When to use\] Use after an AI Mapping task has succeeded and the user has reviewed and confirmed the final product/supplier preview, to commit that result. \[When not to use\] To search AI Mapping candidates or create the mapping task, use the corresponding candidate-search or create tools. Never call this on an unconfirmed or still-running task. \[How to use\] `task_id` is required and must belong to the current account with status ProgressSuccess. The tool rechecks task ownership and status immediately before writing; if already applied, it returns without re-writing. The write is sent once — if the outcome is unknown, re-check with `get_job_status`/`get_store_product_mapping` rather than retrying. \[Side effects\] Changes the product's live supplier mapping used for future order fulfillment. \[Confirmation\] Required, never skippable: show the exact product/supplier/task preview and get an explicit second confirmation before calling.
apply_product_mapping	\[Store Products\] \[What it does\] Applies a variant-to-supplier mapping that has already been decided and confirmed by any process (manual selection, AI Mapping, or another flow) as the official supply relationship for one DSers-managed product, replacing its current mapping state. \[When to use\] Use when the user wants a confirmed SKU mapping or AI Mapping result saved as the final supplier relationship. Trigger words: apply mapping, save SKU mapping, commit AI Mapping. \[When not to use\] This tool never searches for mapping candidates or generates AI Mapping suggestions; use the dedicated candidate-search or AI Mapping tools for that. Never pass an unconfirmed AI suggestion directly into this tool. \[How to use\] - `dsers_product_id` is required, taken from the latest Mapping read. - `mapping` may be a complete update (every current sales variant) or a partial update (only changed variants); partial updates preserve unsubmitted variants, while complete updates drop unlisted old variants and pool candidates. - Each `sales_product_variant_id` may appear only once; `mappings=[]` intentionally unmaps that variant. - The Mapping pool is rebuilt internally from the latest saved state, final variant mappings, and supplier details. Callers do not submit `pool`; partial updates preserve current candidates, while complete updates retain only products needed by the final mapping. - `product_mapping_type` is required and represents the overall final mapping type. - This write is not idempotent and is sent once; success only means it was accepted, so re-read the Mapping detail to verify persistence, and never auto-retry on an unclear outcome. \[Side effects\] Changes the product's supplier variant mapping, affecting future supply, pricing, and order fulfillment. \[Confirmation\] Required, never skippable: show the exact product, variants, and the old-to-new supplier mapping changes first.
cancel_supplier_order	\[Order\] \[What it does\] Requests asynchronous supplier-side cancellation for one DSers order that is in `awaiting_payment` status; only one order per call. \[When to use\] Use when the user explicitly wants to stop a specific order whose latest confirmed status is `awaiting_payment`. \[When not to use\] If status is unknown, check it with `get_order` first; do not call this for an order in any other status. \[How to use\] Supply exactly one `dsers_order_id` from `list_orders`, verified via `get_order`. Omit `supplier_platform_id` only when exactly one supplier is eligible. A successful response contains only `message`: it means DSers acknowledged the asynchronous request, not that cancellation completed. Completion is confirmed only by a later `get_order` showing the cancelled status. Dispatch once; never auto-retry — re-read order state if the outcome is unclear. \[Side effects\] May cancel the order's supplier orders; destructive and critical-risk. \[Confirmation\] Requires explicit, non-skippable user confirmation; show the exact order and supplier first. \[Follow-up\] After acknowledgement, verify cancellation with `get_order`; if rejected, report the reason and stop.
create_order_payment_link	\[Order\] \[What it does\] Generates authenticated DSers Checkout links for awaiting-payment orders, returning one amount and link per supplier payment group. It never charges the user or completes payment. \[When to use\] Use it when the user wants to pay specific awaiting-payment orders, and when the agent needs to hand the user a payment entry point for orders already in that state. Trigger words: pay these orders, create a payment link, settle this batch. \[When not to use\] To find awaiting-payment orders, use `list_orders`. To place orders with suppliers, use `place_orders_to_suppliers`. It cannot pay on the user's behalf. \[How to use\] - `supplier_platform_id` and `selection_mode` are required. Selected mode needs exact order IDs, up to 100; filtered mode covers every order matching the filters, which is usually far broader than the user expects, so confirm the scope first. - AliExpress and Alibaba.com merge selected or filtered matches into one direct checkout URL and return those `dsers_order_ids`. Filtered mode is capped at 100 matching orders; more than 100 is rejected. - The non-AliExpress path creates a persistent payment-link record and is not idempotent, so never recreate an uncertain link; verify through the order list or the Payment Link page instead. - Judge each group separately: only links flagged checkout-ready are usable, while failed, skipped, unknown, and partial outcomes are not success and must be reported individually. - Amounts are returned as strings in the currency's smallest unit and must be converted before display. The user has to open the link to pay, and payment status must be confirmed later from the order data. \[Side effects\] No charge; non-AliExpress groups create payment-link records. \[Confirmation\] Required but skippable; show order scope and amounts first.
create_pre_publish_products	\[Import List Product\] \[What it does\] Turns supplier products into editable pre-publish products (the items on the DSers Import List page), up to 20 per call. \[When to use\] Use it when the user has picked products to import, and whenever the agent needs pre-publish products to exist before editing or publishing them. Trigger words: import this product, add to import list, save it for editing, bulk import. \[When not to use\] To edit an imported product, use `update_pre_publish_product_content`. For prices, use `update_pre_publish_product_price`. To list products in a store, use `publish_products_to_stores`. \[How to use\] - `supplier_platform_id` and `supplier_product_id` must come from the same `search_supplier_products` result. Use the top-level fields for one product or `items` for 2 to 20; never mix the two modes. - `languages` is merged with the account's Product Settings languages and saved back: English is always included and counts toward the plan's language limit, and that settings change persists even if the import later fails. - When `country` is omitted the previously selected import country applies, falling back to US; if the setting cannot be read the call stops without writing anything. - Read `imported_items` and `failed_items` item by item because a batch can partially succeed. A successful single-product request also returns the top-level `import_item_id`. Failed items include their supplier IDs, reason, and when plan-limited, `code`, `checkout_scene`, `name`, and the database-provided `message`. - Do not auto-retry failures; check the reason first, such as a product that already has a pre-publish record. If the outcome is unclear, verify with `list_pre_publish_products` instead of resending. - Import List products, draft products, and pre-publish products are the same objects; when users use the old menu wording, proceed normally and answer in generic product terms rather than sending them to a page. \[Side effects\] Creates pre-publish products and may change account language settings. \[Confirmation\] Required but skippable; disclose the language-setting change.
delete_pre_publish_products	\[Import List Product\] \[What it does\] Permanently deletes 1-20 exact Import List products by `import_item_id`; it never selects products by keyword or filter. \[When to use\] Call after the user reviews and selects exact products with `list_pre_publish_products` to remove; trigger words: delete import list product, clean up import list, remove pre-publish products. \[When not to use\] To find or narrow removal candidates, use `list_pre_publish_products` first. This tool does not remove products already published to a store. \[How to use\] Pass 1-20 exact `import_item_ids` copied from `list_pre_publish_products`. A successful response returns only the normalized `import_item_ids` submitted after Product BFF accepts the delete call; it does not provide per-item outcomes. If the outcome is unclear, re-check with `list_pre_publish_products` instead of retrying the delete. \[Side effects\] Permanently removes products from the Import List; irreversible. Dispatch once. \[Confirmation\] Requires user confirmation, skippable per policy; show the exact products before calling. \[Follow-up\] If the outcome is unclear, verify which products remain with `list_pre_publish_products`.
diagnose_order_issue	\[Order\] \[What it does\] Read-only diagnosis of why DSers orders cannot be placed, paid, or fulfilled; reports per-dimension pass/fail results and resolutions. \[When to use\] Use when the user asks why an order is failing, or to check readiness before placing it with the supplier. Call this before `place_orders_to_suppliers` / placement to understand and resolve blockers. \[When not to use\] To actually place an allowed order, use the placement tool; this tool never places orders or edits data. \[How to use\] Exact `dsers_order_ids` mode and search-filter mode are mutually exclusive; both modes require `supplier_platform_id`, and search mode evaluates one page of up to 100 orders matching filters, and defaults omitted `status` to `awaiting_order` (`all` is rejected). In exact mode, `supplier_platform_id` limits evaluation scope to that supplier. Only `decision=allowed` with `complete=true` conclusively permits placement — `unknown` or `incomplete` remains inconclusive even without a reported blocker. Dimensions whose checks are unavailable are reported in `missing_checks`, not treated as passing. In exact `dsers_order_ids` mode, `fulfillable_item_ids` contains the supplier-orderable item IDs within the selected `supplier_platform_id` scope; seller-platform Fulfill restrictions are excluded from this supplier-ordering result. The supplier order-and-payment disable switch is evaluated per `supplier_platform_id`. `CANNOT_ORDER_WITHOUT_SKU` is evaluated for supplier apps that have unquoted items; a confirmed restriction is `UNQUOTED_ORDER`. `AWAITING_ORDER_ITEM_PRODUCT_EMPTY_CANNOT_ORDER` is evaluated for supplier apps that have zero-quantity items; a confirmed restriction is `ZERO_FULFILLABLE_QUANTITY`. `MAX_CHAR_LEAVE_A_MESSAGE_TO_SUPPLIER` is evaluated for supplier apps that have items with messages over 1000 characters; a confirmed restriction is `SUPPLIER_MESSAGE_TOO_LONG`. `AWAITING_PAYMENT_MAKE_PAYMENT_BTN_DO_NOTHING` is evaluated for all relevant supplier apps on awaiting-payment orders with zero cost; a confirmed restriction is `AWAITING_PAYMENT_ZERO_COST`. Other platform-dependent checks that cannot be evaluated stay in `missing_checks`. \[Side effects\] Read-only; no order data changes. \[Confirmation\] Required per current configuration and not skippable. \[Follow-up\] If conclusively allowed and placement is the goal, proceed to the placement tool per its own confirmation rules; otherwise report the blocker or missing check and stop.
find_feature_entry	\[Fallback\] \[What it does\] Searches the DSers feature catalog by English intent keywords only after confirming no existing DSers tool can complete the request; returns anchored page destinations without performing any business action. \[When to use\] Call only after verifying every other DSers tool cannot fulfill the request and a page entry point is needed; trigger words: feature entry, where to set up, no tool covers this, navigate to a feature. \[When not to use\] Do not use for product, order, or store queries that have dedicated tools (e.g. get_order, list_stores); this tool never substitutes for a business action. \[How to use\] Pass specific English intent keywords as `query`; at most 10 destinations are returned. An empty `matches` list is a valid result meaning no fallback destination exists. `truncated=true` means more matches exist beyond the limit — narrow the keywords or raise `limit`. \[Side effects\] Read-only; no data is changed. \[Confirmation\] No confirmation required. \[Follow-up\] If a match fits, explain the destination and ask whether to open its URL; if none fits, report there is no suitable destination and stop.
get_account_profile	\[Account\] \[What it does\] Reads the signed-in DSers account's identity, permissions, visible subaccounts, and account settings such as timezone. \[When to use\] Call it when the user asks about account identity, registration, permissions, or subaccounts. Call it proactively before product, order, or store actions that need a permission check, or before resolving relative dates such as "today" or "this week", which need the account timezone. Trigger words: account, registration, subaccount / staff, permission, timezone. \[When not to use\] For the current subscription or plan benefits use `get_plan_and_credits`; for subscription billing history or invoices use `get_plan_and_credit_billing`. It cannot read accounts outside your own account tree, and never modifies permissions or subaccounts. \[How to use\] - Empty values carry meaning: an empty subaccount list means it is not visible to the current identity, and an empty menu list means a main account with full access; neither means "none". - Convert every time to the account timezone: returned times are UTC, and the response timestamp marks data freshness only, not registration, login, or last-modified time. - Partial gaps are not failures: when optional parts are missing, the rest is still reliable, so note what is missing instead of retrying or erroring out. - Do not surface raw data: the email address is never returned, only its verification status; store permissions are store IDs, so look up names separately. \[Side effects\] Read-only. No account data or permission is changed. \[Confirmation\] None required, the tool is read-only.
get_job_status	\[SystemInternal\] \[What it does\] Reads the latest status of one asynchronous task created by a DSers business write tool, using the exact `task_type` and `task_id` returned by that creating tool. \[When to use\] Use when the user asks whether an earlier async action (import, bulk price sync, AI mapping, supplier order sync, product push) has finished or what stage it is at. \[When not to use\] Never use this to create, cancel, or rerun a task; it is read-only status only. Legacy `job_id` queries are not supported, and only one task can be queried per call. \[How to use\] `task_type` and `task_id` are required and must be copied exactly from the creating tool's result; `delay_seconds` is optional (default 3, max 20). `terminal=true` only means polling can stop; still check `status` and `error` to distinguish success, failure, cancelled, expired, or unknown completion. When `status=unknown` or `error.code=UPSTREAM_UNKNOWN`, never auto-retry the original write; check the actual business entity instead. Only `ai_mapping`, `product_push`, `product_price_sync`, and `supply_order_sync` actively refresh upstream state; `product_stock_sync` only confirms receipt. The current or final task-specific business outcome is carried in `result`. For `task_type=order_process`, copy `task_id` from `place_orders_to_suppliers` (the place-order task ID). `status=running` while pending work remains; `succeeded` when pending is zero and failed is zero, including all-zero counts; `failed` when pending is zero and failed is non-zero. The four counts are in `result`. \[Side effects\] None; read-only and never creates, cancels, or retries any business write. \[Confirmation\] Not required.
get_managed_store_product	\[Store Products\] \[What it does\] Reads one DSers-managed Sales Product's options and variants, mapped Supplier Products, primary and secondary supplier-variant mappings, effective supplier inventory, blacklist state, sales-channel deletion state, and sync settings. \[When to use\] Use it when the user asks about one managed product's variants, inventory, pricing, mapped supplier products, or sync state, and when exact IDs are needed before a price, stock, mapping, or supplier-detail operation. \[When not to use\] To find, filter, or count products, use `list_managed_store_products`. For mapped Supplier Product content or shipping data, call `get_supplier_product` with the paired IDs from `mapped_supplier_product_list`. \[How to use\] - Copy `dsers_product_id` from `list_managed_store_products` `items[].dsers_product_id`; it is not a Sales Product or Supplier Product ID. - `include_sales_product_description` defaults to false, so `sales_product_description` is omitted unless explicitly requested because descriptions can be large. - Each `mapped_supplier_product_list[]` entry provides the `supplier_platform_id` and `supplier_product_id` pair required by `get_supplier_product`. - `primary_supplier_product_variant_mapping_list` contains the default Basic Mapping supplier or the single supplier Product BFF can resolve for that sales variant. `secondary_supplier_product_variant_mapping_list` contains the non-default supplier returned only for Basic Mapping. - `supplier_product_variant_display_price_amount` is converted toward the DSers store default currency; always read it with `supplier_product_variant_display_price_currency` because Product BFF falls back to the supplier currency if conversion fails. - `sales_product_variant_effective_supplier_inventory_list[].sales_product_variant_effective_supplier_inventory_quantity` is Product BFF's final display inventory for the sales variant: primary stock first, but secondary stock is used when primary stock is zero or missing. It is not sales-channel inventory and cannot be attributed to one fixed Supplier Variant. - `mapped_supplier_product_count` of 0 means no mapped supplier summary was returned. `sales_product_is_blacklisted_in_dsers` comes from Product BFF `is_unable`; it is distinct from deletion on the sales channel. \[Side effects\] None; read-only. \[Confirmation\] Not required.
get_order	\[Order\] \[What it does\] Reads one normalized rich DSers order record: line items, costs and income, supplier rows, tracking numbers, and a privacy-minimized destination summary. \[When to use\] Use it when the user asks about a specific order, and whenever the agent needs row-level IDs and current status before editing, placing, or fulfilling that order. Trigger words: this order's detail, its supplier order, what happened with this order. \[When not to use\] To find orders or see pending volume, use `list_orders`. To place orders, use `place_orders_to_suppliers`. For package movement, use `get_package_details`. It changes nothing. \[How to use\] - `dsers_order_id` is required and must be the DSers internal order ID from `list_orders`; a storefront or supplier order number cannot be passed directly. - The Tool performs one rich-order lookup in the supplied supplier and tab scope. It returns that normalized detail or an error such as `NOT_FOUND`; it does not return a degraded summary. Treat omitted optional fields as unavailable, not as zero. - `supplier_platform_id` and `tab_status` stay required. Copy them from the same `list_orders` request when that call included them. When `list_orders` omitted `supplier_platform_id` or `status`, copy the omitted field from the same `line_items[]` row being inspected. Mixed `tab_statuses`: pick the tab matching the user intent, else the first known value. Do not invent pairs. If `tab_statuses` is empty, do not call this Tool; re-list with an explicit `status`. - `items[].tab_statuses` lists only the known memberships for that item. `items[].mixed_tab_status=true` means more than one known tab; false does not prove completeness. - Money uses different bases: income is authoritative in the seller-platform currency, the setting-currency figure may appear only as a labeled conversion, and item prices and supplier costs use the DSers default currency, so never mix them. - The address is a privacy-minimized destination summary. An omitted component does not prove the address is complete or placeable; use `diagnose_order_issue` before placement. Product titles must be shown verbatim, never translated or truncated. \[Side effects\] None; read-only. \[Confirmation\] Not required.
get_order_paymentlink_and_billing	\[Order\] \[What it does\] Searches authenticated-account order checkout Billing records only; it does not cover subscription or one-time-purchase billing. \[When to use\] Use when the user needs to look up order-related payment or billing records, such as checking the billing status tied to an order. \[When not to use\] For subscription billing or invoices, use `get_plan_and_credit_billing`. This tool never creates a payment link; use the payment-flow-start tool for that. When `related_kind=pbl`, `related_id` is a PBL ID and must never be passed to `get_order` as `dsers_order_id`. \[How to use\] `billing_id` gives an optional exact lookup (skips the default time window); otherwise `start_time`/`end_time` default to the latest 30 days. `platforms`, `statuses`, and `supplier_platform_id` are optional filters; copy `supplier_platform_id` from `list_stores`. Paginate with `page_number`. \[Side effects\] None; read-only, never creates or modifies any record. \[Confirmation\] No confirmation required; this tool is read-only and never creates or modifies any record.
get_package_details	\[Tracking / Logistics\] \[What it does\] Reads the logistics status, attention flag, and carrier event snapshot that DSers holds for one tracking number on the authenticated account. \[When to use\] Use it when the user asks where a shipment is or why it has stalled, and whenever the agent needs event evidence before handling a delivery exception or replying to a buyer. Trigger words: where is my package, check this tracking number, delivery exception, when will it arrive. \[When not to use\] It looks up tracking numbers only and cannot return every package on an order; get the tracking number from `get_order` first. To write a tracking number back to a store order, use `update_store_order_tracking_number`. External numbers outside this account cannot be queried. \[How to use\] - `tracking_number` is required and must belong to this account; a number supplied by a buyer cannot be looked up directly. - Events keep the upstream order, which is not necessarily newest first, so never assume the first entry is the latest checkpoint. - Event times use the carrier's own format; a normalized timestamp and timezone appear only when available, so confirm the timezone before comparing times. - An empty event list is a valid result meaning no scans yet; it does not prove the parcel is unshipped or lost. Estimated delivery is not returned and must not be inferred. - The data is a stored DSers snapshot that can lag the carrier site. The attention flag is only a marker, not a confirmed exception. \[Side effects\] None; read-only. \[Confirmation\] Not required.
get_plan_and_credit_billing	\[Subscribe\] \[What it does\] Returns exactly one billing result selected by `billing_kind`: `subscription_billing` (paid recurring and one-time subscription purchase records) or `invoice_download` (one invoice download URL). \[When to use\] Use when the user wants to see subscription payment history or download an invoice. \[When not to use\] For the current plan and benefits, use `get_plan_and_credits`. For order-level billing, use `get_order_paymentlink_and_billing`. AI Credits usage history is currently unavailable through this Tool. This Tool never creates a payment or changes a subscription. \[How to use\] `billing_kind` is required and selects exactly one mode per call. `subscription_billing` uses `start_time`/`end_time`/`billing_id`/`sort_by`/pagination; `invoice_download` uses only `billing_id` and `invoice_id`. `subscription_billing` is server-fixed to paid DSers subscription and one-time-purchase records only. \[Side effects\] None; read-only. \[Confirmation\] Not required.
get_plan_and_credits	\[Subscribe\] \[What it does\] Reads the current account's subscription plan and plan limits/benefits in one call. \[When to use\] Use when the user asks about their current plan or what the plan includes. Trigger words: my plan, plan benefits. \[When not to use\] For identity or permissions, use `get_account_profile`. For billing history or invoices, use `get_plan_and_credit_billing`. This tool currently returns no AI Credits balance, usage history, or billing line items. \[How to use\] No inputs are required; call with an empty object. `benefits` are plan allowances and feature switches, not current usage. `current_subscription` is only the current snapshot, while `active_subscriptions` also includes active one-time plans. All required upstream reads must succeed together; if any fails, the whole call returns a retryable error instead of partial data. \[Side effects\] None; read-only. \[Confirmation\] Not required.
get_pre_publish_product	\[Import List Product\] \[What it does\] Reads the editable snapshot of one pre-publish product — an item on the DSers Import List page: content, images, package details, options, variants, prices, stock, and the `resource_version` writes require. \[When to use\] Use it when the user asks for one pre-publish product's full detail, and whenever the agent must obtain the current version and row identifiers before editing, repricing, or pushing it. Trigger words: this pre-publish product, this item in my import list, its variants, check before editing. \[When not to use\] To find or filter pre-publish products, use `list_pre_publish_products`. For a product already pushed to a store, including Draft status, use `get_managed_store_product`. It changes nothing. \[How to use\] - `import_item_id` is required and comes from `list_pre_publish_products` `items[].import_item_id`. - `include_supplier_product_description` defaults to false, so `supplier_product_description` is omitted unless explicitly requested because descriptions can be large. - `resource_version` is the token for content edits, price edits, and pushes, and it expires after each write; re-read immediately before every write instead of reusing an older value. - `supplier_product_variant_id` and option `supplier_product_option_value_id` can repeat because duplicated rows keep their supplier ID, so always pair them with `variant_index` or `value_index`. - Prices and costs are exact strings; send them back unchanged and never recompute or round them. Currency is reported at item and variant level. - If a write's outcome is unclear, re-read with this tool to confirm the current state rather than retrying the write. - Import List products, draft products, and pre-publish products name the same objects; accept the old wording and answer in generic product terms rather than sending the user to a page. \[Side effects\] None; read-only. \[Confirmation\] Not required.
get_pre_publish_product_organization	\[Import List Product\] \[What it does\] Reads current and available Organization values for pre-publish products — the items on the DSers Import List page — in one target store, plus the version and review tokens later writes require. Organization covers Category, Collection, Type, Tags, and Vendor, and the store defines which values exist. \[When to use\] Use it when the user wants to see or adjust listing categories, tags, or vendor before publishing, and always once per product-store target before a push. Trigger words: category, collection, tags, vendor, check my import list products before publishing. \[When not to use\] For product content and variants, use `get_pre_publish_product`. To save selections, use `update_pre_publish_product_organization`. It changes nothing. \[How to use\] - `import_item_ids` (1 to 100) and `dsers_store_id` are required; send the whole selection at once. Choices are shared, but each product gets its own token. - Choices and tokens are per product-and-store: for a multi-store push, call it once per store and never reuse another store's available values, `review_token`, or `resource_version`. - `review_token` is single-use and expires quickly (see `review_expires_at`); together with `resource_version` it is required to save settings and can never be reused. - When `organizations_truncated` or `categories_truncated` is true the option lists are incomplete; narrow with `organization_name`, `keyword`, or `category_keyword` and re-read instead of treating them as complete. - `categories_supported` false means the platform has no categories, so never invent one. `select_number` 0 means no declared upper limit, not zero selectable, and `is_create` decides whether new values may be created. - Always show the choices to the user; never silently select or create values. A batch read can fail per product, so check each item's failure reason and retryable flag. - Import List products, draft products, and pre-publish products name the same objects; accept the old wording and answer in generic product terms rather than sending the user to a page. \[Side effects\] None; read-only apart from issuing review tokens. \[Confirmation\] Not required.
get_pricing_rule	\[Pricing Rule\] \[What it does\] Reads one owned store's Tool-facing Pricing Settings: the active `mode` (`none`, `basic`, `advanced`, or `ai_custom`), saved Basic, Advanced, and AI Custom bodies, price endings, exchange-rate context, non-blocking `warnings`, and the `resource_version` required by updates. Inactive saved rules are returned only as context. \[When to use\] Use when the user asks for a store's pricing formula, strategy, margins, price endings, or exchange rate, and immediately before every `update_pricing_rule` call. \[When not to use\] To save Pricing Settings, use `update_pricing_rule`. To calculate the price one managed product would receive, use `simulate_pricing_rule`. To change product prices, use the applicable product update Tool; this Tool never reprices products. \[How to use\] - Copy `dsers_store_id` from `list_stores`. Pricing Rules are store-wide; there is no account-wide or per-product rule. - Read `mode` first. Only its matching body is active. For `advanced`, read `formula_mode`: `fixed` uses `fixed_ranges` and `fixed_rest`, while `custom` uses `custom_ranges` and `custom_rest`. Other returned bodies are inactive saved rules and must not be reported as current. - `ai_custom` is separate from Advanced `custom`. Report `ai_custom_rule` only when present and use `ai_custom_formula_for_user` as read-only presentation. - When `needs_initial_rule` is true, the store has only an unsaved default shell. The first rule save needs a complete matching rule body, but cents or currency may still be updated independently. - If `warnings` reports an invalid saved AI Custom formula, show that warning to the user. The invalid `ai_custom_rule` is omitted, while Basic, Advanced, cents, currency, and `resource_version` remain usable. - Basic and Advanced range boundaries are inclusive USD decimal costs on a fixed 0.01 grid. AI Custom explicit monetary fields are USD decimals. Store currency and exchange-rate settings are returned separately and must not be used to reinterpret saved rule values. - Copy `resource_version` unchanged into the next update. After any successful update, discard the old version and read again before another change. \[Side effects\] None; read-only. \[Confirmation\] Not required.
get_push_shipping_recommendation	\[Import List Product\] \[What it does\] Reads publish-ready logistics candidates for each Import List product paired with a connected store, plus that store's current pricing rank. \[When to use\] Use when a merchant asks which shipping methods are available before publishing, or when an Agent needs a valid shipping_method_id for a product-store pair before calling publish_products_to_stores. Trigger words: publish shipping, shipping method, delivery option, logistics for this product, carrier before publish. \[When not to use\] Do not use it to publish a product; use publish_products_to_stores. Do not use it to read the full editable product snapshot; use get_pre_publish_product. Do not use it to view or change category/organization settings; use get_pre_publish_product_organization or update_pre_publish_product_organization. \[How to use\] import_list_ids and dsers_store_ids expand into a unique Cartesian product capped at 100 product-store targets; copy IDs exactly from list_pre_publish_products and the store-discovery Tool. If any requested target is missing, malformed, or hits an upstream error, the entire call fails rather than returning partial results. An empty logistics array is a valid, complete result meaning no candidates exist for that pair, not a failure. Copy the returned service_id verbatim (never infer it from company_name) into publish_products_to_stores; amount is a decimal string in major currency units, not a float. \[Side effects\] None; read-only, changes no shipping or store settings. \[Confirmation\] Not required. \[Follow-up\] If a candidate is chosen, pass its service_id to publish_products_to_stores to complete the publish.
get_store_product_mapping	\[Store Products\] \[What it does\] Reads the MCP-safe saved mapping view for one DSers-managed sales product, including persisted sales-to-supplier variant relationships, destination countries, and seller/supplier option snapshots. It is a projected view, not the complete Product BFF response. \[When to use\] Use when the user wants to inspect the currently exposed mapping relationships or verify them before or after applying changes. \[When not to use\] To search candidate supplier products or generate AI Mapping suggestions, use the corresponding tools; this tool never creates or updates mapping. \[How to use\] Pass `dsers_product_id` alone, or `dsers_store_id` together with `sales_product_id` (never one without the other). Read each `mapping[]` seller variant and its nested `mappings[]` supplier variants; `sales_product_variant_options` and `supplier_product_variant_options` are saved option snapshots, not editable option-map rules. An omitted or empty `mapping` array means nothing is mapped, not a query failure. The response intentionally omits `pool`, seller and supplier prices, currency, supplier ship-from, and internal workflow fields. Use `get_managed_store_product` for current variant prices and `simulate_pricing_rule` for calculated seller prices. \[Side effects\] None; read-only. \[Confirmation\] Not required.
get_supplier_product	\[Supply Product\] \[What it does\] Reads one supplier product's options, variants, stock, prices, shipping origins, and availability status for a given destination and language context. \[When to use\] Use it when the user asks about a specific supplier product's quality, stock, price, or shipping, and when the agent must verify a shortlisted candidate before importing, mapping, or quoting freight. Trigger words: this supplier product, enough stock, ships to, supply cost. \[When not to use\] To find candidates, use `search_supplier_products`. For destination freight costs, use `list_supplier_product_freight_quotes`. For a product already in the store, use `get_managed_store_product`. \[How to use\] - Copy `supplier_platform_id` and `supplier_product_id` from the same search candidate; never use `applications[].app_id` or a DSers-managed product ID. - `include_supplier_product_description` defaults to false, so `supplier_product_description` is omitted unless explicitly requested because descriptions can be large. - Statuses such as `NotShipTo`, `NotLanguage`, `NotDropShipping`, and `NotAvailable` mean unavailable under the requested `country` or `language`, not that the product is missing; retry with another destination before concluding. - `country`, `language`, and `currency` are requested context only and may be unsupported upstream; report the returned values, not the requested ones. - Only `supplier_product_variant_list[].supplier_product_variant_id` is accepted for freight quotes, ordering, and mapping; `stock` of 0 means that variant is out of stock, not that the product is delisted. - Prices are strings and must be read with their currency, which can differ between variant and product level. Quotes exclude shipping, so never treat them as landed cost. \[Side effects\] None; read-only, and it never imports or maps a product. \[Confirmation\] Not required.
import_store_products_to_dsers	\[Store Products\] \[What it does\] Imports one to five selected seller-platform products from one connected store into DSers management; already-managed products are rejected. \[When to use\] Use when the merchant wants DSers to manage products that already exist in that store. \[When not to use\] For products already managed, browse them with `list_managed_store_products` instead of importing again. \[How to use\] Take `dsers_store_id` from `list_stores` and one to five `sales_product_ids` from `search_store_products`. The response is a completion message; this Tool exposes no fulfillment-service option or asynchronous job identifier. \[Side effects\] Creates DSers-managed products for the store; dispatch each import once. \[Confirmation\] Required; skippable per authorization policy. \[Follow-up\] Re-read `list_managed_store_products` if the merchant wants to review the imported products; otherwise report the completion message and stop.
list_featured_product_collections	\[Supply Product\] \[What it does\] Lists curated product collections visible to the account's supplier applications: collection names, descriptions and scene types. Theme entry points only, never product records. \[When to use\] Call it when the merchant gives no category or keyword and asks what to sell, what is recommended, or what is selling well; the agent also calls it first when a supplier product search needs a direction. Trigger words: product ideas, best sellers, what should I sell, curated collections, inspiration. \[When not to use\] With a clear category or keyword, use `search_supplier_products` for products and prices and `get_supplier_product` for one product; use `create_pre_publish_products` to import, and `list_managed_store_products` for the merchant's own listings. \[How to use\] - Collections are editorial placements, not a sales ranking, and the scene type is not a product category: present them as curated themes and use the type for grouping only. - Collection IDs are banner identifiers, not product IDs; never pass them to a product lookup, and show the name and description instead. - An empty list is a valid result, not a failure: say no themes are available and stop; do not retry or re-tune parameters. - To limit platforms, copy supplier platform IDs only from `list_stores` `supplier_apps[].supplier_platform_id`; omit them when unsure to cover every visible platform. \[Side effects\] Read-only; no data or configuration is changed. \[Confirmation\] None required. \[Follow-up\] Themes only: once the merchant picks a collection, search it with `search_supplier_products`; listing themes alone does not answer "what should I sell".
list_managed_store_products	\[Store Products\] \[What it does\] Lists one store's DSers-managed products as lightweight card-ready summaries with product identity, title, image, selling-price range, mapping status, sales status, and mapped supplier product price ranges. \[When to use\] Use it when the user browses or filters products already managed in DSers, and when the agent needs a `dsers_product_id` before reading detail or changing price, stock, or mapping. Trigger words: my products, managed products, unmapped products, product list. \[When not to use\] For sales options or variants, exact variant IDs, mapped supplier IDs, effective supplier inventory, sync settings, DSers blacklist state, or seller-deletion state, use `get_managed_store_product`. For store products not yet imported into DSers, use `search_store_products`. This tool never edits products. \[How to use\] - `dsers_store_id` is required and comes from `list_stores`; use `list_stores` separately when the card also needs the store display name. - `product_search_type` changes what `keyword` searches: `store` searches Sales Product titles, `supplier_product_name` searches mapped Supplier Product names, and `supplier_store_name` searches supplier store names. - `items[].dsers_product_id` is the required DSers-managed product ID, not a supplier or sales-platform ID; use it with `get_managed_store_product` and Mapping Tools. - The current Product BFF list response does not expose `sales_product_id`, supplier store name, or supplier store URL, so this Tool does not invent them. - Sales prices and supplier product prices are separate min/max decimal strings with their own currencies. The supplier range is product-level price data, not a normalized variant cost; never label it USD unless `supplier_product_currency` is actually USD. - `items[].mapped_supplier_product_list` contains Product BFF's main mapped Supplier Product summaries; Basic Mapping non-default secondary suppliers are not included. Its IDs can be reused for supplier detail lookup. - Empty `items` means no match, not an error. When `pagination.has_more` is true, pass `next_cursor` back unchanged as `cursor` and keep every filter and sort identical. \[Side effects\] None; read-only. \[Confirmation\] Not required.
list_orders	\[Order\] \[What it does\] Browses orders, returning order summaries, per-tab counts, and cursor pagination; it is the entry point for obtaining order IDs. An explicit `supplier_platform_id` scopes Elasticsearch to that supplier; omitting it searches without a supplier filter. \[When to use\] Use it when the user wants to find orders, see pending volume, or filter by store, buyer, or time, and whenever the agent needs real order IDs before reading detail or processing. Trigger words: recent orders, pending orders, this buyer's order, problem orders. \[When not to use\] For the full record of a known order, use `get_order`. To place orders, use `place_orders_to_suppliers`. For shipment tracking, use `get_package_details`. \[How to use\] - `supplier_platform_id` is optional. When the user names no supplier, omit it: Elasticsearch is not filtered by supplier and reconstructed items are not filtered by supplier. The string `0` searches Unmapped only and still filters items to Unmapped. Copy a positive ID from `list_stores` `supplier_apps[].supplier_platform_id` when the user names a supplier, and never substitute a sales channel ID. - `status` is optional. Omit it by default when the user does not name a tab, and for exact order-number lookup; that returns cross-tab rows within the current Elasticsearch supplier scope in one call. Do not fan out tabs. An explicit status still filters reconstructed items to that tab. Statuses are tab memberships, not exclusive states: an order can sit in several tabs, counts overlap and must not be summed into a total, and pending and awaiting order are distinct values that both belong in any summary. - Each `line_items[]` row exposes `supplier_platform_id` and `tab_statuses`. If this call omitted `supplier_platform_id` or `status`, copy the omitted field from the same `line_items[]` row into `get_order`. Mixed `tab_statuses`: pick the tab matching the user intent, else the first known value. Do not invent supplier/tab pairs. If `tab_statuses` is empty, do not call `get_order`; re-list with an explicit `status`. Do not fill item tabs from `orders[].order_status`. - Each row's `order_status` is the tab requested for that call when `status` was set; when `status` was omitted it is the first known item tab, not a complete status set or an exclusive whole-order state. - Money is reported in several bases: order income is authoritative in the seller-platform currency, the setting-currency amount may appear only as a labeled conversion, and item prices and supplier costs use the DSers default currency. Row money follows this request's Elasticsearch supplier scope; when `supplier_platform_id` is omitted, that scope is not limited to one supplier. - Pages hold up to 100 rows; pass the returned cursor back unchanged for more. \[Side effects\] None; read-only. \[Confirmation\] Not required.
list_packages	\[Tracking / Logistics\] \[What it does\] Lists account-owned packages by normalized logistics status; read-only. \[When to use\] Use when packages that are pending, in transit, delivered, in an exception state, or flagged for attention are needed. \[When not to use\] For the tracking events of one known package, use `get_package_details` instead of this tool. \[How to use\] Filter with `status=all`, `status=pending`, `status=in_transit`, `status=delivered`, `status=abnormal` (all exception packages), or `status=attention` (flagged packages). You can also filter by order/tracking keyword, store, supplier platform, order age, or Unix time range; `page_size` caps at 100; reuse the previous `next_cursor` to page. An empty `items` array is valid; `has_more=true` means more results remain. \[Side effects\] Read-only. \[Confirmation\] No confirmation required. \[Follow-up\] If a package is in an exception or appears overdue, inspect it with `get_package_details`; otherwise report the result and stop.
list_platform_shipping_methods	\[Supplier / Logistics\] \[What it does\] Lists logistics/shipping services available for one supplier platform and destination country (or Global). \[When to use\] Use when you need valid `shipping_method` values for a given supplier and destination, such as before `update_order_supplier` or a pricing calculation. \[When not to use\] Not for checking an order's actual shipping status; this only returns available service options. \[How to use\] `supplier_platform_id` (from `list_stores`) and `country_code` (from the countries list, a 2-3 letter code or "Global") are both required; returns each service's ID, name, average cost, and time. \[Side effects\] None; read-only. \[Confirmation\] Not required.
list_pre_publish_products	\[Import List Product\] \[What it does\] Searches the account's pre-publish products — the items on the DSers Import List page: imported from suppliers, not yet pushed to a store — returning summary rows: title, supplier, cost and sell price ranges, stock, tags, and push status. \[When to use\] Use it when the user wants to find, browse, or filter products saved but not yet pushed to a store, and when the agent needs an `import_item_id` before reading detail, repricing, or pushing. Trigger words: products I saved, products in my import list, not pushed yet, pre-publish products. \[When not to use\] For one pre-publish product's options, variants, prices, or stock, use `get_pre_publish_product`. For supplier products not yet imported, use `search_supplier_products`. For products already on a store, including Draft status, use `list_managed_store_products`. It never adds, edits, or removes items. \[How to use\] - No parameter is required; with no filters it returns the default list. - Rows are summaries with `_partial` true; option, variant, per-SKU price, and stock details stay empty until you call `get_pre_publish_product`. - Cost bounds are exclusive when sent alone but inclusive when both are sent, and they use USD major units, not the store currency. - `sku_limit` is a strictly-greater-than threshold; omit it or send 0 to skip SKU-count filtering. - Empty `items` is a valid result. When `has_more` is true, resend `next_cursor` unchanged and keep filters and sort identical. - Import List products, draft products, and pre-publish products all name the same objects; accept the old wording and answer in generic product terms instead of sending the user to a page. \[Side effects\] None; read-only. \[Confirmation\] Not required.
list_stores	\[Store\] \[What it does\] Lists connected seller stores with their application, country, currency, timezone and connection status, plus supplier applications available to product tools. It takes no input. \[When to use\] Call it when the user asks which stores are connected, about a store's currency, timezone or status, and proactively before any store-scoped action because downstream tools accept only a store ID. Trigger words: store list, Shopify, store status, authorization, currency, timezone. \[When not to use\] For products inside a store use `search_store_products`; for pricing-rule detail use `get_pricing_rule`; for a reconnect link use `start_store_reauthorization`. It never adds, unbinds or edits stores. \[How to use\] - Match the user's store reference against the returned stores; continue only on one clear match, ask the user to choose on multiple matches, and never write to all stores by default. - An empty list means no connected store is available, and sections in `degraded_parts` are unavailable only this time — note them and continue rather than retrying. If a status is not `AVAILABLE`, inspect the returned status before choosing reauthorization; do not infer that every non-available state requires it. - Do not mix IDs: `stores[].dsers_store_id` for store-scoped tools, `stores[].sales_channel_id` for connection flows, and `supplier_apps[].supplier_platform_id` for supplier-product tools; `sales_store_id` is not a DSers store ID. - Hidden stores are still returned — exclude or flag them when counting, and read each store in its own currency and timezone, not the account's. - For `publish_products_to_stores`, Shopify Shipping Profile choices come from `stores[].shipping_profiles[].id` and the chosen profile's `locations[].id`; fixed product-push choices remain in that Tool's input schema, while this Tool also returns dynamic languages and effective store defaults. \[Side effects\] Read-only; no store, authorization or push setting is changed. \[Confirmation\] None required; picking among matches is disambiguation.
list_supplier_product_change_notifications	\[Supply Product\] \[What it does\] Read-only list of cost, stock, SKU, and availability change notifications for previously ordered supplier products from the last 30 days. \[When to use\] Use to check supplier-side changes affecting mapped store products. \[When not to use\] For product details, use `get_supplier_product`; for other alert types, use the applicable notification tool. \[How to use\] App/store filters use decimal-string ID arrays; times use Unix timestamps; `page_size` caps at 100. Only changes from the last 30 days are returned; an empty result is valid. Mapped metadata can be incomplete — fields in `missing_fields` remain unknown. Pass `next_cursor` when `has_more=true`. \[Side effects\] Read-only; does not mark notifications as read. \[Confirmation\] No confirmation required. \[Follow-up\] For a cost increase needing margin review, use `get_pricing_rule`; for an already-approved change, use `update_pricing_rule`; for stockout/unavailability, find replacements with `search_supplier_products`; for a SKU change on a mapped product, review candidates with `search_ai_mapping_candidates`; otherwise report and stop.
list_supplier_product_freight_quotes	\[Supply Product\] \[What it does\] Lists freight quotes for one supplier product (or specific SKUs) to a destination country, for cost estimation before import. \[When to use\] Use to compare cost, delivery time, and tracking support before importing. \[When not to use\] For product or variant details, use `get_supplier_product`; to import, use the import tool, not this one. \[How to use\] Copy `supplier_platform_id` and `supplier_product_id` from `search_supplier_products` or `get_supplier_product`; `ship_to_country` is a country code. For one SKU use `supplier_product_variant_id`; for several use `supplier_product_variant_ids`. Copy either from `get_supplier_product` `supplier_product_variant_list[].supplier_product_variant_id`, or omit both for product-level quotes. The returned `quotes[].ship_from` is supplier-provided information, not a selectable filter. An empty quote list is a valid no-quote result. \[Side effects\] Read-only; no data changes. \[Confirmation\] No confirmation required. \[Follow-up\] If a quote meets cost, timing, and tracking needs, continue the original product flow; if none is available, verify the destination and SKUs or abandon the candidate.
list_supplier_search_filters	\[Supply Product\] \[What it does\] Returns the machine values of every supplier-product search filter available to this account, grouped by visible online supplier platform, plus which filters each platform actually supports. Returns no products. \[When to use\] Call before running a supplier product search, to translate spoken conditions such as "ships from the US", "arrives within 3 days", "free shipping", a category, or a specific carrier into submittable values; initial discovery can be called with no input. Pass `supplier_platform_id` to load one platform's options, and optionally `parent_category_id` to load only that category's direct children. \[When not to use\] Use `search_supplier_products` when you need actual products; this tool returns filter values only. Does not cover filters for products already imported into DSers or listed in a store. Not a settings reader — it cannot view or change the user's logistics configuration. \[How to use\] Copy `platforms[].ship_from[].supplier_product_country_code` to search `ship_from`, `platforms[].ship_to[].supplier_product_country_code` to `ship_to`, `platforms[].categories[].supplier_platform_category_id` to `category_ids`, `platforms[].shipping_methods[].supplier_shipping_service_id` to `shipping_method`, and `filter_capabilities[].options[].value` to the named search input. Labels are display-only. Every value is bound to its `supplier_platform_id`, and only keys listed in that platform's `supported_filters` take effect. A category response contains root categories or one requested parent's direct children; when `has_children=true`, call again with that category ID as `parent_category_id`. Monetary ranges are always USD. `failed_sources` means one filter type on one platform is missing, not a total failure — other platforms and options remain usable, and retrying only helps when `retryable=true`. \[Side effects\] None, read-only. \[Confirmation\] Not required. \[Follow-up\] After the user picks filter values, call the supplier product search tool named in `next_tool`.
list_supported_countries	\[Utility\] \[What it does\] Lists countries currently supported by DSers, returning each country's ID, code, and display name. \[When to use\] Use it to obtain valid destination country codes before calling logistics tools such as `list_platform_shipping_methods`. \[When not to use\] It does not support search, filtering, or pagination, and cannot modify country configuration. \[How to use\] No input is required. Copy the returned `countries[].code` exactly for later logistics calls; never use the country name or ID as the code. `total` equals the number of countries returned in this call. \[Side effects\] None; read-only. \[Confirmation\] Not required.
place_orders_to_suppliers	\[Order\] \[What it does\] For AliExpress (`supplier_platform_id=159831080`), returns only a DSers Orders page `url` at the fixed `/application/orders` path without saving a search snapshot or placing orders. For every other supplier, submits matching orders as an asynchronous task that may create real supplier orders and incur cost. \[When to use\] Use it when the user explicitly asks to place or process orders, and only after the agent has confirmed the target orders have no blockers and the user has approved. Trigger words: place these orders, send to the supplier, process pending orders. \[When not to use\] To check eligibility only, use the order diagnostic tool. For payment after placement, use `create_order_payment_link`. To read current status, use `list_orders` or `get_order`. \[How to use\] - `supplier_platform_id`, `sales_channel_id`, `status`, and `selection_mode` are required. `selection_mode` is `selected` or `filtered` with no default; never infer it from whether `dsers_order_ids` is empty. - `selected` uses exact `dsers_order_ids` and only the required `status`, `supplier_platform_id`, and `sales_channel_id`. Empty, `search_by=default`, and `cancel_source=any` count as omitted; any other search filter is rejected. IDs must be unique positive decimals; duplicates are not silently dropped. - For AliExpress, `selected` accepts 1–20 IDs for input validation without checking ownership or placeability; `filtered` validates and resolves store ownership. Both modes return only `/application/orders`; the URL does not retain IDs, filters, or tab state, so the user must review the target orders again in DSers. - For every other supplier, `selected` accepts 1–20 IDs and writes them as exact `order_ids`. One ID is checked for ownership, supplier, and store scope, and that order's store is pinned under `sales_channel_id`. With two or more IDs, missing or unowned IDs are skipped when collecting stores, every owned order must belong to `sales_channel_id`, the original unique IDs are passed through, and the call fails if none are owned. Final placeability is decided by Order BFF. - `filtered` omits `dsers_order_ids` and matches by `dsers_store_ids`, `query`, `search_by`, time, countries, flags, `agency_ids`, and `cancel_source`. Never approximate a few user-named orders with filters: a filter usually matches far more orders than intended and can place unwanted ones. A non-default `search_by` requires `query`. - A non-AliExpress response returns `task_type` and `task_id`; these identify the polling scope and do not mean every order was placed successfully. Poll `get_job_status` until `terminal=true`, then confirm the real outcome order by order with `list_orders`. If a status is unchanged or unknown, never send the placement request again, or orders may be placed twice. \[Side effects\] The AliExpress URL hand-off does not place orders. Other suppliers may create real supplier orders and spend money. \[Confirmation\] Mandatory and not skippable; show each order and amount.
publish_products_to_stores	\[Import List Product\] \[What it does\] Publishes reviewed import-list products to selected stores in one call, creating store products whose listing status and buyer visibility follow the chosen settings; up to 100 product-store targets per call. \[When to use\] Use it when the user confirms that prepared products should go to the named stores, and only after the agent holds a valid approval token for every target. Trigger words: publish to store, push products, list them, keep as draft. \[When not to use\] For product content or category settings, use `update_pre_publish_product_content` and `update_pre_publish_product_organization`. For an existing store product's price or stock, use `update_managed_store_product`. It does not republish products already in a store. \[How to use\] - Every product-store target needs its own `push_approval_token` from `update_pre_publish_product_organization`; tokens last 24 hours and are single-use. If one expires with no configuration change, re-read and reissue with `confirm_current=true`. - A token proves the settings were reviewed; it is not the user's consent to publish. - Every item must use the same store set. Send the user's complete selected stores in one call; use separate calls when product groups need different store sets. The expanded matrix must stay within 100 product-store targets. - `sales_channels` is passed through for every target. If a target platform does not support the selected channel, that option may not take effect; this does not block the push. - `stores[].shipping_profile` remains Shopify-only and must be omitted for non-Shopify stores. Copy `profile_id` from the matching `list_stores.stores[].shipping_profiles[].id` and `location_id` from that profile's `locations[].id`; never guess or combine values from different stores or profiles. - `product_status` and `publish_to_online_store` are independent: active alone does not make a product buyer-visible, which requires both. - Omitted listing options fall back to DSers or store defaults, so state the effective values before confirming. - An accepted write returns one `task_type` and `task_id`; poll `get_job_status` until terminal and read the task's per-target status. - The write is not idempotent and can partially succeed after acceptance: send once, inspect task status and failure reasons, and retry only with newly issued tokens. \[Side effects\] Creates store products in every selected store and may make them buyer-visible immediately. \[Confirmation\] Required, never skippable: show effective settings for every product-store target.
recommend_apps_to_install	\[Plugins\] \[What it does\] Recommends every visible sales-channel or supplier-platform application of the selected type that is not yet installed; read-only. \[When to use\] Use when the user wants to discover another channel or supplier platform. \[When not to use\] To install and authorize a selected sales-channel application, use `start_store_connection`; to inspect connected stores, use `list_stores`. \[How to use\] Set `app_type` to `seller`, `supplier`, or `all` (the default). The Tool does not provide keyword filtering or caller-controlled pagination. An empty recommendation list is valid. \[Side effects\] Read-only; installs or authorizes nothing. \[Confirmation\] No confirmation required. \[Follow-up\] If the user selects a channel application, continue with `start_store_connection`; otherwise report the recommendations or empty result and stop.
search_ai_mapping_candidates	\[Store Products\] \[What it does\] Finds visually similar supplier item for one DSers product via image search, with price, stock, freight, rating, and similarity evidence; creates or applies no mapping. \[When to use\] Use when the merchant wants to compare suppliers before mapping a managed product. \[When not to use\] For a general supplier-catalog search, use `search_supplier_products`; to start the selected mapping computation, use `start_ai_product_mapping`. \[How to use\] Copy `dsers_product_id` from `list_managed_store_products`; `ship_to` sets destination context for availability and freight. Zero matches is a valid result and may include a reason; missing price, rating, or similarity remain unknown. \[Side effects\] Read-only; neither creates nor applies a mapping. \[Confirmation\] No confirmation required. \[Follow-up\] If the merchant selects a suitable candidate, start its computation with `start_ai_product_mapping`; if none fits, report the result and stop.
search_store_products	\[Store Products\] \[What it does\] Searches products directly on a seller's store platform (e.g. Shopify), not DSers My Products; used to inspect store products or as an import source. \[When to use\] Use to find what a store sells or to locate store products for importing into DSers. \[When not to use\] For products already managed in DSers, use `list_managed_store_products`; to import selected products, use `import_store_products_to_dsers`. \[How to use\] Copy `dsers_store_id` from `list_stores`; pages are 1-based; pass the previous `next_since_id` unchanged as `since_id` for the next page. Each item's `already_imported` state is included; an empty result is valid. \[Side effects\] Read-only; no store or DSers data changes. \[Confirmation\] No confirmation required. \[Follow-up\] If importing is the goal and the user selects products not already in DSers, continue with `import_store_products_to_dsers`; otherwise report the result and stop.
search_supplier_products	\[Supply Product\] \[What it does\] Searches supplier products by keyword or image across the account's visible supplier platforms, returning comparable candidates and echoing the filters that actually took effect. \[When to use\] Use it when the merchant wants to find products to sell, compare suppliers, or match an uploaded image; the agent also calls it first to obtain the supplier platform ID and product ID needed before a detail lookup or an import. Trigger words: sourcing, find a supplier, same as this image, best sellers, cost price. \[When not to use\] For variants, stock or per-country shipping on one known product use `get_supplier_product` and `list_supplier_product_freight_quotes`; to import or map use `create_pre_publish_products`; for products already in the merchant's stores use `list_managed_store_products`. \[How to use\] - Paging depends on scope: cursor paging and a larger page size work only when one supplier platform is selected; an all-platform search returns a fixed slice per platform, so pick a platform before paging. - Compare only the metrics marked available on a candidate, and only in the base currency; unmarked metrics are unknown, and original supplier prices carry different currencies, so never infer or mix them. - Filters are adapted per platform: trust the echoed effective conditions and tell the merchant which filters did not apply, rather than claiming the results meet every condition. - If some platforms fail while others return candidates, treat it as partial coverage — report the gap and continue; do not retry the whole search or answer "nothing found". \[Side effects\] Read-only; never imports, edits or maps products. \[Confirmation\] Not required.
send_buyer_tracking_notification	\[Order\] \[What it does\] Asynchronously requests a Shopify fulfillment tracking notification for the buyer of one owned order; Shopify only. \[When to use\] Use when the merchant wants Shopify to notify the buyer about tracking for fulfilled items that already have tracking information. \[When not to use\] To fulfill items or synchronize tracking to the seller store, use `update_store_order_tracking_number` first. This tool does not apply to non-Shopify platforms. \[How to use\] - Copy one exact `dsers_order_id` from `get_order` after checking the fulfilled items and tracking information. The request is order-wide and cannot select a subset of line items. - A successful response contains only `message`: it means Order BFF accepted an asynchronous notification request, not that Shopify sent it or the buyer received it. Shopify may suppress an identical recent update. - Send once, never auto-retried. If the outcome is unknown, check the Shopify order and buyer notification history before deciding what to do; `get_order` can confirm order and tracking prerequisites but cannot confirm notification delivery. \[Side effects\] May send an external tracking notification to the buyer. \[Confirmation\] Required, never skippable: show the exact order, eligible fulfilled items, and tracking information, and state that this may contact the buyer. \[Follow-up\] After acceptance, check the Shopify order and buyer notification history later; if rejected, report the error and stop.
simulate_pricing_rule	\[Pricing Rule\] \[What it does\] Simulates the selling price and compare-at price that the store's Pricing Rule would compute for a DSers-managed product's mapped variants in a given destination country and cost, without writing anything back. \[When to use\] Use when the user wants to preview what price a Pricing Rule would produce before actually applying it, such as after a cost or destination change. \[When not to use\] To actually write the live price, use `update_managed_store_product`. To view or edit the rule itself, use `get_pricing_rule`/`update_pricing_rule`. \[How to use\] `dsers_product_id` and `ship_to` (2-letter country code) are required. Optionally list specific `sales_product_variant_id` values with an optional cost override (defaults to the mapped supplier cost); omitting the list simulates all mapped variants. Unmapped variants never appear in the results. \[Side effects\] None; read-only and never writes back to the product. \[Confirmation\] Not required.
start_ai_product_mapping	\[Store Products\] \[What it does\] Starts an asynchronous AI Mapping computation between one DSers product and one supplier candidate; it does not apply the resulting mapping. \[When to use\] Use after the merchant selects a supplier candidate for that product. \[When not to use\] To find or compare candidates, use `search_ai_mapping_candidates`; this tool cannot apply a computed mapping — that requires the mapping-apply tool associated with `get_store_product_mapping`. \[How to use\] Copy `dsers_product_id` from `list_managed_store_products`; copy `supplier_platform_id` and `supplier_product_id` from the same `search_ai_mapping_candidates` candidate. Read `task_created` and `next_step` before acting: a newly created task has `task_created=true`; a false value can point to an existing task, an existing completed result to apply, or an Applied result requiring confirmed remap. Follow the returned `status_tool` only when present, using its `task_type` and `task_id`; do not treat running status as completion. \[Side effects\] A response with `task_created=true` consumes 8 AI Credits and creates a computation task; history-only responses create nothing, consume no Credits, and leave the product mapping unchanged. \[Confirmation\] Requires explicit, non-skippable confirmation; show the exact product, candidate, and 8 AI Credits cost first. \[Follow-up\] Follow `next_step`: poll an indicated new or existing task until terminal, apply an indicated completed result only after its separate confirmation, or show the remap preview before calling again with `remap=true`.
start_store_connection	\[Store\] \[What it does\] Installs the selected seller application if needed and generates its external authorization link for a new store connection; a returned link does not mean the store is connected. \[When to use\] Use after the user selects a sales-channel application for a new store. \[When not to use\] For an existing store needing reconnection, use `start_store_reauthorization` instead of restarting this flow. \[How to use\] Copy `recommend_apps_to_install.recommendations[].app_id` into `sales_channel_id`, or copy `list_stores.stores[].sales_channel_id` for an already-installed platform. Pass `country` only when the selected app requires a country-specific flow. A successful response returns `sales_channel_id`, `app_name`, a validated HTTPS `authorization_url`, and `generated_at`; this means only that the link was generated and external authorization is still pending. The upstream platform controls the URL lifetime and reuse policy. If the outcome is unresolved, verify with `list_stores` before retrying. \[Side effects\] May install the selected seller application. \[Confirmation\] Requires explicit, non-skippable confirmation; show the selected application and country choice first. \[Follow-up\] Give the returned `authorization_url` to the user to complete authorization on the platform, then verify the new connection with `list_stores`.
start_store_reauthorization	\[Store\] \[What it does\] Requests a platform reauthorization link for an owned store; generating the link does not mean reauthorization is complete. \[When to use\] Use for a store with a connection error, expired authorization, or another reconnection need. \[When not to use\] For a brand-new store connection, use `start_store_connection`; this tool is only for reauthorizing an existing store. \[How to use\] Copy `dsers_store_id` from `list_stores` after checking current status. A successful response returns `dsers_store_id`, `sales_store_name`, `sales_channel_id`, a validated HTTPS `authorization_url`, and `generated_at`; this means only that the link was generated. The upstream platform controls its lifetime and reuse policy. If the outcome is unresolved, verify with `list_stores` before retrying. \[Side effects\] Generating the link does not change authorization status. \[Confirmation\] Requires user confirmation before generating the link; skippable per authorization policy. \[Follow-up\] Give the returned `authorization_url` to the user to complete platform authorization, then verify the connection with `list_stores`.
sync_supply_order_tracking_number	\[Tracking / Logistics\] \[What it does\] Requests an asynchronous refresh of carrier tracking status for one tracking number and syncs it into DSers; does not return refreshed events immediately. \[When to use\] Use when a shipment's tracking looks stale and fresh data is needed before reporting progress. \[When not to use\] For current tracking events, use `get_package_details`; to find a tracking number, use `list_packages`. \[How to use\] Supply one tracking number `tn` copied from `list_packages`. `accepted` only means the request was accepted, not completed, and does not show that stored status changed — there is no completion flag or refreshed events in the response. Dispatch once, never auto-retry; check `get_package_details` first if the outcome is unclear. \[Side effects\] May update stored tracking data. \[Confirmation\] Required; skippable per authorization policy. \[Follow-up\] If refreshed status is still needed, wait and check `get_package_details`; if rejected, report the message and stop.
update_managed_store_product	\[Store Products\] \[What it does\] Changes selling price, cost, compare-at price, currency, or stock for exact variants of one DSers-managed store product, and handles the matching auto-sync switches. \[When to use\] Use it when the user asks to change an existing product's price, cost, or stock, and when the agent has already resolved the exact variants and target values. Trigger words: change the store price, reprice a live product, update stock, update cost. \[When not to use\] To inspect current prices, stock, or variants, use `get_managed_store_product`. For a product not yet pushed to a store — an item still on the DSers Import List — use `update_pre_publish_product_price`. To change or apply a store Pricing Rule in bulk, use the pricing-rule or bulk-price Tool. It edits one product only and cannot bulk-reprice by filter. \[How to use\] - Resolve IDs in order: `dsers_store_id` from `list_stores`, `dsers_product_id` from `list_managed_store_products` `items[].dsers_product_id`, and `sales_product_variant_id` from `get_managed_store_product` `sales_product_variant_list[].sales_product_variant_id`. SKUs, option text, and supplier variant IDs are rejected. - Every `price_updates` item requires `sales_product_variant_price_amount`, so resend the current selling price even when only `sales_product_variant_cost_amount`, `sales_product_variant_compare_at_price_amount`, or `currency` changes. - Amounts are major-unit decimal strings ("19.99", never "1999"), and `currency` sets the allowed precision; omit it only when the variant or product already has one. - `sales_product_variant_inventory_quantity` replaces the current quantity and is never a delta. - `price_auto_sync_action` is mandatory with price updates and `stock_auto_sync_action` with stock updates; `disable` permanently turns that sync off. - This write is not idempotent. Send it once, for at most 100 variants of a single product. - Compare `price_variants_updated` and `stock_variants_updated` with what you requested; if they differ or the outcome is unknown, re-read with `get_managed_store_product` instead of retrying. Subscription errors block the write and are returned as structured errors. - This tool covers only products already pushed to a store, including Draft status; for items not published yet, use `update_pre_publish_product_price`. If the publish state is unclear, or the product exists on both sides, ask before changing the live price. \[Side effects\] Changes buyer-visible prices and stock; `disable` also switches off auto-sync. \[Confirmation\] Required: show store, product, variants, and final values first.
update_order_information	\[Order\] \[What it does\] Updates fields still editable on a DSers order in its current status — shipping address, DSers-only note, sales-channel note, and/or supplier order message — without touching amount, payment status, quantities, supplier, or mapping. \[When to use\] Use when the user explicitly provides new address, contact, or note values and the order is still in an editable state. \[When not to use\] To change which supplier fulfills the order, use `update_order_supplier`. This cannot be used once the order is submitted, paid, or otherwise locked. Never guess or infer address or contact details. \[How to use\] `address` fields are partial; omitted fields are preserved, so provide at least one field to change. `supplier_platform_id` is required only when setting `sales_order_sales_channel_note` or `dsers_supplier_order_message`, using the exact platform ID from this order, or 0 for Unmapped. Show the before/after diff and get explicit confirmation before writing. If the outcome is unknown, re-read the order rather than retry. \[Side effects\] Changes order details, which can affect fulfillment. \[Confirmation\] Required, never skippable: show the diff and get explicit confirmation for exactly the specified fields.
update_order_supplier	\[Order\] \[What it does\] Replaces the supplier used to fulfill one order or order item for this order only, without changing the product's long-term supplier mapping. \[When to use\] Use when the original supplier is unavailable, out of stock, mispriced, or cannot ship, and the user selects a replacement supplier for this order. \[When not to use\] To change the product's permanent supplier mapping, use `apply_product_mapping`. This tool only affects the current order and never writes back to product-level Mapping. \[How to use\] Read the order, current supplier, and existing mapping first. Validate the replacement supplier's product status, SKU, stock, price, shipping method, and destination-country support. Before writing, show the cost, stock, and shipping differences between the old and new supplier. This cannot be applied to orders already submitted, paid, or otherwise locked. If the outcome is unknown, re-read the order rather than retry. \[Side effects\] Changes which supplier fulfills this order, affecting cost, shipping, and fulfillment; does not touch product-level Mapping. \[Confirmation\] Required, never skippable: show the supplier comparison first.
update_pre_publish_product_content	\[Import List Product\] \[What it does\] Changes non-price content of one pre-publish product — an item on the DSers Import List page: title, description, images, package, options and option values, variants, SKUs, and stock, including deletions and duplications. \[When to use\] Use it when the user wants to edit, clean up, or save translated content for a pre-publish product, and once the agent has final wording or has identified the exact rows to change. Trigger words: change the title, edit description, remove images, delete variants, fix this import list product, save translation. \[When not to use\] For selling or compare-at prices, use `update_pre_publish_product_price`. For a product already pushed to a store, including Draft status, use `update_managed_store_product`. It does not translate; it only saves content you already produced. \[How to use\] - Take `import_item_id` and `resource_version` from a fresh `get_pre_publish_product`; stale versions are rejected, and at least one editable field must be sent. - Every option, option-value, and variant operation needs the ID plus its zero-based index, because duplicated rows keep the original ID. - `supplier_product_image_url_list` replaces the whole list rather than appending; resend all images even to add one, the first becomes the main image, and each must be a public HTTPS URL with a resource path. - Deletions cascade: removing an option value deletes every variant using it, and `delete_options` keeps only variants matching the reserve value you name. At least one option, one value, and one variant must remain. - Titles of variants that have options are derived; rename them through `rename_option_values`, not `supplier_product_variant_list[].supplier_product_variant_name`. - An empty string clears a field while omitting it preserves the field; `cost`, `currency`, and supplier are protected and cannot be changed. - This write is not idempotent. Send it once. The server verifies the stored content before returning `import_item_id`, `changed_fields`, `changed_variant_ids`, and `changed_option_ids`; it does not return a new `resource_version`. Before another write, or if the outcome is unknown, re-read with `get_pre_publish_product` instead of resending. - Import List products, draft products, and pre-publish products name the same objects; accept the old wording and answer in generic product terms rather than sending the user to a page. \[Side effects\] Rewrites the pre-publish product; deletions cannot be undone. \[Confirmation\] Required but skippable; always confirm deletions first.
update_pre_publish_product_organization	\[Import List Product\] \[What it does\] Saves or confirms Organization, Category, and URL handle settings for pre-publish products — the items on the DSers Import List page — in one store, and issues the single-use approval that publishing requires. \[When to use\] Use it once the user has chosen or confirmed listing categories and tags, and whenever the agent needs a push approval for each product-store target before publishing. Trigger words: keep current settings, change the collection, get my import list products ready to publish. \[When not to use\] To read available choices, use `get_pre_publish_product_organization`. To actually publish, use `publish_products_to_stores`. Product content and prices are out of scope. \[How to use\] - Always call the get tool first: each product carries its own `resource_version` and single-use short-lived `review_token`, while `dsers_store_id` sits at the top level. Send all 1 to 100 products in one call. - An empty `organizations` or empty `category_ids` clears those settings rather than leaving them untouched; use `confirm_current=true` to keep the current values. - Use only field names and value IDs returned by the get tool. `create_values` creates store-level values that can persist even if the rest of the call fails. - Repeat `marketplace_id` when changing categories. A `url_handle` may not contain spaces, slashes, question marks, hashes, or non-ASCII characters, and an empty string clears it. - The returned `push_approval_token` is single-use and valid for 24 hours; store it for publishing. It proves the settings were reviewed, not that the user consented to publish. - Batches can partially succeed, so read each item's executed flag, failure reason, and retryable flag instead of judging by the overall result. - If the outcome is unknown, re-read with the get tool rather than resending, because the earlier tokens are already consumed. - Import List products, draft products, and pre-publish products name the same objects; accept the old wording and answer in generic product terms rather than sending the user to a page. \[Side effects\] Changes store-level settings and may create new store values. \[Confirmation\] Required but skippable; use only values the user explicitly chose.
update_pre_publish_product_price	\[Import List Product\] \[What it does\] Supports three modes for one pre-publish product on the DSers Import List: `variants` changes selling and compare-at prices for exact variant rows, `fixed_price` sets one selling price for every variant, and `pricing_rule` only opens or closes the item's item-level pricing rule. Every successful price change automatically closes the item's item-level pricing rule in the same write. It never changes the store-level Pricing Rule. \[When to use\] Use it when the user wants to reprice a pre-publish product or explicitly open or close that import item's pricing rule. Before a price change, re-read the item, compute every target price, disclose that the item-level pricing rule will be closed, and proceed only after the agent has obtained confirmation. Trigger words: reprice a product that is not published yet, adjust prices before publishing, set one price for every variant, open or close this import item's pricing rule. \[When not to use\] For titles, images, options, or other non-price content, use `update_pre_publish_product_content`. For a product already pushed to a store, including Draft status, use `update_managed_store_product`; this tool never syncs store prices. To change the store-level Pricing Rule itself, use `update_pricing_rule`. \[How to use\] - Take `import_item_id` and `resource_version` from a fresh `get_pre_publish_product`; a version more than a few minutes old is rejected as stale. - Amounts are plain decimals with up to two places and are always stored as 77.77 to 7777; the `dsers_store_id` currency is a display label only and changes neither conversion nor precision. - Pick exactly one `mode` and send only its matching argument: `variants` with `supplier_product_variant_list`, `fixed_price` with `fixed_price`, or `pricing_rule` with `pricing_rule_status`. - `variants` and `fixed_price` automatically close the item-level pricing rule. Do not send `pricing_rule_status` with either price mode. Price changes and the close happen atomically in one Product BFF write and are both verified by read-after-write. - `pricing_rule` changes only the item-level pricing-rule status. It does not change prices, compare-at prices, price bounds, or `is_price_edited`; do not send price fields in this mode. - `fixed_price` applies atomically to every variant and cannot target a subset. - `supplier_product_variant_list` accepts 1 to 100 rows in `variants` mode; add `variant_index` whenever a `supplier_product_variant_id` is duplicated. - Send `supplier_product_variant_compare_at_price_amount` only on explicit request: a non-empty value must not be below the resulting price, and an empty string clears it. Never raise or clear it on your own when only price was requested. - This write is not idempotent. Send it once. The server verifies the stored update before returning `import_item_id`, `changed_fields`, and `message`; it does not return a new `resource_version` or warning list. Before another write, or if the outcome is unknown, re-read with `get_pre_publish_product` to confirm prices, compare-at values, the item-level rule, and the latest version instead of resending. - Stock or cost requests must go to `update_managed_store_product`; this tool changes only selling and compare-at prices. When the publish state is unclear, or the same product exists both as a pre-publish item and a store product, ask which side to change instead of defaulting. - Import List products, draft products, and pre-publish products name the same objects; accept the old wording and answer in generic product terms rather than sending the user to a page. \[Side effects\] `variants` and `fixed_price` persist pre-publish prices and close the item-level pricing rule; `pricing_rule` changes only that status. Published store products are unaffected. \[Confirmation\] Required, never skippable. For price modes, show before and after prices per variant and state that the item-level pricing rule will close. For `pricing_rule`, show only the requested status change.
update_pricing_rule	\[Pricing Rule\] \[What it does\] Saves one owned store's Pricing Settings. A call may update any combination of the store-wide Basic or Advanced rule, price endings, and exchange-rate mode. Supported rule modes are `none`, `basic`, and `advanced`. \[When to use\] Use only when the user explicitly asks to change a store's Pricing Settings, after a fresh `get_pricing_rule` read and after the user confirms the exact resulting store-wide configuration. \[When not to use\] To inspect settings, use `get_pricing_rule`. To preview a product price, use `simulate_pricing_rule`. To change live or pre-publish product prices, use the applicable product update Tool. This Tool changes the rule itself; it does not reprice existing products. \[How to use\] - Always call `get_pricing_rule` first. Copy `dsers_store_id` and `resource_version` unchanged. A successful write invalidates that version. - For a rule update, choose exactly one mode and its matching complete body: `mode=none` sends no rule body; `mode=basic` requires `basic_rule`; `mode=advanced` requires `advanced_rule`. Never send a body belonging to another mode. - Advanced `formula_mode=fixed` requires `fixed_ranges` and `fixed_rest` and must not send custom fields. Advanced `formula_mode=custom` requires `custom_ranges` and `custom_rest` and must not send fixed fields. Inactive saved Advanced fields are preserved. - Basic and Advanced boundaries are inclusive USD costs with at most two decimal places and `min < max`. Basic and Advanced fixed gaps are completed on the 0.01 grid from their rest formula; Advanced custom gaps are preserved. Collections may contain at most 100 ranges after completion. - Advanced custom expressions use the exact placeholders `[Product cost]`, `[Shipping cost]`, and `[Tax]`; percentage literals such as `10%` are supported. Settings Product validates every submitted expression before writing. - Advanced mode requires the current plan's pricing-rule benefit; unsupported plans receive an upgrade-required error before any write. - The rule, cents, and currency sections are updated independently. Omit top-level `mode` for a cents-only or currency-only update. Omitted sections are preserved; only an explicit false disables a cent-ending switch. A custom rate requires custom mode: `mode=default` omits `exchange_rate`; `mode=custom` requires a positive `exchange_rate`. - This Tool is not idempotent. Send once. If the result is unknown or partial, call `get_pricing_rule` and submit only what still differs. On success the server has read back and verified the saved state and returns the new `resource_version`. \[Side effects\] Changes store-wide Pricing Settings used by future price calculations, but does not directly rewrite existing product prices. \[Confirmation\] Mandatory and not skippable. Show the store, resulting active mode and formula, completed ranges, and every cents or currency change before calling.
update_store_order_tracking_number	\[Tracking / Logistics\] \[What it does\] Dispatches the seller-side fulfillment and tracking flow for the fulfillable items of one owned DSers order. The resulting shipment state and tracking can become buyer-visible. \[When to use\] Use when the supplier has shipped and the user wants the seller-platform order fulfilled or its existing tracking synchronized. Trigger words: sync the tracking number, mark as shipped, push tracking to the store, update store tracking. \[When not to use\] For carrier events, use `get_package_details`. To inspect the order, fulfillable items, and tracking numbers before dispatch, use `get_order`. This tool does not accept a new tracking number or a subset of items. \[How to use\] - Copy one exact `dsers_order_id` from `get_order`. The service validates ownership and the current fulfillable items before either write path. - Keep `switch_fulfillment_service=false` for the normal path. It calls Order Core `OnSupplierOrderSendGoods` immediately without waiting for delayed-fulfill settings. - Set `switch_fulfillment_service=true` only for a Shopify order after the normal path returns the specific fulfillment-service permission error and its retry instruction. This calls `SwitchFulfillmentService`, may change Shopify variant locations to DSers for later orders, and then dispatches Fulfill; it does not also call `OnSupplierOrderSendGoods`. - A successful response contains only `message`, which reports the accepted dispatch and safe next step; it does not prove final seller-platform fulfillment. - This write is not idempotent. Send it once. If the outcome is unclear, refresh `get_order` and the seller-platform order instead of resending. \[Side effects\] Dispatches seller-platform fulfillment; the Shopify switch path may also change variant locations. \[Confirmation\] Required, never skippable: show the exact store, order, current fulfillable items and tracking, selected path, and any Shopify location change first.
update_store_product_price_in_bulk	\[Store Products\] \[What it does\] Starts a whole-store price-sync task for one to 20 owned stores. Product BFF applies each store's currently enabled Pricing Rule to all eligible mapped products. \[When to use\] Use when the merchant explicitly wants to reapply the enabled Pricing Rule across complete stores. \[When not to use\] For one exact product or variant, use `update_managed_store_product`. For pre-publish products, use `update_pre_publish_product_price`. This Tool does not accept product filters, variant filters, fixed/percentage adjustment inputs, or Pricing Rule changes. \[How to use\] Copy the complete `dsers_store_ids` selection from `list_stores`. The preflight verifies store ownership, an enabled Pricing Rule, and no conflicting active task; it does not calculate a per-product price preview. The write creates an async task; after confirmation, poll `get_job_status` with the returned `task_type` and `task_id`; its `result` contains the current and final per-store progress. If task creation is uncertain, check status instead of creating another task. \[Side effects\] May change buyer-visible prices for every eligible mapped product in each selected store. \[Confirmation\] Required, never skippable: show the exact stores and explain that their enabled Pricing Rules apply store-wide.
update_supplier_order	\[Order\] \[What it does\] Starts an asynchronous refresh of supplier order details for one store or all owned stores; does not return refreshed data immediately. \[When to use\] Use when supplier order details (such as tracking or status) look stale or missing and must be refreshed before rereading the order; commonly the final write-back step in flows like Order Address Fix. \[When not to use\] For reading existing data without a refresh, use `get_order` or `list_orders`; to change order content itself, use the order-update tool, not this one. \[How to use\] Copy `dsers_store_id` from `list_stores`; omitting it covers all owned stores, so confirm scope first. A successful response returns `task_type` and `task_id`; use both with `get_job_status` until `terminal=true`. The response means only that the asynchronous job was created, not that supplier details are already refreshed. Dispatch once; if the outcome is unknown, poll the returned task instead of resubmitting. \[Side effects\] Creates a synchronization job that may update stored supplier details. \[Confirmation\] Requires non-skippable user confirmation; show the exact store scope first. \[Follow-up\] After the task reaches a successful terminal state, verify updated supplier details with `get_order` or `list_orders`; if it fails, report the task status and message, then stop.
validate_order_address	\[Order\] \[What it does\] Read-only check of one order's currently saved shipping address against DSers required-field, length, and format rules; never accepts or saves candidate address fields. \[When to use\] Use to inspect the saved address or investigate a reported address-rule failure before deciding whether an update is needed. \[When not to use\] It cannot validate an unsaved candidate address or confirm real postal deliverability. To change the address, use `update_order_information`. \[How to use\] Copy only `dsers_order_id` from `list_orders` or `get_order`. The address passes only when both `rule_validation_passed=true` and `rule_evaluation_complete=true`; passing does not confirm postal deliverability. \[Side effects\] Read-only; no order data changes. \[Confirmation\] No confirmation required. \[Follow-up\] If issues are reported, collect the corrected fields, show the proposed change, and call `update_order_information` after confirmation. Call this Tool again only after the update if the saved address must be checked again.

纠错与举报（发现条目失效、署名有误或涉及侵权？）

提交举报 / 纠错

侵权举报经核验成立后，我们会即时下线该条目并删除已存的内容副本。