scrape_listing_details

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

With no annotations provided, the description carries the full behavioral disclosure burden. It clearly states the tool scrapes and grades the listing, which is a good start, but it does not disclose potential rate limits, anti-bot risks, the need for the 'render' flag to handle dynamic content, or any side effects like delays. This leaves meaningful behavioral gaps for a scraping tool.

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 a single, information-dense sentence that front-loads the core action and then enumerates data points. While long, every item adds value for an agent deciding whether to call it, and the grading promise is a strong differentiator. A more structured format (e.g., bullets) would improve maintainability, but the current prose is efficient and not redundant.

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?

Given the tool's complexity and the presence of an output schema (which covers return values), the description is largely complete in listing what data is scraped and the grading output. However, it omits any practical caveats such as the need for rendering, error handling for invalid ASINs, or rate-limit expectations. Overall, it is close to sufficient for a scraping tool but lacks some operational warnings.

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 description explicitly mentions 'by ASIN', which clarifies the 'asin' parameter, but it completely omits any explanation of the 'render' parameter. With 0% schema description coverage, the description must name and explain both parameters; it only covers one, so the agent cannot know the purpose or effect of 'render' without external context.

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 states a specific verb ('scrape') and resource ('complete Amazon India listing by ASIN'), enumerating many distinct data points (title, images, bullets, A+ content, etc.), and pairs it with a unique grading feature that sets it apart from sibling tools like scrape_amazon_product or scrape_amazon_search. The additional promise to 'tell you exactly how to beat it' clearly distinguishes its purpose.

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 implies when to use it (when you need a comprehensive listing analysis and grading), but it does not explicitly contrast with alternatives, mention when not to use it, or state any prerequisites (e.g., ASIN validity, country-specific access). No exclusions or routing guidance to siblings is provided, so the agent must infer context from the purpose alone.

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