Skip to main content
Glama

Logimu

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, 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

TableJSON 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; a ZIP Amazon rejects is guidance, never billed.
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. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover readOnly/openWorld/idempotent/destructive, and the description goes well beyond them: latency in seconds, billing rules (0.5 credit, never billed on no-offers/failed fetch), API key requirement, supported marketplaces, and an HONESTY clause explaining that no_sellers is confirmed by a second independent fetch while failures surface as errors. This is rich behavioral context an agent could not get from 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?

Dense but well-structured with labeled sections (USE WHEN / DON'T USE / RETURNS / HONESTY / LATENCY / MARKETPLACES / COST) and front-loaded purpose. It is long, and some RETURNS field enumeration borders on restating schema-level detail, but nearly every sentence carries actionable information.

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 no output schema, the description fully documents the return shape (asin, price, buybox_seller, current_sellers fields, fulfillment, seller_ratings, gtin_resolution), plus cost, latency and failure semantics. An agent has everything needed to call it correctly.

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 adds real meaning beyond the schema: zip is scoped to page 1 and country=us, gtin resolution order and barcode_verified semantics, and per-parameter billing nuances (include_used not billed extra, unresolved barcode never billed). Slightly redundant with the schema in places, hence not 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 precise verb and resource ('LIVE Amazon offers page for one product: every seller offering it right now'), including scope (up to 10 pages, no product page fetched). It explicitly distinguishes itself from siblings product, shopping, serp, brand and seller, so an agent can route without opening any 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?

Explicit USE WHEN list ('who sells a product right now', 'cheapest new or used offer', 'buy-box winner as of this minute') and an explicit DON'T USE list naming the sibling tools to use instead (product, shopping, serp, brand, seller). Nothing is left to inference.

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.