Skip to main content
Glama

track_product

Idempotent

TRACK a product: pin an Amazon ASIN into our hot lane so its all-offers page is re-read every hour or every 2, 4, 12 or 24 hours, for as long as the plan is active (or a ttl_days you set), with e-mail and webhook alerts on the thresholds you give; every read lands in the product's history as a sub-daily buy-box point (price, buy-box seller, fulfillment, offer count - buybox_price_points_hot on the product tool). read=product_page (2026-10-29) reads the product page and its offers page instead, so the SALES RANK is read too: every reading lands in bsr_points_hot (and its offers page in buybox_price_points_hot); such a read draws 2 snapshots of the allowance. USE WHEN the user wants to watch a product's price, buy box, seller count or sales rank more often than our normal cadence: repricing, MAP and buy-box monitoring, a competitor's listing, a launch, a deal, a book's rank. Posting the same ASIN again renews it and changes its interval. DON'T USE to read data (product, offers): tracking only schedules the reads. COST 0 credits: what a plan sells is a daily allowance of tracked snapshots (Solo 2,500 a day = 416 products every 4 hours, Starter 6,000, Growth 18,000, Standard 40,000, Scale 170,000, Volume 710,000); when the allowance is spent the answer says so with the upgrade link, and when only a longer interval fits it is granted (granted_interval). RETURNS id, asin, country, status (active / paused / expired / stopped), interval, read, granted_interval, requested_interval, snapshots_per_day (reads_per_day too for product_page), expires_at, in_lane, last_snapshot_at, next_due_at, pending (true until the lane picks it up, within ~10 minutes), allowance (plan, snapshots_per_day, used, remaining). action=stop ends a tracking at once (by id from list_tracked, or by asin + country) and releases its allowance; the row stays listed 30 days as stopped. BULK (2026-10-14): asins (up to 10,000) with action=track / stop, and action=sync to make the active set equal to a list (dry_run first). STOCK STATES: every read is in_stock (a buy box), no_buybox (offers, no featured offer) or out_of_stock (no offers, confirmed twice); availability_change / out_of_stock / back_in_stock alert on the transitions, price alerts compare buy-box prices only. Paid plans only (the allowance belongs to a subscription). MARKETPLACES us, uk, de, ca, au, fr, it, es, jp, mx, br (no Walmart).

Input Schema

NameRequiredDescriptionDefault
idNoWith action=stop: the tracking id (from list_tracked). Or give asin + country, or ids / asins.
idsNoWith action=stop: several tracking ids at once (up to 10,000).
asinNoThe product's 10-character Amazon ASIN (one product). Or give asins.
readNoWhich page each read fetches (2026-10-29): offers (default) = the all-offers page (buy box, price, every offer, stock); product_page = the product page and its offers page, so the sales rank is read too: every reading lands in the product tool's bsr_points_hot, and its offers page in buybox_price_points_hot as with offers. A product-page read draws 2 snapshots of the allowance (12h = 4 a day). Like interval, every call sets it: tracking the same ASIN again without read switches it back to offers.offers
asinsNoBulk (2026-10-14): up to 10,000 ASINs in one call - with action=track all get the same interval / ttl_days / alerts (results[] in input order: created / renewed / refused / invalid, the allowance consumed in input order, never all-or-nothing); with action=stop they are stopped; with action=sync they are the full list the active set becomes.
actionNotrack (default) creates or renews the tracking(s); stop ends one or many at once; sync (2026-10-14) makes the account's active set on one marketplace EQUAL to asins: missing ones are created, active ones not listed are stopped, the rest are left as they are - dry_run first to see the counts.track
countryNoThe Amazon marketplace to track the product on.us
dry_runNoWith action=sync: return what would be created and stopped without writing.
intervalNoHow often the lane re-reads the product (see read). A shorter interval costs more of the daily allowance (1h = 24 snapshots a day, 2h = 12, 4h = 6, 12h = 2, 24h = 1; twice that with read=product_page).4h
ttl_daysNoOptional: stop after this many days (1-365). Omit (or 0) and the tracking runs for as long as the plan is active - a lapsed plan keeps it 7 days, then it pauses and resumes with the plan.
notify_ifNoWith webhook_url and / or alert_email: the thresholds. price_below / price_above (a buy-box price), price_change_pct (percent move of the buy-box price since the last in-stock read), buybox_seller_change (true: a different seller holds the buy box, between two in-stock reads), offer_count_below / offer_count_above (a count), availability_change (true: the stock STATE changed - in_stock, no_buybox = offers exist but Amazon shows no featured offer, out_of_stock = no offers at all, confirmed by a second read; the event carries both codes), out_of_stock (true: shorthand for a change to out_of_stock), back_in_stock (true: a change to in_stock). {} attaches the webhook and fires on nothing.
alert_emailNoOptional: e-mail alerts for the notify_if thresholds - 'true' for the account's own address, or an address. One e-mail per event, at most 50 a day per tracking. 'false' detaches. Works with or without webhook_url.
webhook_urlNoOptional: an https URL Logimu POSTs to when a notify_if threshold fires on a new observation (signed X-Logimu-Signature: sha256=HMAC-SHA256(secret, body); the secret is returned once in webhook_secret). An empty string detaches it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / asins / description
      Previous value: -"Bulk (2026-10-14): up to 1,000 ASINs in one call - with action=track all get the same interval / ttl_days / alerts (results[] in input order: created / renewed / refused / invalid, the allowance consumed in input order, never all-or-nothing); with action=stop they are stopped; with action=sync they are the full list the active set becomes."New value: +"Bulk (2026-10-14): up to 10,000 ASINs in one call - with action=track all get the same interval / ttl_days / alerts (results[] in input order: created / renewed / refused / invalid, the allowance consumed in input order, never all-or-nothing); with action=stop they are stopped; with action=sync they are the full list the active set becomes."
    • changedInput schema / properties / ids / description
      Previous value: -"With action=stop: several tracking ids at once (up to 1,000)."New value: +"With action=stop: several tracking ids at once (up to 10,000)."
  2. Changed2 schema fields changed
    • changedInput schema / properties / interval / description
      Previous value: -"How often the lane re-reads the all-offers page. A shorter interval costs more of the daily allowance (1h = 24 snapshots a day, 2h = 12, 4h = 6, 12h = 2, 24h = 1)."New value: +"How often the lane re-reads the product (see read). A shorter interval costs more of the daily allowance (1h = 24 snapshots a day, 2h = 12, 4h = 6, 12h = 2, 24h = 1; twice that with read=product_page)."
    • addedInput schema / properties / read
      Added value: +{
      +  "default": "offers",
      +  "description": "Which page each read fetches (2026-10-29): offers (default) = the all-offers page (buy box, price, every offer, stock); product_page = the product page and its offers page, so the sales rank is read too: every reading lands in the product tool's bsr_points_hot, and its offers page in buybox_price_points_hot as with offers. A product-page read draws 2 snapshots of the allowance (12h = 4 a day). Like interval, every call sets it: tracking the same ASIN again without read switches it back to offers.",
      +  "enum": [
      +    "offers",
      +    "product_page"
      +  ],
      +  "type": "string"
      +}
  3. Changed1 schema field changed
    • changedInput schema / properties / action / description
      Previous value: -"track (default) creates or renews the tracking(s); stop ends one or many at once; sync (2026-10-14) makes the key's active set on one marketplace EQUAL to asins: missing ones are created, active ones not listed are stopped, the rest are left as they are - dry_run first to see the counts."New value: +"track (default) creates or renews the tracking(s); stop ends one or many at once; sync (2026-10-14) makes the account's active set on one marketplace EQUAL to asins: missing ones are created, active ones not listed are stopped, the rest are left as they are - dry_run first to see the counts."
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false and idempotentHint=true; the description adds the real behavioral profile: a plan-based snapshot allowance rather than credits, granted_interval fallback when only a coarser interval fits, pending ~10 minutes in the lane, plan-lapse retention of 7 days then pause, stop semantics (allowance released, row listed 30 days as stopped), sync making the active set equal to a list, and per-day email caps. Nothing contradicts the 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 verb and the mechanism, and nearly every sentence carries operational detail. It is very dense and somewhat sprawling (STSATE abbreviations, dated changelog markers, marketplace list repeated from the schema), so it reads longer than strictly necessary.

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 13-parameter, nested, enum-heavy, no-output-schema mutation tool, the description covers cost, plan limits, return fields, bulk/sync, stop semantics, stock-state definitions and supported marketplaces. Nothing an agent needs to invoke it correctly 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% and the schema descriptions are already extremely detailed (read's 2-snapshot cost, interval-to-snapshot mapping, notify_if semantics), so the description can only add framing. It does add useful cross-parameter meaning — read interacts with interval and with idempotent re-track resetting read to offers — but much of the parameter exposition overlaps the schema rather than extending it.

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?

A specific verb (TRACK) plus resource (Amazon ASIN in the hot lane) and the mechanism (re-read all-offers page at an interval, history into buybox_price_points_hot). It explicitly contrasts with the sibling `product` tool for reading data, so an agent can distinguish scheduling from fetching.

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?

Contains an explicit USE WHEN list (repricing, MAP/buy-box monitoring, launch, deal, book rank) and a DON'T USE clause pointing at product/offers for reads. Also says re-posting the same ASIN renews it, which resolves an ambiguity an agent would otherwise hit.

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.