Skip to main content
Glama

logimu-shopping-mcp

deals

Read-onlyIdempotent

LIVE Amazon Today's Deals: the deals page of one marketplace, read from Amazon at request time and filtered the way Amazon's own page filters it - department (category_id), deal collection (deal_types: lightning_deal, trending, coupons, started_today, ending_today; or any collection id an answer lists), percent off, price, Prime Exclusive, minimum rating, brand. USE WHEN the user asks what is on sale or discounted on Amazon right now, wants today's deals or lightning deals in a department, deals above a discount or under a price, coupon deals, or deals ending today. DON'T USE for one product's price history or past price drops (product with offer_history), for who sells a product right now (offers), for a keyword search (serp, shopping) or for what sells best in a category (bestsellers). RETURNS deals[] (position, asin, title, link, image, deal_id, deal_link, deal_type e.g. BEST_DEAL / LIGHTNING_DEAL, is_lightning_deal, deal_state, percent_claimed, ends_at, deal_price and list_price {value, currency, symbol, label}, percent_off, savings, deal_badge, is_prime_price, coupon {text, amount, promotion_id, link}, brand, brand_id, department_ids, product_group, product_type, variations), categories[] (category_id, name, selected: the departments to pass back as category_id), collections[] (id, name: pass back as collection), facets (brands with ids, reviewRating, price and percentOff ranges, accessType), selected_filters, filter_check (per requested filter: applied / not_applied / unverified), pagination (page, page_size, pages_fetched, start_index, returned, has_more, partial), amazon (marketplace_id, locale, currency), observed_at and cached. HONESTY: an empty deals list is a real answer (e.g. no lightning deals running at this hour); a filter Amazon did not apply (filter_check not_applied, e.g. a category_id that is not one of the marketplace's deals departments) is refused as an error, never billed, instead of serving the unfiltered page; unverified filters are served, so say so before relying on them; there is no total count (has_more says whether the last page came back full) and no deal start time; ends_at only where Amazon shows a countdown; list_price is Amazon's reference price with its own label (RRP, Was, Typical ...), null when the page shows none. LATENCY is SECONDS: ~10-30s a page (pages=5 up to ~2 min); an identical request within 15 min may come from our cache in milliseconds. 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). 1 credit per deals page fetched that returned at least one deal, whatever its size (30, 60, 90 or 120 deals are all 1 credit, so page_size=120 gives the most deals per credit), cached or fresh; a page with no deals, an empty list, a blocked or busy fetch and bad input are never billed.

Input Schema

NameRequiredDescriptionDefault
urlNoOptional: an Amazon deals URL (/deals, /events/deals or /gp/goldbox). The host decides the marketplace and its query string is kept (e.g. a filtered deals page copied from the browser).
pageNo1-based page of the deals list.
brandNoA brand id from facets.brands of a previous answer (e.g. 811979|dreame).
pagesNoConsecutive pages merged into one answer, starting at page (stops early on a short page). 1 credit per page that returned deals.
countryNoThe Amazon marketplace whose deals page to read. Required unless url is given; with url it must match the URL's marketplace.
discountNoRainforest form of min_discount (50_percent_off = at least 50% off). Not together with min_discount.
max_priceNoMaximum deal price in the marketplace currency (Amazon applies whole units; a fraction is rounded up).
min_priceNoMinimum deal price in the marketplace currency (Amazon applies whole units; a fraction is rounded down).
page_sizeNoDeals per page; Amazon serves steps of 30 only. Every page is 1 credit whatever its size, so 120 gives the most deals per credit.
collectionNoAny other collection id from collections[] of a previous answer (collections differ per marketplace and over time). Not together with deal_types.
deal_typesNoOne of Amazon's stable deal collections. Not together with collection.
category_idNoA deals department id from categories[] of a previous answer (Amazon applies one department at a time).
max_discountNoMaximum percent off (0-100). Same marketplaces as min_discount (refused on it, fr, es).
min_discountNoMinimum percent off (0-100). Amazon applies it on the us, uk, de, ca, au, mx, jp and br deals pages; amazon.it, amazon.fr and amazon.es have no discount filter, so there it is refused (not_applied, never billed): ask without it and filter on percent_off.
minimum_ratingNoOnly products rated at least this many stars (1-4).
prime_exclusiveNotrue = Prime Exclusive deals only.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / max_discount / description
      Previous value: -"Maximum percent off (0-100)."New value: +"Maximum percent off (0-100). Same marketplaces as min_discount (refused on it, fr, es)."
    • changedInput schema / properties / min_discount / description
      Previous value: -"Minimum percent off (0-100)."New value: +"Minimum percent off (0-100). Amazon applies it on the us, uk, de, ca, au, mx, jp and br deals pages; amazon.it, amazon.fr and amazon.es have no discount filter, so there it is refused (not_applied, never billed): ask without it and filter on percent_off."
  2. Added

TDQS

A4.5/5.0
Behavior3/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description is not the sole source of that information. The description does add substantial operational context: filter refusal vs. verified application (filter_check), that empty results are legitimate answers, absence of a total count and deal start time, and the 15-minute cache window. However, it omits some details that would help an agent plan calls, such as whether `pages` pagination interacts with `page` in a specific order beyond 'starting at page', and what 'partial' in pagination means. A 3 reflects solid but not exhaustive behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and scope, then USE WHEN, DON'T USE, RETURNS, HONESTY, LATENCY, MARKETPLACES, COST. Every section serves a distinct invocation concern. Although long, the length is justified by 16 parameters, no output schema, and the need to document side effects and cost. It avoids gratuitous repetition, though the credit rule is stated twice (in COST and in `page_size`).

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, so the description carries the return-value burden. It enumerates the full shape of `deals[]`, `categories[]`, `collections[]`, `facets`, `selected_filters`, `filter_check`, `pagination`, `amazon`, `observed_at` and `cached`. It also discloses the critical honesty constraints (empty list is real, unapplied filter is refused and unbilled, unverified filters are served) that an agent needs to interpret results safely.

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?

With 100% schema description coverage, baseline is 3. The description adds meaning beyond the schema: it explains that `deal_types` values are 'stable deal collections', that `category_id` values come from `categories[]` of a prior answer, that `collection` ids vary by marketplace, and that `page_size=120` maximizes deals per credit. These are practical semantics that help an agent choose values correctly, though some overlap with schema text.

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?

Opens with a specific verb+resource ('LIVE Amazon Today's Deals ... the deals page of one marketplace') and immediately enumerates the filter surface (department, deal collection, discount, price, Prime, rating, brand). An agent can distinguish this from `offers`, `product`, `serp`, `shopping` and `bestsellers` without opening anything else.

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 block enumerates concrete user intents (today's deals, lightning deals in a department, coupons, deals ending today), and the DON'T USE block names four sibling tools and the exact scenario that routes to each. Both the positive and negative routing conditions are stated.

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.

Resources