Skip to main content
Glama

offers

Read-onlyIdempotent

LIVE Amazon offers page for one product: every seller offering it right now, read from Amazon's 'All offers' view at request time, every page of it (up to 10). Each offer has the seller and seller_id, price, shipping_cost, condition, buy box, FBA / FBM / Amazon, Prime, ships-from, the delivery promise and the seller's feedback record; the answer adds the buy box and the page's own header (title, image, rating, review count). No product page is fetched. USE WHEN the user asks who sells a product right now, wants every current offer, the cheapest new or used offer or the buy-box winner as of this minute, or needs a fresh seller list before buying, sourcing or repricing. DON'T USE for brand, BSR, listing content, reviews or price / offer history (product), for a keyword search (shopping, serp) or for a brand's or a seller's long-run buy-box record (brand, seller). RETURNS asin, marketplace, observed_at, title, image_url, rating, reviews_count, currency, price (the buy box), buybox_seller, buybox_seller_id, seller_count, no_sellers, pages_fetched, complete (false = Amazon stopped serving the offers pages part-way: the list is the part read, with partial_reason and a note), buybox_condition / buybox_condition_source / buybox_condition_detail (new | used | null = no featured offer; the pinned offer's condition text or the used storefront's name, e.g. Amazon Resale), current_sellers (sellers[] buy box first, then price ascending: seller, seller_id, price, shipping_cost, condition, condition_class, is_buybox, is_fba, is_prime, fulfillment, ships_from, delivery, seller_rating, plus buybox_days_30d and the 30-day buy-box shares from our observations; offer_count, used_offer_count, lowest_new, lowest_used), fulfillment (offer counts by AMZ / FBA / FBM, whether Amazon sells or holds the buy box) and seller_ratings; with gtin also gtin_resolution (source, confidence, barcode_verified). HONESTY: no_sellers=true means Amazon lists no offer for the product right now, an answer confirmed by a second, independent fetch before it is served; a fetch that fails is reported as an error, never as no sellers. LATENCY is SECONDS: typically 4-12s (one page ~4s; a long list walks every page). MARKETPLACES us, uk, de, ca, au, fr, it, es, jp, mx, br (no Walmart). COST API key required (the free no-signup lane cannot run live fetches). 0.5 credit when the answer carries at least one offer; a no-offers answer, an ASIN Amazon does not have, a barcode nothing resolves and a failed or busy fetch are never billed.

Input Schema

NameRequiredDescriptionDefault
zipNoOptional (2026-10-14): a US 5-digit ZIP - the offers page as Amazon shows it to a shopper at that ZIP, with location (Amazon's confirmed 'Deliver to' answer) and deliverable (whether the item is offered to that ZIP right now; Amazon Fresh and Whole Foods items deliver only to some ZIPs, and an out-of-area ZIP shows the same unavailable box as a stock-out). Page 1 of the offers only, a one-off session, nothing stored. country=us only. 1 credit when the answer carries an offer, and (since 2026-10-29) for a verified not-deliverable answer (the ZIP confirmed on the page, the offers page read, zero offers: not_deliverable_verified true); a ZIP Amazon rejects is guidance, never billed, as are deliverable null, a 404 and a failed fetch. A session at a ZIP is kept a few minutes per account, so this check right after a serp zip= search on the same ZIP skips the warm-up.
asinNoThe product's 10-character Amazon ASIN (a print book's ISBN-10 works too). Provide asin or gtin.
gtinNoA barcode instead of an ASIN: UPC-12, EAN-13, GTIN-14 or ISBN-13. Resolved cheapest evidence first: a listing we observe that carries it, a book's ISBN-10, the same product on another Amazon marketplace, then Amazon's own search (organic results only). gtin_resolution says which, and barcode_verified whether the listing itself carries the barcode. A barcode nothing resolves is never billed.
countryNoThe Amazon marketplace to read the offers page on.us
include_usedNotrue also lists the used, refurbished, open-box and collectible offers in current_sellers.sellers. Either way current_sellers carries used_offer_count, lowest_new and lowest_used, and every row its condition. Not billed extra.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / zip / description
      Previous value: -"Optional (2026-10-14): a US 5-digit ZIP - the offers page as Amazon shows it to a shopper at that ZIP, with location (Amazon's confirmed 'Deliver to' answer) and deliverable (whether the item is offered to that ZIP right now; Amazon Fresh and Whole Foods items deliver only to some ZIPs, and an out-of-area ZIP shows the same unavailable box as a stock-out). Page 1 of the offers only, a one-off session, nothing stored. country=us only. 1 credit when the answer carries an offer; a ZIP Amazon rejects is guidance, never billed."New value: +"Optional (2026-10-14): a US 5-digit ZIP - the offers page as Amazon shows it to a shopper at that ZIP, with location (Amazon's confirmed 'Deliver to' answer) and deliverable (whether the item is offered to that ZIP right now; Amazon Fresh and Whole Foods items deliver only to some ZIPs, and an out-of-area ZIP shows the same unavailable box as a stock-out). Page 1 of the offers only, a one-off session, nothing stored. country=us only. 1 credit when the answer carries an offer, and (since 2026-10-29) for a verified not-deliverable answer (the ZIP confirmed on the page, the offers page read, zero offers: not_deliverable_verified true); a ZIP Amazon rejects is guidance, never billed, as are deliverable null, a 404 and a failed fetch. A session at a ZIP is kept a few minutes per account, so this check right after a serp zip= search on the same ZIP skips the warm-up."
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations (readOnly, openWorld, idempotent, non-destructive), the description discloses that no product page is fetched, up to 10 offers pages are walked, latency is typically 4-12 seconds, an API key is required, and billing rules are stated precisely. It also explains the honesty guarantee around no_sellers and complete=false partial results, which is exactly the kind of behavioral context an agent needs.

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?

The description is front-loaded with purpose, then USE WHEN/DON'T USE, then returns and operational caveats. It is long and dense, but most of the length is justified by the absence of an output schema and the need to explain completeness, latency, markets and billing.

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 live-fetch tool with five parameters and no output schema, the description is complete: it enumerates the return fields, explains partial results and no-offer honesty, lists supported marketplaces, states latency, and covers billing and API-key requirements. Nothing critical is left for the agent to infer.

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

Parameters3/5

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

Schema description coverage is 100%, and the schema already documents asin, gtin, zip, country and include_used in detail. The description reinforces a few points such as gtin_resolution and the ZIP session behavior, but it does not add substantial meaning beyond the already-rich schema, so baseline 3 is appropriate.

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?

The description states a specific verb and resource: it returns the live Amazon offers page for one product, every seller offering it right now, read from the 'All offers' view at request time. It explicitly distinguishes this from product, brand, seller, shopping and serp tools, so an agent can select it without opening a schema.

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?

It provides explicit USE WHEN conditions: who sells a product right now, every current offer, cheapest new/used offer, buy-box winner, or a fresh seller list before buying, sourcing or repricing. It also gives explicit DON'T USE guidance pointing to product, shopping, serp, brand and seller for adjacent needs.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.