Skip to main content
Glama

LeoWorks Data Tools — Naver, K-beauty & AliExpress

leoworks/aliexpress-search-scraper

leoworks--aliexpress-search-scraper
Destructive

This tool calls the Actor "leoworks/aliexpress-search-scraper" and retrieves its output results. Actor description: Scrape AliExpress search results for any keyword — rank, title, price, discount, sold count, rating, ship-from and ads flagged — up to 60 pages. Rank mode tracks where your products rank for each keyword over time. No login.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNoOrder of the search results. Example values: "best_match"best_match
countryNoTwo-letter country code. Results, prices and product IDs depend on the region; the proxy exits in this country. Example values: "US"US
currencyNoThree-letter currency code for prices (e.g. USD, EUR, GBP). Example values: "USD"USD
keywordsYes**REQUIRED** Search terms, one per line (e.g. wireless earbuds, phone case). Example values: ["wireless earbuds"]
maxPagesNo60 products per page. Search mode: an upper bound next to the result cap (default 60 pages). Rank mode: how deep to look for tracked products (default 5 = top 300, up to 60).
waitSecsNoMax seconds (0–45, default 30) to cap the wait for the Actor run to reach terminal state. For long-running Actors the response returns at the cap with the current run status; follow `nextStep` to poll via get-actor-run. Set to 0 to fire-and-forget.
includeAdsNoKeep sponsored products in search-mode results (flagged isAd). Organic rank never counts ads. Example values: true
healthCheckNoInternal: fail the run when results look degraded (used by the developer's scheduled checks).
trackProductsNoOptional. Product URLs or IDs (any AliExpress site). When set, the Actor runs in rank mode: one row per keyword × product with its organic rank (ads excluded), position, page, and the change since the previous run — or 'not found within N'. Charged as keyword-checked instead of per result.
maxConcurrencyNoKeywords processed in parallel. Example values: 3
rankHistoryStoreNoKey-value store in your account that keeps the last rank of each keyword × product, so each row shows previousRank, rankChange (positive = moved up) and isNew. Leave empty to turn off. No extra charge. Example values: "aliexpress-rank-history"aliexpress-rank-history
proxyConfigurationNoDefault Apify datacenter proxy (in the shipping country) works. Example values: {"useApifyProxy":true}
residentialFallbackNoRetry failing pages through residential proxy in the shipping country. Example values: true
maxResultsPerKeywordNoStop after this many products per keyword. Applied before the page count. Starts at 20 for a quick, low-cost first run; raise it up to 3,600 (60 pages). Example values: 20

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
tipNoAdvisory guidance RAG Web Browser wrote to its key-value store under the reserved "TIP" key
runIdYesActor run ID
statsNoRun statistics
statusYesRun status: READY | RUNNING | TIMING-OUT | TIMED-OUT | ABORTING | ABORTED | SUCCEEDED | FAILED
actorIdYesStable Apify Actor ID from the run record
summaryYesPast-tense summary of the run state
exitCodeNoActor process exit code; populated for terminal states (especially FAILED)
nextStepYesOne primary follow-up action with identifiers interpolated
storagesYesDataset and key-value store metadata, keyed by alias. "default" is always the primary entry.
actorNameNo"username/actor-name"
startedAtNoISO timestamp when the run started
finishedAtNoISO timestamp when the run finished (terminal states only)
statusMessageNoPass-through from Apify run.statusMessage
apifyConsoleUrlNoPersonalized Apify Console link to the run; present only for Console sessions

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare openWorldHint=true and destructiveHint=true, so the safety profile is partly covered. The description adds useful context ('No login', ads flagged, up to 60 pages), but does not disclose why the tool is destructive (credit consumption per result vs per keyword, actor-run launch) nor that it may return before the run finishes at the waitSecs cap. 'Retrieves its output results' slightly oversells synchronous behavior, though the schema's waitSecs/nextStep text corrects it.

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

Conciseness4/5

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

Two sentences, front-loaded with the platform and the scraped fields; nothing is redundant or padded. The opening 'calls the Actor ... and retrieves its output results' wrapper is the only dead weight.

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

Completeness3/5

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

With an output schema present, return values need not be explained, and the schema covers parameters and run polling. What is missing for a 14-parameter, credit-consuming actor is any note about cost model (per-result vs per-keyword) and the asynchronous run lifecycle, both of which matter for correct invocation but are only discoverable inside the schema.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all 14 parameters including defaults, enums and the rank-mode trigger. The description only gestures at a couple of concepts (rank mode, ads flagged) without adding syntax or semantics beyond the schema, so the baseline 3 applies.

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

Purpose4/5

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

The description states a concrete verb and resource ('Scrape AliExpress search results for any keyword') and enumerates the returned fields (rank, title, price, discount, sold count, rating, ship-from, ads), plus the two operating modes (search vs rank). It is clear enough to distinguish from the AliExpress reviews classifier and Naver trackers by platform and data type, though the leading boilerplate sentence ('calls the Actor ... retrieves its output results') adds nothing.

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

Usage Guidelines3/5

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

The description implies usage via the mode split ('Rank mode tracks where your products rank ... over time') and 'No login', but never states when to pick this tool over the sibling rank trackers or when rank mode is appropriate versus plain search. The concrete trigger (setting trackProducts) lives only in the schema, so guidance is implied rather than explicit.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.