apiguru-amazon-data

Product detail for up to 20 ASINs in one call

product_details_batch

Read-onlyIdempotent

Enrich a list of up to 20 ASINs in a single call. Fetches product details concurrently, deduplicates the input, and is faster and cheaper than multiple single requests.

Instructions

Use to enrich a list of ASINs in one call; compare the ASINs in results with the ones you sent. Batch variant of product_details. Accepts a comma-separated ASIN list, deduplicates it, and fetches all of them concurrently. Far cheaper and faster than N single calls. Price: $0.0024 per item (max 20). Billed per ASIN processed, including ones that come back not-found. More than 20 ASINs returns 413. Bullet points and specs are what Amazon shows for the listing; on multi-variant listings they can describe the product family rather than the exact variant. A null field means Amazon did not show it. ASINs Amazon has no record for on that marketplace are listed in not_returned (billed, like a not-found product_details call; retrying will not help). The batch record comes from Amazon's app, not the product page: price, rating, availability, images, bullets and variants, but no best-seller ranks, no category path and no merchant (seller) id. For those call product_details per ASIN. On an API key both cost one request per ASIN, so the batch saves calls and time, not money; keyless (x402) it is also cheaper per item. Compact rows carry brand, weight {raw, unit, value} and dimension {length, width, height, unit, raw} in product_details' shape, read from the row's product_attributes (package dimensions first); outside amazon.com Amazon's app prints centimetres under an inches label, so there dimension.unit is cm while raw keeps Amazon's text.

Input Schema

Name	Required	Description	Default
`geo`	No	Marketplace country code.	US
`asins`	Yes	Comma-separated ASIN list, maximum 20 after de-duplication. Each must be 10 uppercase alphanumeric characters. An Amazon product URL (…/dp/ASIN) works too, in place of an ASIN; lower case is fine. A URL's domain sets the marketplace unless geo says otherwise.
`fields`	No	Comma-separated top-level fields to return instead of the compact set, e.g. "weight,dimension,brand" or "product_attributes" (the whole spec table). Any response lists what it left out under _omitted_fields.
`compact`	No	Return the compact record (about 2-7 KB a row: title, brand, price, availability, rating summary, bullets, weight, dimension, variation_summary). false returns the full app record (15-150 KB a row: the product_attributes and product_details spec tables, images, the variation maps).

Output Schema

Name	Required	Description	Default
`results`	No
`request_id`	No
`country_code`	No
`response_time`	No
`amazon_request_count`	No
`billable_requests_count`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.1.59Oct 31, 2026

changedInput schema / properties / compact / description

Previous value: -"Return the compact record (about 4 KB: identity, price, rating, availability, bullets, category, offer, buy box). false returns the full record (about 75 KB, includes from_manufacturer, tech_specs, product_information, product_reviews)."New value: +"Return the compact record (about 2-7 KB a row: title, brand, price, availability, rating summary, bullets, weight, dimension, variation_summary). false returns the full app record (15-150 KB a row: the product_attributes and product_details spec tables, images, the variation maps)."

changedInput schema / properties / fields / description

Previous value: -"Comma-separated top-level fields to return instead of the compact set, e.g. \"tech_specs,product_information\". Any response lists what it left out under _omitted_fields."New value: +"Comma-separated top-level fields to return instead of the compact set, e.g. \"weight,dimension,brand\" or \"product_attributes\" (the whole spec table). Any response lists what it left out under _omitted_fields."

Changed3 schema fields changedv1.1.50Oct 4, 2026

changedInput schema / properties / asins / description

Previous value: -"Comma-separated ASIN list, maximum 20 after de-duplication. Each must be 10 uppercase alphanumeric characters."New value: +"Comma-separated ASIN list, maximum 20 after de-duplication. Each must be 10 uppercase alphanumeric characters. An Amazon product URL (…/dp/ASIN) works too, in place of an ASIN; lower case is fine. A URL's domain sets the marketplace unless geo says otherwise."

removedInput schema / properties / asins / pattern

Removed value: -"^[A-Z0-9]{10}(,[A-Z0-9]{10})*$"

changedInput schema / properties / geo / enum

Previous value: -[
-  "US",
-  "CA",
-  "DE",
-  "MX",
-  "UK",
-  "FR",
-  "IT",
-  "ES",
-  "AU",
-  "BR",
-  "IN",
-  "JP",
-  "NL",
-  "AE",
-  "PL",
-  "SA",
-  "SG",
-  "SE",
-  "TR",
-  "BE"
-]New value: +[
+  "US",
+  "CA",
+  "DE",
+  "MX",
+  "UK",
+  "FR",
+  "IT",
+  "ES",
+  "AU",
+  "BR",
+  "IN",
+  "JP",
+  "NL",
+  "AE",
+  "PL",
+  "SA",
+  "SG",
+  "SE",
+  "TR",
+  "BE",
+  "IE",
+  "ZA",
+  "EG"
+]

First observedv0.1.0Sep 27, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantial behavior beyond them: deduplication and concurrent fetch, $0.0024 per ASIN billed even for not-found or not_returned items, the 413 threshold, that retrying not_returned items will not help, and that batch records come from Amazon's app rather than the product page (hence missing ranks/category/merchant id). The multi-variant and null-field caveats are exactly the kind of gotcha an agent cannot infer from schema or annotations.

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?

Front-loaded with the purpose and the cost/latency argument, and nearly every sentence carries operational information. The final sentence about weight/dimension is a dense run-on that would read better split, and the pricing/billing detail is restated twice (per-item cost and per-ASIN billing including not-found).

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

Completeness5/5

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

For a 4-parameter batch read with an output schema and full annotation coverage, the description still supplies the failure modes (413, not_returned, null fields), the shape difference between compact and full records, and the field-coverage gaps versus product_details. Nothing an agent needs to call this correctly or interpret the result is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description goes beyond the schema by explaining what the compact row actually contains (brand, weight {raw, unit, value}, dimension triple, package dimensions first) and the non-obvious cm-under-inches-label quirk for dimension.unit outside amazon.com. It does not add anything about geo beyond the schema's one-liner, keeping it from a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('enrich a list of ASINs') and immediately frames itself as the 'batch variant of product_details', which pins down exactly which sibling it replaces. The 20-item cap and per-item pricing further scope what the tool is.

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

Usage Guidelines5/5

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

Gives explicit when-to-use ('use to enrich a list of ASINs in one call', 'far cheaper and faster than N single calls'), an explicit hard limit (>20 returns 413), and an explicit when-not-plus-alternative ('no best-seller ranks, no category path and no merchant (seller) id. For those call product_details per ASIN'). It even distinguishes API-key vs x402 billing so the agent knows when the batch is cheaper versus merely faster.

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

Deploy Server