Skip to main content
Glama

Logimu

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). USE WHEN the user wants to watch a product's price, buy box or seller count more often than our normal cadence: repricing, MAP and buy-box monitoring, a competitor's listing, a launch, a deal. 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, granted_interval, requested_interval, snapshots_per_day, 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 1,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

TableJSON 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 1,000).
asinNoThe product's 10-character Amazon ASIN (one product). Or give asins.
asinsNoBulk (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.
actionNotrack (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.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 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).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. 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, idempotentHint=true, destructiveHint=false, openWorldHint=false; the description adds cost (0 credits), plan allowance tiers and exhaustion behavior with upgrade link, granted_interval fallback, ~10 minute pending window, stop semantics and the 30-day stopped row retention, paid-plans-only gating, and supported marketplaces. Nothing here contradicts the idempotent/destructive 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 core verb and organized under clear capitalized signposts (USE WHEN, DON'T USE, COST, RETURNS, BULK, STOCK STATES), so an agent can scan to the needed block. It is however very long, and the interval cost table, ttl_days lapse behavior, notify_if semantics and bulk rules are largely restated from the input schema rather than adding new 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?

No output schema exists, and the description compensates with an explicit RETURNS field list (id, asin, status, interval, granted_interval, snapshots_per_day, expires_at, in_lane, pending, allowance, etc.) plus the stock-state vocabulary. Combined with cost, plan gating, marketplace scope and alert semantics, an agent has everything needed to call this 12-parameter, multi-mode tool 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 description coverage is 100%, so the baseline is 3 and the schema already carries per-parameter detail. The description still adds cross-parameter meaning the schema does not: the allowance cost model tied to interval (Solo 2,500/day = 416 products at 4h), the interaction of action=stop with id/asin+country/ids/asins, and action=sync's dry_run-first workflow.

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 ('TRACK a product: pin an Amazon ASIN into our hot lane') plus the resulting mechanism (all-offers page re-read on an interval, snapshots landing in the product's history). It explicitly distinguishes itself from siblings by naming 'product' and 'offers' as the read tools it is not, and 'list_tracked' as the id source.

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 an explicit USE WHEN list (repricing, MAP/buy-box monitoring, competitor listings, launches, deals) and an explicit DON'T USE ('to read data (product, offers): tracking only schedules the reads'). It also names the alternative cadence ('more often than our normal cadence') and the idempotent re-post behavior.

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.