Start a Reverse Source scan: for each ASIN, search Google Shopping for a cheaper source than Amazon — i.e. where to buy the product to flip it. Up to 250 ASINs. Uses the shared Keepa scan key (counts against the user's daily scan credits). Returns a job_id — poll get_reverse_source_status(job_id) for results. Premium feature.
| Name | Required | Description | Default |
|---|---|---|---|
| asins | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavioral traits. It discloses that it uses a shared key, consumes credits, returns a job_id asynchronously, and is a premium feature. It does not mention error handling or concurrency limits, but covers the key behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (3 sentences), front-loaded with the main purpose, and includes all essential details without extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description specifies the return value (job_id) and how to obtain results via polling. It also notes the limit and premium feature. While it omits some details like concurrency or error recovery, it is fairly complete for an async scan tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter (asins) with 0% schema description coverage. The description adds the constraint 'Up to 250 ASINs', which provides important context beyond the schema, but does not specify format or validation rules. This is adequate but not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear verb (start) and resource (Reverse Source scan), and explains the outcome: searching Google Shopping for cheaper sources to flip. It distinguishes itself from sibling start_* tools by describing the unique nature of the scan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: uses shared Keepa key, counts against daily credits, returns a job_id for polling, and limits input to 250 ASINs. It does not explicitly state when not to use or mention alternatives, but the polling method is indicated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct data type or action (e.g., product analysis, deal types, FBA operations). Even similar-sounding tools like get_deal_results and get_oa_deals are clearly separated by domain (A2A vs OA) in descriptions. No significant overlap.
All tools follow a clear verb_noun pattern with underscores (e.g., analyse_product, create_deal_task, get_credits). The consistent 'get_' prefix for retrieval tools and varied but predictable action verbs make the set easy to navigate.
At 37 tools, the set is large but covers a broad Amazon seller ecosystem (research, sourcing, FBA, deals, monitoring). Each tool serves a distinct purpose, and the count reflects the domain's complexity without being bloated.
The tool surface covers all major seller workflows: product analysis, profit calculation, sourcing, deal discovery, storefront monitoring, FBA operations, purchase tracking, price alerts, and reconciliation. No obvious gaps for core tasks.
