Search 100+ US retailers, 260M+ products with real-time pricing, stock, and price history. Documentation - https://www.lemmebuyit.com/developer Homepage - https://www.lemmebuyit.com
Scored across 12 tools
Most tools have clearly distinct purposes: discovery, product detail, price history, stock, eligibility, promotions, and service status are separated well. There is some potential overlap between get_product_price_history, get_amazon_asin_price_history, and get_retailer_product(response_format="full"), but the descriptions make the intended use cases reasonably clear.
All tool names use consistent snake_case with a predictable verb_noun or verb_noun_noun structure (e.g. find_flips, get_retailer_product, search_promotions, check_listing_eligibility). The few special cases, such as check_skill_run and get_status, still fit the overall convention.
Twelve tools is well within a reasonable range for a multi-retailer resale intelligence server. Each tool appears to earn its place by covering a specific part of the workflow: discovery, product lookup, pricing, stock, promotions, eligibility, plan checks, and health.
The surface covers the core resale workflow well: retailer discovery, category browsing, product search/detail, price history, stock, promotions, Amazon gating, and plan enforcement. Minor gaps exist around saved workflows/alerts or more direct Amazon-side product lookup beyond price history, but agents can work around these.
Check whether YOUR connected Amazon seller account can list each ASIN (ELIGIBLE / GATED / RESTRICTED / UNKNOWN). Pass the ASINs you want to verify. If the result is not_connected, tell the user to connect their Amazon seller account and stop. Verify live with get_retailer_product / check_listing_eligibility before buying.
| Name | Required | Description | Default |
|---|---|---|---|
| asins | Yes | Amazon ASINs to check, 1-200. | |
| conditionType | No | Listing condition, defaults to "new_new". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely new behavioral context: the four possible result states, the special not_connected branch and the required agent response, and a caveat that eligibility should be re-verified live. It does not mention rate limits, latency, or whether results can go stale.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the core purpose and outcome values before the procedural branches. The final line naming 'get_retailer_product / check_listing_eligibility' is slightly muddled since one of those is this same tool, costing a point on structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by naming the four result states and the not_connected failure mode, which is the critical thing an agent needs to branch on. Coverage is solid for a two-parameter read tool; only rate-limiting and batch-size behavior are left unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, including the 1-200 bound on asins and the default for conditionType, so the schema carries parameter semantics. The description only says to pass the ASINs and never explains conditionType's effect on the ELIGIBLE/GATED outcome, adding little beyond the structured field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (check), resource (listing eligibility), and scope (YOUR connected Amazon seller account), and enumerates the exact outcome vocabulary (ELIGIBLE / GATED / RESTRICTED / UNKNOWN). An agent can distinguish this from price-history or product-lookup siblings without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear operating instructions: pass the ASINs to verify, and if the result is not_connected, stop and tell the user to connect their account. It also points at get_retailer_product for live verification before buying. It stops short of stating explicit when-not conditions or which sibling to prefer for large batches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reserve ONE run of a LemMeBuyIt skill against your plan's daily limit. Call this exactly once at the start of a skill. If allowed is false, stop and tell the user the plan_notice message (the daily limit was reached); do not continue the skill.
| Name | Required | Description | Default |
|---|---|---|---|
| skill_id | Yes | The skill id, e.g. "resale-arbitrage-scan". | |
| capability | No | Optional capability slice for usage analytics: one of deal|resale|coupon|watch|full. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag this as non-read-only and non-idempotent; the description adds real context on top of that by naming the consumed resource (daily quota), the exact-once calling contract, and the output fields `allowed` and `plan_notice` even though no output schema exists. It does not say whether a reserved run is refunded if the skill aborts, which is the one behavioral gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, zero waste, and the critical constraint (reserve ONE run, once) is front-loaded before the conditional failure handling. Every sentence carries a distinct actionable instruction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a quota-gating call with no output schema, the description supplies the missing return semantics (allowed, plan_notice) and the required agent behavior on denial. An agent has everything needed to invoke and act on the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so `skill_id` and `capability` (including its deal|resale|coupon|watch|full slice) are already documented in the schema. The description's phrase "a LemMeBuyIt skill" adds only marginal framing and repeats no parameter syntax, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (reserve) and resource (one run of a LemMeBuyIt skill) plus the scoping constraint (against the plan's daily limit). Nothing in the sibling list does anything similar, so an agent can immediately tell this apart from pricing/history/listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit call timing ("exactly once at the start of a skill") and an explicit branch on the result ("If allowed is false, stop and tell the user the plan_notice message ... do not continue the skill"). Both the when-to-use and the failure path are spelled out rather than inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find profitable resale candidates at a retailer in one call. Returns product families (variants collapsed) from the refreshed catalog ranked by ROI after marketplace fees, priced against the better of the live Amazon buy box and the Walmart cross-match (each row names the winning marketplace), with dead / parked-at-MSRP / case-pack / mismatched listings removed and a BUY or THIN call on every row, plus a coverage summary. Candidates are not gated on an on-sale flag: any price-changed item that clears the ROI screen surfaces. Set window:"today" for the daily-deals report (items refreshed today). Set retailer_id to "all" to scan across stores. To scan a whole merchandising category (e.g. every shoe/apparel or electronics store, including feed-based stores the daily scan misses), set retailer_id:"all" and pass vertical (e.g. "shoes_apparel"). On plans with paging, page the full ranked list via meta.next_cursor; the Free plan returns the top 10 rows. For ONE store, set retailer_id to that store and exhaustive:true to page its ENTIRE ROI-screened catalog (not just the top deals), served from a daily full-catalog precompute so it never times out; walmart is excluded. These are paper calls: shortlist, then verify live with get_retailer_product / check_listing_eligibility before buying. Links may be affiliate links; responses include an affiliate_disclosure.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | No | Brand filter (exact match). | |
| limit | No | Rows per page. Default 25. The normal rundown caps at 100/page; an exhaustive full-store scan allows up to 1000/page so a whole-store workbook is a handful of pages. Free tier is capped to the top 10. | |
| cursor | No | Pagination cursor. Omit for the first page; then pass the prior response's meta.next_cursor verbatim to page through the full rundown (paid tiers only). On an exhaustive scan it is an opaque token - keep paging until meta.has_more is false. | |
| window | No | Time window for candidates. "today" = items refreshed since 00:00 UTC today (the daily-deals report); "week" = last 7 days; "all" (default) = the full refreshed catalog. Candidates are not gated on an on-sale flag - any price-changed item that clears the ROI screen surfaces. Sales rank (BSR) is never a filter. | |
| min_net | No | Minimum net profit per unit in USD. Default 3.00. | |
| min_roi | No | Minimum ROI after fees, as a fraction (0.20 = 20%). Default 0.20. | |
| category | No | Category filter (exact match). | |
| vertical | No | Scan every store in a merchandising vertical (10-41 stores) instead of the daily-deals changes feed. Covers feed-based stores that the "all" changes scan misses. Inherently cross-retailer: when set, retailer_id is ignored and the scan always spans the vertical's member stores (set retailer_id:"all"). Use for "find shoe deals / apparel flips / electronics to resell" style asks. | |
| max_price | No | Maximum retailer buy price (USD). | |
| min_price | No | Minimum retailer buy price (USD). | |
| exhaustive | No | Store-level FULL-CATALOG scan. With a specific retailer_id (not "all"), returns that store's COMPLETE ROI-screened resale catalog - every matched product, not a top sample - paged to completion via meta.next_cursor (paid tiers only). Served from a daily precompute (<=24h fresh), so it does not time out. Ignored for retailer_id:"all" / vertical, for window:"today", and for walmart (never full-scanned). Shortlist the winners, then verify live with get_retailer_product / check_listing_eligibility before buying. | |
| retailer_id | Yes | Retailer id (e.g. "kohls", "walmart"), or "all" to scan across stores and merge the results. For a whole merchandising category (e.g. every shoe/apparel store), set retailer_id:"all" and pass `vertical`. | |
| include_thin | No | Include THIN rows (profitable but under min ROI). Default false. | |
| referral_pct | No | Marketplace referral fee as a fraction of resale price. Default 0.20. | |
| fulfillment_fee | No | Flat per-unit fulfilment fee in USD. Default 5.00. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld, yet the description adds substantial context beyond them: filtering rules (dead, parked-at-MSRP, case-pack, mismatched removed), the BUY/THIN verdict per row, fee-adjusted ROI against the better of Amazon buy box and Walmart cross-match, a coverage summary, Free-plan top-10 cap, <=24h precompute freshness so exhaustive scans never time out, Walmart exclusion, and affiliate-disclosure caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is long, but front-loaded with the return contract first and then the mode-selection rules, and nearly every sentence carries operative information. There is mild duplication between the prose and the schema's exhaustive/window/vertical descriptions, which keeps it just short of a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter, no-output-schema tool, the description compensates fully: it explains the ranked return structure, the BUY/THIN verdict, coverage summary, pagination via meta.next_cursor, plan-tier limits, data freshness, and affiliate disclosures. An agent has everything needed to call and interpret it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the per-field schema already documents each parameter and the baseline is 3. The description adds genuine cross-parameter interplay not captured per-property — that vertical overrides retailer_id, that exhaustive is ignored for retailer_id:"all"/vertical/window:"today"/walmart, and that cursor chains via meta.next_cursor.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Find profitable resale candidates at a retailer') and immediately specifies the return shape: product families from the refreshed catalog ranked by ROI, with the winning marketplace named per row. It also implicitly separates itself from the verification siblings by framing results as paper calls to shortlist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit routing for every major mode: window:"today" for the daily-deals report, retailer_id:"all" for cross-store, vertical for category-wide scans including feed-based stores, and exhaustive:true for a single store's full catalog. It also names the follow-up tools (get_retailer_product / check_listing_eligibility) and warns the results must be verified before buying.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID. Weekly Amazon price history for a specific ASIN: Buy Box, lowest 3P-new, list price, sales rank, and offer counts over up to 104 weeks. Requires a paid plan.
| Name | Required | Description | Default |
|---|---|---|---|
| asin | Yes | Amazon ASIN (e.g. "B09BF2YX6W"). Get it from a product's `asins` field. | |
| weeks | No | Trailing weeks to return (1-104, default 12). Weeks with no samples are omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new operational context: this is a paid endpoint, the granularity is weekly, and the window tops out at 104 weeks. Cost/auth disclosure is exactly the kind of thing annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, with the billing gate front-loaded as the very first word and the metric list packed into the second sentence. Nothing can be trimmed without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description compensates well by naming the five returned series. Combined with the paid-plan prerequisite and the 104-week horizon, an agent has enough to call and interpret the tool; only the sibling-relationship with get_product_price_history is left unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both parameters (asin, weeks) are already fully documented in the schema, including the 1-104 range, the default of 12, and the omission of empty weeks. The description restates the 104-week ceiling but adds no format or semantics beyond that, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Weekly Amazon price history for a specific ASIN') and enumerates the exact metrics returned (Buy Box, lowest 3P-new, list price, sales rank, offer counts), so an agent knows precisely what comes back. It does not, however, differentiate itself from the sibling get_product_price_history, which is the obvious point of confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Requires a paid plan' is a useful gating condition, so the agent knows when the call is viable. But there is no guidance on when to choose this over get_product_price_history or get_retailer_product, and no exclusion criteria beyond the billing prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID. Live Kohl's per-UPC (per-variant) stock counts for a batch of Kohl's products. Pass products as an array of Kohl's PDP URLs and/or bare "prd-" web IDs (affiliate/redirect links are followed server-side to the canonical kohls.com PDP). Returns one row per product with status ("ok" or "stock_unavailable"), total_in_stock (sum of online-available units across variants), and a variants[] breakdown (upc, sku, qty, availability, in_stock). Counts are a live snapshot and move constantly. stock_unavailable means the fetch fleet could not read the page (Akamai challenge / delisted / no stock JSON) — it is NOT a zero count; never turn it into 0. Send at most 100 products per call and loop in chunks for longer lists. Kohl's only. Requires a paid plan (mcp_standard, mcp_pro, or enterprise_api).
| Name | Required | Description | Default |
|---|---|---|---|
| products | Yes | Kohl's PDP URLs and/or bare "prd-<id>" web IDs. 1-100 per call; chunk longer lists across multiple calls. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover read-only/idempotent, but the description adds the critical semantics: `stock_unavailable` is a fetch failure, not a zero, and must never be coerced to 0; counts are a live snapshot that moves; affiliate/redirect links are followed server-side; and access requires a paid plan tier.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with 'PAID' and the core purpose, then error semantics and limits. Some repetition of the 100-item cap already in the schema, but every sentence carries operational weight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 fully specifies the return shape (`status`, `total_in_stock`, `variants[]` with upc/sku/qty/availability/in_stock) plus the failure-mode interpretation and batch limit — everything needed to call and interpret results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already documents the array, so the baseline is 3; the description goes further by explaining accepted input forms and that affiliate/redirect URLs are resolved to canonical PDPs server-side, which is behavior the schema does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — live per-UPC Kohl's stock counts for a batch of products — with scope ('Kohl's only') that separates it from retailer-agnostic siblings like get_retailer_product or search_retailer_products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete operating conditions: max 100 products per call, loop in chunks for longer lists, Kohl's-only scope, and a paid-plan requirement. It does not explicitly name a sibling alternative for other retailers, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PAID. Weekly price history for a retailer product by SKU/ID — merges the retailer price series with the mapped Amazon ASIN series (Buy Box, lowest 3P-new, list price, sales rank) over up to 104 weeks. Requires a paid plan.
| Name | Required | Description | Default |
|---|---|---|---|
| weeks | No | Trailing weeks to return (1-104, default 12). Weeks with no samples are omitted. | |
| product_id | Yes | The product's unique SKU/ID within the retailer's catalog. Pass the 'product_id' field from search_retailer_products results (equivalently, its 'unique_merchant_sku'). Note: the search result's 'id' field is an internal cursor key and is NOT resolvable here. | |
| retailer_id | Yes | Retailer identifier (e.g. "walmart"). Use list_retailers to get valid IDs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the bar is lower. The description adds genuinely non-annotated traits: a paid-plan entitlement requirement, the 104-week maximum window, and the fact that weeks without samples are omitted from the merged series.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The scope and entitlement are front-loaded in a compact single sentence with no filler. The only waste is redundancy: 'PAID.' and 'Requires a paid plan.' state the same constraint twice.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does the heavy lifting by enumerating the returned series (Buy Box, lowest 3P-new, list price, sales rank) and the merge behavior, plus entitlement and time window. The remaining gap is how the merged series is shaped/aligned per week, which an agent calling this correctly would benefit from knowing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description corroborates the 'up to 104 weeks' bound and the SKU/ID lookup identity but adds no syntax or format detail beyond what the schema already documents for weeks, product_id, and retailer_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('weekly price history for a retailer product by SKU/ID') and immediately specifies the distinguishing scope: it merges the retailer series with the mapped Amazon ASIN series, which is what separates it from the sibling get_amazon_asin_price_history. An agent can identify the data it returns (Buy Box, lowest 3P-new, list price, sales rank) without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'PAID' marker and 'Requires a paid plan' sentence act as a gating precondition for use, which is real guidance. However, it never says when to prefer this over the plain ASIN history sibling, nor any other alternative or exclusion; the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List product categories available for a specific retailer. Use this to discover valid category paths before filtering products by category.
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | Signed pagination cursor from the previous response (next_cursor). Omit for the first page. | |
| limit | No | Max categories per page (1-500, default 100). Paginate via next_cursor for full lists. | |
| retailer_id | Yes | The retailer identifier (e.g. "walmart", "target", "homedepot"). Use list_retailers to get valid IDs. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds no further behavioral context such as whether categories are hierarchical, whether the list is exhaustive, or how pagination should be driven (the schema handles cursors). Adds little beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, zero padding, and the purpose is front-loaded before the usage hint. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only listing tool with full schema coverage and no output schema, the description gives the agent enough to call it correctly and understand its role in a retailer → category → product workflow. It could note pagination or category path shape, but nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so retailer_id, limit and after are all documented in the schema, including the cross-reference to list_retailers. The description adds no parameter detail beyond what the schema provides, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource with scope: 'List product categories available for a specific retailer.' It clearly distinguishes itself from the product-level siblings (search_retailer_products, get_retailer_product) by operating on categories, though it doesn't name those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use this to discover valid category paths before filtering products by category' gives a concrete context for invocation and a downstream dependency. There's no explicit when-not guidance, but the usage trigger is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details for a specific product by its retailer SKU/ID. Returns compact items by default (~14 fields); pass response_format="full" for complete product data including resale intelligence such as Amazon pricing, profitability, and catalog metrics. Links may be affiliate links; responses include an affiliate_disclosure.
| Name | Required | Description | Default |
|---|---|---|---|
| product_id | Yes | The product's unique SKU/ID within the retailer's catalog. Pass the 'product_id' field from search_retailer_products results (equivalently, its 'unique_merchant_sku'). Note: the search result's 'id' field is an internal cursor key and is NOT resolvable here. | |
| retailer_id | Yes | Retailer identifier (e.g. "walmart", "target"). Use list_retailers to get valid IDs. | |
| response_format | No | Response shape. "compact" (default) returns a ~14-field subset; "resale" adds the Amazon resale signals (asins, amazon_price, profitability, trimmed amazon_marketplace) without the long product_description; "full" returns complete product data with resale intelligence. | compact |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond the structured fields: the default response shape and field count, and the fact that links may be affiliate links with an accompanying affiliate_disclosure. It does not cover error/pagination behavior, keeping 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each earning its place: purpose first, then the response-shape tradeoff, then the affiliate disclosure. Nothing is padded and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining what comes back, and it does so via the compact/full distinction and the affiliate disclosure. It leaves minor gaps (pagination, error cases, exact link placement) that are low-risk for a read-only idempotent lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and each property already documents its role in detail, so the baseline is 3. The description's note about compact returning ~14 fields and full including resale intelligence largely restates what the response_format schema description already says, adding little beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Get details') and resource ('a specific product by its retailer SKU/ID'), which an agent can distinguish from the sibling search_retailer_products without opening either schema. The SKU-keyed singular lookup versus the plural search tool is clear from the phrasing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear conditional guidance for the default vs response_format="full" case ('Returns compact items by default; pass ... for complete product data'), and the schema reinforces the workflow by pointing at search_retailer_products for product_id and list_retailers for retailer_id. It stops short of explicitly naming when NOT to use this tool, so it is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the health and operational status of the LemMeBuyIt MCP service.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only the scoping phrase 'health and operational status' and discloses nothing extra such as what is checked, auth needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with zero waste. The resource is named immediately and nothing redundant is added.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter health check this is nearly sufficient, but with no output schema the description never indicates what the status result contains (e.g., per-dependency health, version, latency). An agent knows when to call it but not what it gets back.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters (100% schema coverage trivially), so there is nothing to document. Baseline 4 applies; no parameter gaps exist to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Check) and resource (health and operational status of the LemMeBuyIt MCP service). No sibling tool does a service health check, so an agent can immediately distinguish it from the search/pricing/retailer tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the purpose — call it to verify the service is up — but there is no explicit when-to-use or when-not-to-use guidance, nor any mention of alternatives. Adequate but leaves the trigger condition to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all retailers available to your LemMeBuyIt connection (100+ U.S. retailers). Call this to discover valid retailer IDs before searching products.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds useful context beyond that: the result set is connection-scoped and comprises 100+ U.S. retailers, which sets expectations about breadth and locality. It stops short of describing output format or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste, and the payoff statement (discover retailer IDs before searching) is front-loaded right after the resource definition. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-param, no-output-schema discovery tool, the description supplies the essentials: what comes back (retailer IDs), how many (100+), and the workflow position (before product search). Only the exact return shape is unspecified, and the absence of an output schema makes that a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. Nothing in the description misleads about inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (retailers) plus scope: those available to the LemMeBuyIt connection, 100+ U.S. retailers. An agent can immediately tell this is the retailer-enumeration tool and not, say, get_retailer_categories or search_retailer_products.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to call it to discover valid retailer IDs before searching products, which gives a clear when-to-use trigger. It does not name or exclude alternatives such as get_retailer_categories, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search current promotions, coupons, sales, and deals across retailers. Filter by retailer, category, promotion type, coupon availability, or expiry; full-text search over titles/descriptions; cursor pagination via "after". Returns active promotions by default (set active=false to include expired/upcoming).
| Name | Required | Description | Default |
|---|---|---|---|
| after | No | Signed pagination cursor from the previous response (next_cursor). Omit for the first page. | |
| limit | No | Max promotions per page (1-100, default 25). Paginate via next_cursor for more. | |
| active | No | When true (default), only return promotions currently within their active date window. Set false to include expired/upcoming promotions. | |
| sort_by | No | Sort order. Omit for the default ordering. Must be consistent across paginated requests. | |
| category | No | Filter by category (exact match, e.g. "Apparel"). | |
| retailer_id | No | Filter to one or more retailers. Comma-separated retailer IDs (e.g. "kohls,macys"). Use list_retailers to get valid IDs. Omit to search all retailers. | |
| search_query | No | Full-text search over the promotion title and description. | |
| promotion_type | No | Filter by promotion type (e.g. "coupon", "percentage-off", "free-shipping"). | |
| advertiser_name | No | Filter by the brand or merchant name (exact match). | |
| has_coupon_code | No | If true, only return promotions that include a coupon code. | |
| expiring_within_days | No | Only return promotions ending within this many days from now. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, open-world, non-destructive semantics, so the bar is lower. The description adds genuinely useful behavior beyond them: active-only default with the active=false escape hatch, and cursor pagination via 'after'. It does not discuss result volume or empty-result behavior, keeping it short of 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both front-loaded: capability and filter scope first, defaults and pagination second. No filler clauses and no repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with 11 optional parameters, a fully described schema, and no output schema, the description covers the essentials an agent needs: what it searches, how to filter, the active-by-default semantic, and how to paginate. Nothing material is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 11 parameters, including the sort consistency constraint and the list_retailers cross-reference. The description restates the filter categories and pagination at a high level without adding syntax or format detail, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence names a specific verb (Search) and resource (promotions, coupons, sales, deals) plus the scope (across retailers). This cleanly separates it from product-oriented siblings such as search_retailer_products and get_retailer_product, so an agent can route correctly without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description enumerates the available filter axes and states the default active-only behavior, which implies when to use it, but it never names an alternative tool or states an explicit when-not condition. Usage is inferable rather than instructed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search and SAMPLE a retailer's catalog: text search, barcode lookups, price/discount filtering, and cursor pagination via 'after'. Returns compact items by default (~14 fields); use response_format="resale" for resale signals or "full" for everything. Per-call cap is 500 items. NOTE: this tool is for finding and sampling products, not bulk export. Paging an entire catalog one cursor at a time is slow and token-heavy. For full-catalog coverage, use exhaustive:true on find_flips with a single retailer_id on paid plans, or contact LemMeBuyIt about MCP Enterprise (admin@lemmebuyit.com). Links may be affiliate links; responses include an affiliate_disclosure.
| Name | Required | Description | Default |
|---|---|---|---|
| ean | No | Filter by EAN barcode (exact match). Comma-separated for batch lookups. | |
| mpn | No | Filter by Manufacturer Part Number (exact match). | |
| upc | No | Filter by UPC barcode (exact match). Comma-separated for batch lookups. | |
| asin | No | Filter by Amazon ASIN (exact match). Comma-separated for batch lookups. | |
| gtin | No | Filter by GTIN code (exact match). Comma-separated for batch lookups. | |
| size | No | Filter by size (exact match). | |
| after | No | Signed pagination cursor from the previous response (next_cursor). Omit for the first page. | |
| brand | No | Filter by brand name (exact match, e.g. "Nike"). | |
| color | No | Filter by color (exact match). | |
| limit | No | Max products per page (1-500, default 25). Use 25-100 for browsing; cannot exceed 500. Paginate via next_cursor for bulk traversal. | |
| model | No | Filter by product model number (exact match). | |
| on_sale | No | If true, only return products currently on sale (current_price < original_price). | |
| sort_by | No | Sort order. Omit for relevance-based sorting when using search_query. Must be consistent across paginated requests. | |
| category | No | Filter by category path (exact match). Use ">" as separator (e.g. "Electronics>Computers & Tablets>Laptops"). Use get_retailer_categories to discover valid paths. | |
| currency | No | Filter by currency code (e.g. "USD", "EUR", "CAD"). | |
| material | No | Filter by material (exact match). | |
| condition | No | Filter by condition (e.g. "New", "Used", "Refurbished"). | |
| max_price | No | Maximum price filter. | |
| min_price | No | Minimum price filter. | |
| max_rating | No | Maximum average rating (0-5 scale). | |
| max_weight | No | Maximum product weight. | |
| min_rating | No | Minimum average rating (0-5 scale). | |
| min_weight | No | Minimum product weight. | |
| lookup_type | No | Override auto-detection: "gtin" forces barcode lookup, "text" forces full-text search. | |
| min_reviews | No | Minimum number of customer reviews. | |
| retailer_id | Yes | Retailer identifier (e.g. "walmart", "target"). Use list_retailers to get valid IDs. | |
| subcategory | No | Filter by subcategory (exact match). | |
| manufacturer | No | Filter by manufacturer name (exact match). | |
| max_shipping | No | Maximum shipping cost. Use 0 for free shipping only. | |
| search_query | No | Search query. Auto-detects type: numeric 8-14 digits → GTIN barcode lookup; text → full-text search. Supports comma-separated GTINs for batch lookups. | |
| created_since | No | ISO 8601 datetime. Only return products created after this date. | |
| updated_since | No | ISO 8601 datetime. Only return products updated after this date. | |
| max_sales_rank | No | Maximum Amazon sales rank (BSR) — e.g. 1000000 to keep only items ranked under 1M. Lower = better. Paid plans only. | |
| min_sales_rank | No | Minimum Amazon sales rank (BSR). Lower rank = higher demand. Paid plans only. | |
| response_format | No | Response shape. "compact" (default) returns a ~14-field subset suitable for bulk listing; "resale" adds the Amazon resale signals (asins, amazon_price, profitability, and a trimmed amazon_marketplace with sales_rank/offer_count/buy_box/list_price) while dropping the long product_description — best for screening a whole catalog without exceeding the token cap; "full" returns complete product objects (verbose; a large page may exceed the response token cap). | compact |
| unique_merchant_sku | No | Filter by the retailer's own SKU (exact match). Comma-separated supported. | |
| max_discount_percent | No | Maximum discount percentage (0-100). | |
| min_discount_percent | No | Minimum discount percentage (0-100). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, covering the safety profile. The description adds genuinely useful behavioral context the annotations cannot: the 500-item per-call cap, the ~14-field compact default, the affiliate-link disclosure, and the warning that full response_format risks the token cap. However, return shape is largely delegated to the response_format enum rather than described here, keeping this at a solid 3 rather than a standout.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads purpose and capabilities, then narrows to the sampling-vs-export distinction and escalation. Every sentence carries information — no filler and no repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 38-parameter, no-output-schema tool, the description supplies the strategic context an agent needs: what it returns by default, the size ceiling, pagination cost, affiliate disclosure, and when to abandon it for find_flips. Nothing needed to call it correctly appears to be missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 38 parameters, including after, limit, response_format and the barcode filters. The description reinforces 'after' pagination and the response_format tradeoff but adds no syntax or format detail the schema lacks, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Search and SAMPLE a retailer's catalog') and enumerates the distinct capabilities (text search, barcode lookup, price/discount filtering, cursor pagination). It explicitly positions itself against siblings by naming find_flips for full-catalog coverage, so an agent can distinguish it from get_retailer_product and find_flips 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-not ('not bulk export... paging an entire catalog one cursor at a time is slow and token-heavy') and names the alternative with the exact switch to use instead ('exhaustive:true on find_flips with a single retailer_id on paid plans'). This is a complete routing instruction with a fallback escalation path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_kohls_stockfind_flips1 field changedInput schema / properties / exhaustive / descriptionPrevious value: -"Store-level FULL-CATALOG scan. With a specific retailer_id (not \"all\"), returns that store's COMPLETE ROI-screened resale catalog - every matched product, not a top sample - paged to completion via meta.next_cursor (paid tiers only). Served from a daily precompute (<=24h fresh), so it does not time out. Ignored for retailer_id:\"all\" / vertical, for window:\"today\", and for walmart (never full-scanned). Shortlist the winners, then run the verify-leads skill to confirm them live before buying."New value: +"Store-level FULL-CATALOG scan. With a specific retailer_id (not \"all\"), returns that store's COMPLETE ROI-screened resale catalog - every matched product, not a top sample - paged to completion via meta.next_cursor (paid tiers only). Served from a daily precompute (<=24h fresh), so it does not time out. Ignored for retailer_id:\"all\" / vertical, for window:\"today\", and for walmart (never full-scanned). Shortlist the winners, then verify live with get_retailer_product / check_listing_eligibility before buying."find_flips3 fields changedInput schema / properties / cursor / descriptionPrevious value: -"Pagination cursor. Omit for the first page; then pass the prior response's meta.next_cursor to page through the full ranked rundown (paid tiers only)."New value: +"Pagination cursor. Omit for the first page; then pass the prior response's meta.next_cursor verbatim to page through the full rundown (paid tiers only). On an exhaustive scan it is an opaque token - keep paging until meta.has_more is false."Input schema / properties / limit / descriptionPrevious value: -"Rows per page. Default 25, max 100. Free tier is capped to the top 10."New value: +"Rows per page. Default 25. The normal rundown caps at 100/page; an exhaustive full-store scan allows up to 1000/page so a whole-store workbook is a handful of pages. Free tier is capped to the top 10."Input schema / properties / limit / maximumPrevious value: -100New value: +1000find_flips1 field changedInput schema / properties / exhaustiveAdded value: +{
+ "description": "Store-level FULL-CATALOG scan. With a specific retailer_id (not \"all\"), returns that store's COMPLETE ROI-screened resale catalog - every matched product, not a top sample - paged to completion via meta.next_cursor (paid tiers only). Served from a daily precompute (<=24h fresh), so it does not time out. Ignored for retailer_id:\"all\" / vertical, for window:\"today\", and for walmart (never full-scanned). Shortlist the winners, then run the verify-leads skill to confirm them live before buying.",
+ "type": "boolean"
+}check_listing_eligibilityfind_flips3 fields changedInput schema / properties / cursorAdded value: +{
+ "description": "Pagination cursor. Omit for the first page; then pass the prior response's meta.next_cursor to page through the full ranked rundown (paid tiers only).",
+ "type": "string"
+}Input schema / properties / limit / descriptionPrevious value: -"Number of ranked rows to return. Default 25."New value: +"Rows per page. Default 25, max 100. Free tier is capped to the top 10."Input schema / properties / window / descriptionPrevious value: -"Time window for candidates. \"today\" = on-sale items updated since 00:00 UTC today (the daily-deals report); \"week\" = last 7 days; \"all\" (default) = full on-sale catalog. Sales rank (BSR) is never a filter."New value: +"Time window for candidates. \"today\" = items refreshed since 00:00 UTC today (the daily-deals report); \"week\" = last 7 days; \"all\" (default) = the full refreshed catalog. Candidates are not gated on an on-sale flag - any price-changed item that clears the ROI screen surfaces. Sales rank (BSR) is never a filter."find_flips1 field changedInput schema / properties / min_roi / descriptionPrevious value: -"Minimum ROI after fees, as a fraction (0.30 = 30%). Default 0.30."New value: +"Minimum ROI after fees, as a fraction (0.20 = 20%). Default 0.20."find_flips2 fields changedInput schema / properties / retailer_id / descriptionPrevious value: -"Retailer id (e.g. \"kohls\", \"walmart\"), or \"all\" to scan several large retailers and merge the results."New value: +"Retailer id (e.g. \"kohls\", \"walmart\"), or \"all\" to scan across stores and merge the results. For a whole merchandising category (e.g. every shoe/apparel store), set retailer_id:\"all\" and pass `vertical`."Input schema / properties / verticalAdded value: +{
+ "description": "Scan every store in a merchandising vertical (10-41 stores) instead of the daily-deals changes feed. Covers feed-based stores that the \"all\" changes scan misses. Inherently cross-retailer: when set, retailer_id is ignored and the scan always spans the vertical's member stores (set retailer_id:\"all\"). Use for \"find shoe deals / apparel flips / electronics to resell\" style asks.",
+ "enum": [
+ "shoes_apparel",
+ "general_merchandise",
+ "home_garden",
+ "electronics",
+ "sports_outdoors",
+ "health_beauty",
+ "toys_games",
+ "food_supplements",
+ "crafts_hobbies",
+ "bags_travel"
+ ],
+ "type": "string"
+}find_flips2 fields changedInput schema / properties / max_sales_rankRemoved value: -{
- "description": "Maximum Amazon sales rank (BSR). Default 250000.",
- "maximum": 9007199254740991,
- "minimum": 0,
- "type": "integer"
-}Input schema / properties / windowAdded value: +{
+ "description": "Time window for candidates. \"today\" = on-sale items updated since 00:00 UTC today (the daily-deals report); \"week\" = last 7 days; \"all\" (default) = full on-sale catalog. Sales rank (BSR) is never a filter.",
+ "enum": [
+ "all",
+ "today",
+ "week"
+ ],
+ "type": "string"
+}find_flipssearch_promotions1 field changedInput schema / properties / advertiser_name / descriptionPrevious value: -"Filter by the advertiser/brand name (exact match)."New value: +"Filter by the brand or merchant name (exact match)."get_product_price_history1 field changedInput schema / properties / product_id / descriptionPrevious value: -"The product's unique SKU/ID within the retailer's catalog (the 'unique_merchant_sku' or 'id' from search results)."New value: +"The product's unique SKU/ID within the retailer's catalog. Pass the 'product_id' field from search_retailer_products results (equivalently, its 'unique_merchant_sku'). Note: the search result's 'id' field is an internal cursor key and is NOT resolvable here."get_retailer_product1 field changedInput schema / properties / product_id / descriptionPrevious value: -"The product's unique SKU/ID within the retailer's catalog (the 'unique_merchant_sku' or 'id' field from search results)."New value: +"The product's unique SKU/ID within the retailer's catalog. Pass the 'product_id' field from search_retailer_products results (equivalently, its 'unique_merchant_sku'). Note: the search result's 'id' field is an internal cursor key and is NOT resolvable here."check_skill_runget_amazon_asin_price_historyget_product_price_historyget_retailer_product2 fields changedInput schema / properties / response_format / descriptionPrevious value: -"Response shape. \"compact\" (default) returns a ~14-field subset; \"full\" returns complete product data with resale intelligence."New value: +"Response shape. \"compact\" (default) returns a ~14-field subset; \"resale\" adds the Amazon resale signals (asins, amazon_price, profitability, trimmed amazon_marketplace) without the long product_description; \"full\" returns complete product data with resale intelligence."Input schema / properties / response_format / enumPrevious value: -[
- "full",
- "compact"
-]New value: +[
+ "full",
+ "compact",
+ "resale"
+]search_promotionssearch_retailer_products4 fields changedInput schema / properties / max_sales_rankAdded value: +{
+ "description": "Maximum Amazon sales rank (BSR) — e.g. 1000000 to keep only items ranked under 1M. Lower = better. Paid plans only.",
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+}Input schema / properties / min_sales_rankAdded value: +{
+ "description": "Minimum Amazon sales rank (BSR). Lower rank = higher demand. Paid plans only.",
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+}Input schema / properties / response_format / descriptionPrevious value: -"Response shape. \"compact\" (default) returns a ~14-field subset suitable for bulk listing; \"full\" returns complete product objects with resale intelligence."New value: +"Response shape. \"compact\" (default) returns a ~14-field subset suitable for bulk listing; \"resale\" adds the Amazon resale signals (asins, amazon_price, profitability, and a trimmed amazon_marketplace with sales_rank/offer_count/buy_box/list_price) while dropping the long product_description — best for screening a whole catalog without exceeding the token cap; \"full\" returns complete product objects (verbose; a large page may exceed the response token cap)."Input schema / properties / response_format / enumPrevious value: -[
- "full",
- "compact"
-]New value: +[
+ "full",
+ "compact",
+ "resale"
+]get_amazon_asin_price_historyget_product_price_historyget_retailer_categories2 fields changedInput schema / properties / afterAdded value: +{
+ "description": "Signed pagination cursor from the previous response (next_cursor). Omit for the first page.",
+ "type": "string"
+}Input schema / properties / limitAdded value: +{
+ "default": 100,
+ "description": "Max categories per page (1-500, default 100). Paginate via next_cursor for full lists.",
+ "maximum": 500,
+ "minimum": 1,
+ "type": "integer"
+}get_retailer_product1 field changedInput schema / properties / response_formatAdded value: +{
+ "default": "compact",
+ "description": "Response shape. \"compact\" (default) returns a ~14-field subset; \"full\" returns complete product data with resale intelligence.",
+ "enum": [
+ "full",
+ "compact"
+ ],
+ "type": "string"
+}search_retailer_products10 fields changedInput schema / properties / after / descriptionPrevious value: -"Cursor for the next page. Use the next_cursor value from the previous response. Omit for the first page."New value: +"Signed pagination cursor from the previous response (next_cursor). Omit for the first page."Input schema / properties / in_stockRemoved value: -{
- "description": "If true, only return in-stock products.",
- "type": "boolean"
-}Input schema / properties / limit / descriptionPrevious value: -"Max products per page (1-10000, default 25). Use 25-100 for browsing, up to 10000 for bulk operations."New value: +"Max products per page (1-500, default 25). Use 25-100 for browsing; cannot exceed 500. Paginate via next_cursor for bulk traversal."Input schema / properties / limit / maximumPrevious value: -10000New value: +500Input schema / properties / max_sales_rankRemoved value: -{
- "description": "Maximum Amazon sales rank (lower = better seller).",
- "maximum": 9007199254740991,
- "minimum": 0,
- "type": "integer"
-}Input schema / properties / min_sales_rankRemoved value: -{
- "description": "Minimum Amazon sales rank.",
- "maximum": 9007199254740991,
- "minimum": 0,
- "type": "integer"
-}Input schema / properties / response_format / defaultAdded value: +"compact"Input schema / properties / response_format / descriptionPrevious value: -"Response shape. \"compact\" returns a smaller subset of fields for large result sets; \"full\" returns complete product objects."New value: +"Response shape. \"compact\" (default) returns a ~14-field subset suitable for bulk listing; \"full\" returns complete product objects with resale intelligence."Input schema / properties / sort_by / enumPrevious value: -[
- "price_asc",
- "price_desc",
- "discount_asc",
- "discount_desc",
- "top_seller_rank_asc",
- "updated_at_asc",
- "updated_at_desc",
- "created_at_asc",
- "created_at_desc"
-]New value: +[
+ "price_asc",
+ "price_desc",
+ "discount_asc",
+ "discount_desc",
+ "updated_at_asc",
+ "updated_at_desc",
+ "created_at_asc",
+ "created_at_desc"
+]Input schema / properties / stock_availabilityRemoved value: -{
- "description": "Filter by stock status string (e.g. \"In Stock\", \"Out of Stock\").",
- "type": "string"
-}get_amazon_asin_price_historyget_product_price_historyget_retailer_categoriesget_retailer_productget_statuslist_retailerssearch_retailer_productsLive search across 250,000+ verified UK and Canada retail deals. Read-only, no auth required.
Curated, human-reviewed deal feed for AI agents — live deal search + price watches. No auth.
Shopping search across 100M+ products, with every retailer's offer and live price in one place.
Cross-retailer product catalog: one scored answer per product with live prices and buy links.
Add one secure layer between your agents and this server.
