Skip to main content
Glama
Amazon Product, Price, and Stock Tracker MCP Server

Amazon Product, Price, and Stock Tracker MCP Server

Read Amazon price and stock

track_amazon_products
Read-only

Monitor Amazon product prices, stock, seller, and ratings across nine marketplaces, and return change rows when a price moves or stock status changes between runs.

Instructions

Read the current Amazon buy box price, list price, stock status, seller, and rating for ASINs or product URLs on 9 marketplaces, priced for that marketplace's delivery country. Keeps the last reading between runs and returns a change row when a price moves or a product goes out of or back into stock. Costs 0.0056 USD per product on amazon.com and amazon.ca, 0.015 USD elsewhere, plus a run start.

Input Schema

NameRequiredDescriptionDefault
productsNoASINs or Amazon product URLs, up to 1,000 per run. A URL uses the marketplace in the URL; a bare ASIN uses the Marketplace setting.
state_keyNoOptional name for the set of last readings, when you keep several separate tracking lists. Letters, numbers, dots, dashes, underscores.
proxy_modeNoauto (default): amazon.com and amazon.ca are read through the Apify proxy pool with residential as the fallback; other marketplaces use residential addresses in that country, because Amazon prices for the delivery country. residential: every product uses residential addresses in its marketplace country and is billed as product-row-local.
marketplaceNoThe store a bare ASIN is read from.
track_changesNotrue (default) or false. With true, the actor keeps each product's last reading in a key value store in your account, and a later run writes a change row when the price moves or the product goes out of or back into stock.
max_charge_usdNoOptional. The run stops before a charge that would pass this amount. Summary rows are always returned.
previous_snapshotNoOptional. Rows from an earlier run of this actor, as a JSON list. When given, changes are computed against these rows, not the stored readings.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A3.9/5.0
Behavior4/5

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

Goes well beyond the annotations: it discloses per-product cost with a marketplace-dependent tier, a run start charge, cross-run state kept in a key-value store, and change-row emission when price or stock moves. The state persistence slightly qualifies the readOnlyHint=true annotation, since the tool writes to your account's store, but it does not modify the products being read, so this is disclosure rather than contradiction. Missing details like rate limits or failure behavior for invalid ASINs keep it from a 5.

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?

Three sentences, front-loaded with what is returned before moving to state behavior and cost. Every sentence carries information, though the pricing sentence is dense and could be split for scanability.

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

Completeness4/5

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

No output schema exists, yet the description names the returned fields and the change-row concept, and it covers cost, state, and marketplace localization. With zero required parameters, the description could say more about defaults and what happens on an empty products array, but the essentials for correct invocation are present.

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 coverage is 100%, so every parameter is already documented and the baseline of 3 applies. The description adds the rationale that prices are localized to the marketplace's delivery country, which explains why marketplace and proxy_mode matter, but it introduces no syntax or constraint details the schema lacks.

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 (Read) and resource (Amazon buy box price, list price, stock, seller, rating) with explicit input scope (ASINs or product URLs) and breadth (9 marketplaces). The marketplace-localized pricing note further pins down what the returned numbers mean, so an agent knows exactly what it gets back.

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

Usage Guidelines3/5

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

No sibling tools exist, so there is nothing to route against, but the description still gives no explicit 'use this when' framing or exclusions. Usage is only implied by the cost and per-product billing model, which lets an agent infer this is a batch lookup tool, not a discovery or search tool.

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

Deploy Server

Other Tools