Cheapest delivered price for any product: tech, home, shoes, beauty. Read from each store's checkout
Scored across 2 tools
The two tools serve clearly separate purposes: find_delivered_price performs a ranked price lookup for a product/country, while import_fee_rules is purely explanatory reference material about tax and duty.
Both names use consistent snake_case, but find_delivered_price follows a verb_noun pattern while import_fee_rules is noun_phrase, a minor deviation in an otherwise predictable scheme.
Two tools is thin for a price-comparison service; the surface is borderline and would benefit from at least a product/store lookup or country-support tool.
The core flow (rank delivered totals + explain import rules) is covered, but there is no way to search for products, browse supported stores, or list covered countries, which are notable gaps for a discovery-oriented service.
Finds the Shopify stores that deliver a product to a country and ranks them by the final total a shopper pays: item price, shipping to that country, the best confirmed code, sales tax or VAT, and import fees. Each total is read from the store's own checkout for that country (no order is placed), and every offer says where import duties are paid: none (ships locally), included in the price, paid at checkout, billed at the door (estimate added), may be billed at the door (not included), or unknown origin. Final totals rank first. Works for any product sold by Shopify stores: electronics, kitchen appliances, drinkware, shoes, clothing, fitness gear, toys, home goods, supplements, beauty and more. Amazon, Daraz, Sephora and other marketplace links are read for the product name only. Amounts are in US dollars with the local currency alongside. Use for questions like "where is a Ninja CREAMi cheapest delivered to the US", "what will a Stanley Quencher 40 oz really cost delivered to Australia" or "cheapest UGG Tasman slippers delivered to the UK".
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | US only: two letter state code, for sales tax. | |
| country | Yes | Two letter delivery country code, for example US, GB, AU, DE. | |
| product | Yes | Brand plus product name, for example "Ninja CREAMi Deluxe", "Stanley Quencher 40 oz" or "Beauty of Joseon Relief Sun", or a product link (Shopify stores are read; Amazon and other marketplace links are read for the name only). A bare type ("toner", "headphones") or a brand alone ("COSRX") is refused with a message asking for both. | |
| postal_code | No | Optional delivery ZIP or postcode, for shipping (and US and Canadian sales tax) to that exact area. Works for the US, Canada, the UK, Australia, the EU and most other supported countries. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, non-destructive and open-world, and the description still adds substantial context: totals are read from the store's own checkout, no order is placed, and each offer is labelled with one of six import-duty payment states. This is behavior an agent cannot infer from the schema or 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?
The purpose and ranking logic are front-loaded in the first two sentences, which earns its place. The long product-category enumeration (electronics, drinkware, shoes, supplements, beauty...) is padding that could be trimmed without losing meaning.
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 open-world search with no output schema, the description covers what is returned (ranked totals broken into item, shipping, code, tax, duties, plus currency) and the duty-payment semantics. It does not address result count, pagination, or behavior when no store carries the product, so it is not fully 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?
Schema description coverage is 100%, so every parameter (state, country, product, postal_code) is already documented with format and purpose, which sets the baseline at 3. The description reinforces the product-refusal rule and currency handling but adds no syntax or format detail beyond the schema.
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 (finds Shopify stores delivering a product to a country, ranked by delivered total) and enumerates exactly which cost components are summed. It is clearly distinguishable from the sibling import_fee_rules, which appears to supply the rule data this tool consumes.
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?
It gives concrete trigger questions ("where is a Ninja CREAMi cheapest delivered to the US") and a scope boundary (marketplace links are read for the product name only; bare types or brands are refused). It never names an alternative tool or states when not to use this one, so it stops short of the 5 bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explains the sales tax, VAT, GST and import duty a shopper pays on goods ordered from abroad to a country, and how Lowcart counts them in totals. Covers the US, UK, Australia, New Zealand and every EU country. US duty depends on the product and where it was made: Lowcart estimates it for beauty products only.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | Two letter country code. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the exact country coverage and an important limitation that US duty depends on product and origin and is only estimated for beauty products, which warns the agent about partial accuracy.
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, front-loaded with what the tool explains and the domain it covers, then the limitation. No filler, though the mid-sentence country list and the 'how Lowcart counts them in totals' clause could be tightened.
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 one-parameter read-only lookup with no output schema, the description supplies the coverage scope and the key accuracy caveat. It is nearly complete; it does not indicate whether the response is a single rule set per country or a breakdown, but that is a minor gap for this simple tool.
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 single 'country' parameter and its 'Two letter country code' format are already documented. The description confirms the country-scoped nature of the tool but adds no format, validation, or defaulting detail beyond the schema, 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?
The description states a specific informational resource — the sales tax, VAT, GST and import duty rules a shopper pays on cross-border goods — and notes how Lowcart counts them in totals. That is clear enough for an agent to know it is a lookup/reference tool, but it never mentions the sibling find_delivered_price or explains how the two differ.
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?
There is no explicit statement of when to call this tool versus find_delivered_price, nor any prerequisite or exclusion. The only scoping information ('covers the US, UK, Australia, New Zealand and every EU country') describes coverage, not usage selection, so the agent must infer when this is the right call.
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.
find_delivered_price1 field changedInput schema / properties / product / descriptionPrevious value: -"Brand plus product name, for example \"Beauty of Joseon Relief Sun\" or \"Stanley Quencher 40 oz\", or a product link (Shopify stores are read; Amazon and other marketplace links are read for the name only). A bare type (\"toner\", \"headphones\") or a brand alone (\"COSRX\") is refused with a message asking for both."New value: +"Brand plus product name, for example \"Ninja CREAMi Deluxe\", \"Stanley Quencher 40 oz\" or \"Beauty of Joseon Relief Sun\", or a product link (Shopify stores are read; Amazon and other marketplace links are read for the name only). A bare type (\"toner\", \"headphones\") or a brand alone (\"COSRX\") is refused with a message asking for both."find_delivered_price1 field changedInput schema / properties / product / descriptionPrevious value: -"Brand plus product name, for example \"Beauty of Joseon Relief Sun\", or a store product link. Beauty and skincare only: a bare type (\"toner\") or a brand alone (\"COSRX\") is refused with a message asking for both."New value: +"Brand plus product name, for example \"Beauty of Joseon Relief Sun\" or \"Stanley Quencher 40 oz\", or a product link (Shopify stores are read; Amazon and other marketplace links are read for the name only). A bare type (\"toner\", \"headphones\") or a brand alone (\"COSRX\") is refused with a message asking for both."find_delivered_priceimport_fee_rulesShopping search across 100M+ products, with every retailer's offer and live price in one place.
Product search across online shops worldwide, plus every seller's price with a direct link.
Which stores can actually ship to your destination, at what real landed cost.
Search Coles, Woolworths and ALDI at once: prices, unit prices, specials, cheapest store per item.
Add one secure layer between your agents and this server.