LeoWorks Data Tools — Naver, K-beauty & AliExpress

leoworks/aliexpress-reviews-classifier

leoworks--aliexpress-reviews-classifier

Destructive

This tool calls the Actor "leoworks/aliexpress-reviews-classifier" and retrieves its output results. Actor description: Scrape AliExpress product reviews — text, English translation, star rating, date, buyer country, option (SKU) and photos — from any product URL. Optional AI classification adds complaint types, sentiment and purchase motive, plus a per-product summary. No login.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`country`	No	Two-letter country code used for the request (affects which reviews AliExpress shows first and the translation language base). Default US. Example values: "US"	US
`waitSecs`	No	Max 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.
`healthCheck`	No	Internal: fail the run when results look degraded (used by the developer's scheduled checks).
`productUrls`	Yes	REQUIRED AliExpress product pages (any site: www.aliexpress.com, aliexpress.us, ko.aliexpress.com …) or product IDs, e.g. https://www.aliexpress.com/item/1005008549911526.html or 1005008549911526. Example values: ["https://www.aliexpress.com/item/1005008549911526.html"]
`reviewFilter`	No	Reviews come in AliExpress' default order. Star and date sorting are not offered by the source. Example values: "all"	all
`maxConcurrency`	No	Products processed in parallel. Example values: 5
`classifyReviews`	No	Add complaint types (delivery, quality/defect, size/fit, price/value, customer service, packaging, no effect, skin/body reaction, other), sentiment and purchase motive to each review. Reviews in other languages are classified from AliExpress' English translation. Charged per review as review-judged. Example values: true
`includeStarOnly`	No	AliExpress has many reviews with a star rating but no text or photos. They are skipped (not charged) by default; turn this on to collect them too (charged as review).
`reviewsPerProduct`	No	Maximum reviews to collect for each product (charged per review). The form starts at 20 for a quick, low-cost first run; raise it up to 5,000 (default when omitted via API: 100). Example values: 20
`complaintThreshold`	No	Minimum probability (0–1) for a complaint type to be reported. Example values: 0.5
`proxyConfiguration`	No	Default Apify datacenter proxy works. Example values: {"useApifyProxy":true}
`residentialFallback`	No	Retry failing requests through residential proxy in the shipping country. Example values: true

Output Schema

TableJSON Schema

Name	Required	Description
`tip`	No	Advisory guidance RAG Web Browser wrote to its key-value store under the reserved "TIP" key
`runId`	Yes	Actor run ID
`stats`	No	Run statistics
`status`	Yes	Run status: READY \| RUNNING \| TIMING-OUT \| TIMED-OUT \| ABORTING \| ABORTED \| SUCCEEDED \| FAILED
`actorId`	Yes	Stable Apify Actor ID from the run record
`summary`	Yes	Past-tense summary of the run state
`exitCode`	No	Actor process exit code; populated for terminal states (especially FAILED)
`nextStep`	Yes	One primary follow-up action with identifiers interpolated
`storages`	Yes	Dataset and key-value store metadata, keyed by alias. "default" is always the primary entry.
`actorName`	No	"username/actor-name"
`startedAt`	No	ISO timestamp when the run started
`finishedAt`	No	ISO timestamp when the run finished (terminal states only)
`statusMessage`	No	Pass-through from Apify run.statusMessage
`apifyConsoleUrl`	No	Personalized Apify Console link to the run; present only for Console sessions

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 6, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true and openWorldHint=true, so the safety profile is partially covered. The description adds real context ('No login', AI classification is optional and enriches each review with complaint type/sentiment/motive plus a per-product summary), but it omits the per-review charging model and the fact that runs are asynchronous and may return before completion, both of which are operationally important.

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 with the substantive information (what is scraped, what classification adds, no login) front-loaded. The opening boilerplate 'calls the Actor ... and retrieves its output results' is filler that repeats the tool name.

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

Completeness4/5

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

With 12 parameters fully described in the schema and an output schema present, the description does not need to enumerate fields or return values. It covers the data surface and the optional classification mode adequately; the main gap is not flagging the cost-per-review and polling workflow that the schema mentions only in scattered parameter descriptions.

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 baseline is 3; every parameter (productUrls, reviewFilter, classifyReviews, reviewsPerProduct, proxies, etc.) is already documented in the schema. The description adds no format or default detail beyond what the schema provides.

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 names a specific verb and resource ('Scrape AliExpress product reviews – text, English translation, star rating, date, buyer country, option (SKU) and photos') and adds the optional AI classification layer, so an agent understands the output scope. It does not explicitly differentiate itself from close siblings such as leoworks--aliexpress-search-scraper or leoworks--korean-review-classifier, so it falls short of a 5.

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

Usage Guidelines2/5

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

There is no statement of when to choose this tool versus the AliExpress search scraper or the Korean review classifier, nor any prerequisite or exclusion guidance. The only routing hint ('follow `nextStep` to poll via get-actor-run') lives in the waitSecs schema field, not the description.

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

All LeoWorks Data Tools — Naver, K-beauty & AliExpress tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.