The connector has been replace with 0auth. https://glama.ai/mcp/connectors/com.lemmebuyit.mcp/lemme-buy-it
Search 86 US retailers — 260M+ products with real-time pricing, stock, and price history.
Scored across 9 tools
Each tool has a clear, distinct purpose: health check, retailer discovery, category discovery, product search, product details, promotions, and the two price-history tools are differentiated by ASIN vs. retailer SKU/ID. There is no meaningful overlap or source of misselection.
Tool names mostly follow a predictable snake_case verb_noun pattern, with search_*, get_*, and list_* used for search, detail, and enumeration operations. Minor deviations like list_retailers vs get_retailer_categories and the vague check_skill_run keep it from being perfectly consistent.
Nine tools is a well-scoped surface for a read-only commerce data/API server. Each tool covers a core operation health, retailers, categories, products, price history, promotions, or quota, without unnecessary fragmentation or bloat.
The tool surface covers the core read-only workflow well: discover retailers, browse categories, search products, get product details, search promotions, and fetch price histories by Amazon ASIN or retailer SKU/ID. Minor gaps such as no direct Amazon product search and no product-level promotion lookup can be worked around through the existing tools.
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 show the upgrade message to the user; 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 only indicate non-read-only and non-destructive. The description adds valuable behavior: the tool consumes one unit of the daily limit, must be called exactly once, and requires checking the `allowed` field to decide whether to continue. This exceeds what annotations 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 with no wasted words. The first sentence states the core action, and the second sentence fronts the exact call timing and conditional handling. Every sentence 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?
With no output schema, the description bears responsibility for response semantics. It covers the critical `allowed`/`upgrade` handling but does not explicitly describe the full response shape or potential error conditions. For a simple two-parameter tool, this is nearly complete.
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 input schema already provides 100% parameter coverage, including an example for skill_id and allowed values for capability. The tool description itself does not add parameter-level detail, so a baseline of 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?
The description states a specific verb and resource: 'Reserve ONE run of a LemMeBuyIt skill against your plan's daily limit.' This clearly distinguishes it from sibling tools, which are retail/price/promotion queries and do not perform quota reservations.
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 gives explicit usage guidance: 'Call this exactly once at the start of a skill.' It also provides precise conditional behavior: if `allowed` is false, stop and show the upgrade message. No alternative tool competes for this purpose, so the instructions are complete.
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 mark the tool read-only and non-destructive, and the description adds the important paid-plan/authorization requirement plus the weekly aggregation and 104-week cap. This goes beyond the annotations without contradicting them, although it does not disclose response format or potential empty results.
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 description is short and front-loaded with PAID, but 'PAID.' and 'Requires a paid plan.' are redundant statements. The core metrics are compactly listed, yet the duplicate warning means not every sentence 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 two-parameter read-only tool with full schema coverage, the description gives the essential operational context: what data is returned, the time range, and the paid-plan constraint. It lacks sibling routing, but nothing critical to actually invoking the tool with a valid ASIN and optional weeks 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 input schema fully documents asin and weeks. The description adds no substantive parameter meaning beyond re-stating the 104-week cap and ASIN specificity, which are already present in the schema, keeping this at the schema-carrying baseline.
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 description clearly states the tool retrieves weekly Amazon price history for a specific ASIN and enumerates the included data points (Buy Box, lowest 3P-new, list price, sales rank, offer counts). It is specific and unambiguous, but it does not explicitly differentiate itself from the sibling get_product_price_history, so it stops short of full sibling distinction.
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-plan requirement implies a precondition for use and the ASIN wording implies when it applies, but the description gives no explicit when/when-not guidance or reference to alternative tools. Sibling tools such as get_product_price_history exist, yet no routing or exclusion is provided.
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 mark this read-only/non-destructive, covering the safety profile. The description adds meaningful context beyond annotations: paid access is required, data is weekly, and it merges retailer and mapped Amazon ASIN series. It does not mention pagination or rate limits, but those are less critical for a read-only history endpoint.
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 with front-loaded 'PAID.' and dense information about scope, merged series, metrics, and time range. The only minor blemish is the slight redundancy between 'PAID.' and 'Requires a paid plan.'
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 3 parameters and no output schema, the description covers what will be returned, the time horizon, and the access cost. It does not explicitly describe response structure, but the schema covers parameter constraints and the payload is straightforward for a price-history endpoint.
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 baseline is 3. The description adds useful domain context such as the merged Amazon series and metric names, but it does not add new parameter-level semantics beyond what the schema already provides for weeks and product_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+resource: returns weekly price history for a retailer product by SKU/ID. It also specifies the merged Amazon ASIN series and the metrics included (Buy Box, lowest 3P-new, list price, sales rank), clearly distinguishing it from the sibling get_amazon_asin_price_history.
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?
Clearly establishes the tool's scope and the paid-plan prerequisite, so an agent knows when this tool is a candidate. It does not explicitly name alternatives or exclusion cases such as when to choose get_amazon_asin_price_history instead, leaving some routing to inference.
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 and destructiveHint=false, so the safety profile is established. The description adds the purpose of discovering category paths but does not disclose additional behaviors such as pagination specifics or result ordering. With annotations covering the core behavioral traits, a 3 is appropriate.
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 description is two sentences long and front-loads the primary action, then immediately adds usage context. Every sentence earns its place without redundancy.
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 listing tool with robust schema documentation, the description is nearly complete. It covers what the tool does and why it is useful. The lack of an output schema is acceptable because the return value is straightforwardly implied as a list of categories, and pagination is handled in the schema.
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 input schema already provides 100% parameter descriptions, including retailer_id format, pagination cursor semantics, and limit bounds. The description adds no additional parameter meaning beyond the schema, so the baseline score of 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 description states a specific verb ('List') and resource ('product categories available for a specific retailer'), which clearly distinguishes it from sibling tools like list_retailers and search_retailer_products. An agent can immediately understand what the tool returns and for whom.
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 sentence 'Use this to discover valid category paths before filtering products by category' provides clear contextual guidance on when to call this tool. It does not explicitly name alternatives or exclusion conditions, but the intended workflow is evident and sufficient for most agents.
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.
| 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?
With readOnlyHint=true and destructiveHint=false, the safety profile is already covered by annotations. The description adds valuable behavioral context by disclosing the default compact response (~14 fields) and explaining how to request full data with response_format="full", including resale intelligence. It does not contradict 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences. The first states the core purpose, and the second covers the key behavior (default format vs. full format) without any filler or redundancy.
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 three-parameter read-only tool with no output schema, the description adequately explains the response shape and the main format option. Combined with the rich parameter descriptions and read-only annotations, nothing critical is missing, though it could have briefly mentioned the 'resale' format or not-found behavior.
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 three parameters thoroughly, including the crucial warning that the search result's 'id' field is not resolvable here. The description adds a little color around resale intelligence, but this largely duplicates what the response_format parameter description already states.
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 description states a specific verb ('Get') and a specific resource ('details for a specific product by its retailer SKU/ID'). The single-item-by-ID scope is clearly distinct from search-oriented siblings like search_retailer_products and from price-history 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?
The description clearly implies this is the tool to use when you already have a retailer and product SKU/ID and want product details. Parameter descriptions reinforce the workflow by telling agents to take product_id from search_retailer_products results and retailer_id from list_retailers. However, it does not explicitly name alternatives or state when not to use this tool.
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 API service.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the API-service scope but does not explain what the response contains or how status is reported.
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 no redundant wording. It efficiently conveys the action and target.
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 parameterless health check with read-only annotations, the description is nearly complete. Mentioning the expected response fields, such as status code or service version, would make it fully comprehensive.
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 has zero parameters and an empty input schema, so no parameter documentation is required. The baseline score of 4 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 description clearly states the action ('Check') and the resource ('health and operational status of the LemmeBuyIt API service'). This distinguishes it from sibling tools focused on product data, prices, and retailer operations.
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 intended use is self-evident: invoke this tool when API health or operational status is needed. No competing health-check sibling exists, so explicit exclusion guidance is unnecessary.
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 API key. Always call this first 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 mark the tool as read-only and non-destructive. The description adds API-key scoping ('available to your API key') and clarifies that it returns valid retailer IDs, which is useful behavioral context beyond the annotations. It does not describe the output shape or pagination, but this is a simple zero-parameter list operation.
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 with no filler. The first states the action and scope; the second provides the workflow instruction. Every word 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 zero-parameter discovery tool, the description covers what the tool does, the API-key scope, and how to use it in the larger workflow. It does not explicitly document the return format, but the stated purpose of discovering valid retailer IDs is enough for an agent to invoke it 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?
The tool has zero parameters, so there is nothing for the description to compensate for. The schema coverage is effectively 100%, and the description's mention of API-key scoping is sufficient context.
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: 'List all retailers available to your API key.' It also explains the tool's role as a discovery step for retailer IDs, which distinguishes it from sibling tools like search_retailer_products and get_retailer_categories.
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?
Provides explicit guidance: 'Always call this first to discover valid retailer IDs before searching products.' This tells the agent when to use the tool and what to do with the result, leaving no ambiguity about its role in the workflow.
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 aggregated 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 advertiser/brand 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 mark the tool as read-only and non-destructive, and the description adds meaningful behavioral context: active promotions are returned by default, active=false changes that behavior, and cursor pagination via 'after' is available. This goes beyond the structured annotations without contradicting them.
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 concise sentences deliver the core purpose, filtering capabilities, pagination mechanism, and the key default behavior. The most important information is front-loaded, and every clause earns its place without redundancy.
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 search tool with 11 well-documented parameters, the description captures the essential context: what is searched, what filters exist, how pagination works, and the active-status default. There is no output schema, so the description could have mentioned the response shape more explicitly, but the schema's pagination-cursor reference partially covers that 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?
Schema description coverage is 100%, so every parameter is already documented. The description adds a useful high-level summary of the filtering and pagination behavior, but it does not need to restate parameter-level details. This is the appropriate baseline when the schema carries the full semantic load.
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 description names a specific verb ('Search') and resource ('promotions, coupons, sales, and deals aggregated across retailers'), which makes the tool's purpose immediately clear. It also signals that this is a cross-retailer promotion search, distinguishing it from sibling tools like 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?
The description clearly states what the tool searches and lists the main filtering dimensions (retailer, category, promotion type, coupon availability, expiry). It also explains the default active-only behavior and how to opt into expired/upcoming promotions, giving a clear context for use, though it does not explicitly name alternative tools or when not to use it.
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 (thousands of items) one cursor at a time is slow and token-heavy. For full-catalog coverage, use the LemMeBuyIt direct REST bulk API (contact LemMeBuyIt for enterprise API access).
| 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 carry readOnlyHint=true/destructiveHint=false, so the bar is lower, but the description still adds substantial behavioral context: the per-call 500-item cap, the token-heavy cost of paging entire catalogs, default response shape (~14-field compact), and the response_format trade-offs (resale drops product_description to stay under token cap, full can exceed it). This is exactly the kind of operational context that exceeds structured fields.
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?
Four sentences with zero filler, front-loaded with the core function then moving to formats, cap, and the critical anti-pattern warning. Each sentence carries distinct information: what it does, what it returns by default and how to change that, its hard cap, and when NOT to use it with a pointer to the alternative.
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 tool with no output schema, the description orients the agent well: purpose, sampling boundary, response formats, per-call cap, and pagination are all covered. The main gap is the absence of explicit sibling routing (e.g., get_retailer_product for single-product details, search_promotions for deals) — though this is minor since the tool's role is clearly scoped.
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 baseline is 3. The description adds genuine operational meaning beyond the schema: it explains response_format trade-offs (resale drops product_description 'best for screening a whole catalog without exceeding the token cap'), frames 'after' within cursor pagination, and states the 500-item cap that contextualizes limit. This is modest but real added value, justifying a 4.
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 description opens with a specific verb+resource: 'Search and SAMPLE a retailer's catalog' and enumerates concrete capabilities (text search, barcode lookups, price/discount filtering, cursor pagination). It sharply distinguishes the tool from the bulk-export use case, making its scope unambiguous even without reading 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 description gives explicit when/when-not guidance: 'this tool is for finding and sampling products, NOT bulk export' with the reason (slow and token-heavy) and a named alternative (LemMeBuyIt direct REST bulk API). It also guides response_format selection by task. It stops short of routing to sibling tools like get_retailer_product for single-item lookups or search_promotions, so it doesn't hit 5.
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_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_categoriesget_retailer_productget_statuslist_retailerssearch_promotionssearch_retailer_productsPrice comparison across partner retailers. Read-only, 90-day history, disclosed affiliate.
Curated, human-reviewed deal feed for AI agents — live deal search + price watches. No auth.
AI shopping comparison — search 50M+ products, compare prices, find deals
Shopping search across 100M+ products, with every retailer's offer and live price in one place.
