Creator product picks with daily-verified store prices and Avahit's own price history.
Scored across 4 tools
The four tools have clearly distinct inputs and purposes: search by keyword, price history by product id, alternatives by product id, and store sales by store domain. There is no overlap in their intended use, so an agent can easily select the right one.
All tool names use snake_case with a verb_noun structure (compare_alternatives, get_price_history, get_store_sales, search_products). The pattern is consistent across the set.
Four tools are well-scoped for a price intelligence service; each tool covers a distinct core function (search, history, alternatives, store sales) and no tool feels redundant. The count is within the typical 3–15 range.
The set covers the main workflows: searching products, checking price history, finding alternatives, and exploring store sales. A minor gap is the lack of a direct 'get product details' tool, but search_products provides enough to discover products and their IDs for other tools.
Given an Avahit product id, return ranked alternatives with a match percentage explaining how close each one is (same category, price distance, product type, same store).
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds genuine behavioral context by disclosing the ranking factors behind the match percentage: same category, price distance, product type, same store. It does not describe result ordering beyond 'ranked' or any result-count 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 that delivers the input, the output, and the scoring factors with no filler. The trailing parenthetical is dense but each element 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 one-parameter, read-only lookup with no output schema, the description explains both the return shape (ranked alternatives with a match percentage) and the criteria behind it. That is close to complete, with only id format and result limits 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?
There is a single parameter and schema description coverage is 0%, so the schema contributes only its type and required status. The description adds a useful qualifier ('Avahit product id'), but does not specify the format or where the id comes from, so it only partially compensates.
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 (return ranked alternatives) plus the resource (alternatives for a given Avahit product id) and even names the ranking signal. It is clearly distinct from siblings like search_products and get_price_history, though it never explicitly contrasts itself with them.
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 statement of when to use this tool versus search_products or the other siblings, and no prerequisites or exclusions are given. Usage is only inferable from the name and the phrase 'Given an Avahit product id.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given an Avahit product id, return what Avahit itself observed about its price: current price and when it was last verified against the store, the lowest and highest price seen with dates, the average, how many checks and since when. Amazon products have no history — Amazon's licence forbids keeping their prices longer than 24 hours.
| Name | Required | Description | Default |
|---|---|---|---|
| productId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, and the description does not contradict them. It adds genuine behavioral context beyond the annotations: the exact data payload shape and the 24-hour retention limit driven by Amazon's licence, which explains why Amazon results are empty rather than erroring.
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, front-loaded with the purpose and the enumeration of returned fields, with the Amazon caveat placed last where it does not interrupt the primary instruction. Every clause carries information; nothing is redundant with the name or schema.
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 effectively serves as the return contract by listing current price, verification date, low/high with dates, average, check count, and tracking start. The Amazon limitation closes the main expected edge case for a read-only 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 0%, so the description carries the burden, and it does constrain the parameter by stating it must be an 'Avahit product id' — implying an Amazon ASIN will not work. It does not give the id format or an example, leaving a small gap for a single required string parameter.
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 ('return what Avahit itself observed about its price') and enumerates the exact fields returned, which no sibling does. The scoping phrase 'what Avahit itself observed' implicitly separates it from store-side or comparative data offered by siblings like get_store_sales or compare_alternatives.
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 a clear usage boundary: Amazon products have no history because of a licensing constraint, so the agent knows not to expect results for them. It does not name an alternative tool for the Amazon case or state prerequisites explicitly, but the applicability condition is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
When does a brand store have sales? Given a store domain or brand name (e.g. 'glossier.com', 'Boll & Branch'), return the sales it announced on its homepage or by email to newsletter subscribers with dates, whether product prices actually dropped in each (or the discount came off at checkout), price cuts Avahit measured itself, today's homepage offer, holiday sale pages (Black Friday) and how often sold-out items come back. Promo codes are never included.
| Name | Required | Description | Default |
|---|---|---|---|
| store | Yes | Store domain or brand name, e.g. 'glossier.com' or 'Rothy's' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations establish readOnlyHint=true and openWorldHint=false, and the description adds genuinely useful disclosure beyond that: the data covers both homepage announcements and email campaigns, distinguishes measured price cuts from checkout-only discounts, and explicitly states 'Promo codes are never included' — a valuable negative guarantee. It does not discuss rate limits or freshness/latency, 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?
It is a single long sentence that is front-loaded with the governing question, but the tail becomes a run-on list ('price cuts Avahit measured itself, today's homepage offer, holiday sale pages...') that is harder to parse than a short bulleted enumeration would be.
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 describing return content, and it does so thoroughly — dates, price-drop verification, homepage offers, holiday pages, restock cadence. Missing only structural details such as response format or whether results span a default time window.
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% for the single 'store' parameter, so the baseline is 3. The description repeats the same examples as the schema ('glossier.com', brand names) without adding format, normalization, or lookup-behavior details, so it does not exceed 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 names a specific resource (a brand store's announced sales) and enumerates what is returned: announcement dates, whether prices actually dropped, homepage offers, holiday sale pages, and restock frequency. It is clearly distinct from siblings like get_price_history or search_products, though it never explicitly contrasts itself with them.
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 framing question 'When does a brand store have sales?' implies the use case, but there is no explicit when-to-use, no when-not-to-use, and no mention of the three sibling tools or how to choose between get_store_sales and get_price_history/compare_alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Avahit's catalogue of direct-to-consumer brand products whose prices Avahit re-checks at the store every day. Returns title, current price with the date of the last check, store domain, store rating and a link to the product page on Avahit.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, 1-20 (default 8) | |
| query | Yes | What the shopper is looking for, e.g. 'white sneakers' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-redundant behavior: prices are re-checked daily and results carry the date of the last check, which tells the agent how fresh the data is — useful context it could not get from the annotations or schema.
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, no filler, front-loaded with the capability and then the return contents. Every clause earns its place by either scoping the search or describing the output.
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 return-value burden and does so well: title, current price with last-check date, store domain, store rating, product link. It omits result ordering and pagination behavior, which are minor gaps for a simple two-parameter search.
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 both query and limit are already documented in the schema, including the 1-20 range and default of 8. The description adds no parameter-level meaning (no syntax, ranking, or result-ordering semantics), 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 (Search) and resource (catalogue of DTC brand products) and adds scope detail — prices re-checked at the store daily — which tells the agent what data it is searching over. It does not differentiate itself from siblings like get_price_history or compare_alternatives, so it stops short of a 5.
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 only implied: the query parameter example ('white sneakers') signals this is the entry point for product discovery, but the description never says when to use it versus compare_alternatives, get_price_history, or get_store_sales, and gives no exclusions or prerequisites.
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_store_salescompare_alternativesget_price_historysearch_productsSearch 86 US retailers — 260M+ products with real-time pricing, stock, and price history.
Price comparison across partner retailers. Read-only, 90-day history, disclosed affiliate.
Product price checks and affiliate link building for AI shopping agents.
AI shopping comparison — search 50M+ products, compare prices, find deals
Add one secure layer between your agents and this server.
