What the user should reorder now. Per-SKU sales velocity vs stock on hand -> days of cover left, a suggested reorder quantity and its potential profit. Call for 'what should I restock?' or 'what's running low?'. lead_time_days = how long a resupply takes to land; cover_days = days of stock the reorder should provide. Requires a connected Amazon account.
| Name | Required | Description | Default |
|---|---|---|---|
| cover_days | No | ||
| lead_time_days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool computes per-SKU sales velocity against stock, calculates days of cover, and outputs a suggested reorder quantity and potential profit. It also explains the parameters lead_time_days and cover_days. The behavior is clearly presented as a read-only analysis, with no contradictions.
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 at 4 sentences, with the core purpose stated first. Each sentence adds essential information: purpose, output, usage context, parameter definitions, and prerequisite. There is no redundancy or extraneous text.
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?
For a tool with only 2 optional parameters and no output schema, the description covers the input semantics, output (suggested quantity, profit, cover days), and a prerequisite (Amazon account). It does not specify the exact return format (e.g., JSON object vs. list), but the level of detail is sufficient for an agent to understand and invoke the tool correctly.
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?
The input schema has 0% description coverage (no descriptions for parameters), but the description adds complete semantic meaning: 'lead_time_days = how long a resupply takes to land; cover_days = days of stock the reorder should provide.' This fully compensates for the schema gaps and goes beyond the default values provided.
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 clearly states the tool's purpose: to suggest what to reorder now based on sales velocity and stock on hand. It specifies the resource (restock suggestions) and directly addresses common user queries like 'what should I restock?' or 'what's running low?', distinguishing it from sibling tools like 'get_aged_stock' or 'get_amazon_inventory' which serve different purposes.
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 explicit guidance on when to use the tool (e.g., 'what should I restock?') and includes a prerequisite ('Requires a connected Amazon account'). However, it does not explicitly mention when not to use it or compare it to alternative tools, missing an opportunity for further clarity.
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.
