SiteCheck Shop & Social

Made-in-China.com wholesale product search: product name

ecommerce_made_in_china

Read-only

Made-in-China.com wholesale product search: product name, supplier company, price range (USD, as the page's structured data gives it) and stock state from the public results page. Only the first page (about 20 products). Price: $0.002 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "q": "<q>"
    },
    "name": "ecommerce_made_in_china"
  }
}

Input Schema

Name	Required	Description	Default
`q`	Yes	Search word, 2 to 40 letters (e.g. mug, led lamp)
`limit`	No	How many products, 1 to 20 (default 5)

Output Schema

Name	Required	Description	Default
`q`	No
`count`	No
`items`	No
`source`	No
`checkedAt`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A3.5/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), yet the description adds genuinely new behavior: a per-call price of $0.002 in USDC, the x402 payment rails (Base, Solana, Arc), the fact that failed calls are free, and the first-page-only depth limit. That is exactly the kind of cost and scope context an agent needs before invoking a paid tool.

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 source and the returned fields, followed by limits and pricing. Dense but every clause carries information; the only slight drag is the parenthetical about structured-data pricing, which reads awkwardly.

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 an output schema present, a fully described input schema, and annotations covering safety, the description is nearly complete: it discloses cost, payment mechanism, and result depth. The remaining minor gap is failure/empty-result behavior, which is only obliquely covered by 'failed calls are not charged'.

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

Parameters2/5

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

Schema coverage is 100%, so both parameters (q with its 2-40 letter constraint and limit with 1-20/default 5) are already fully documented in the schema. The description contributes only the phrase 'price range (USD, as the page's structured data gives it)', which is a return-value caveat rather than parameter meaning, so it adds essentially nothing to q or limit.

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 ('wholesale product search' on Made-in-China.com) and enumerates the returned fields (product name, supplier company, price range, stock state), so the agent knows exactly what data comes back. The source domain makes it distinguishable from the many other ecommerce_* siblings without any explicit comparison.

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?

Usage is implied rather than stated: an agent can infer this is the tool for Chinese wholesale sourcing. The 'only the first page (about 20 products)' note is a useful boundary, but there is no explicit when-to-use/when-not or any pointer to alternatives such as ecommerce_aliexpress or ecommerce_faire for other marketplaces.

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

All SiteCheck Shop & Social 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.

Resources

Need Help?