Cost per unit of Amazon US products: cheapest per oz, count or GB, and each category's median.
Scored across 3 tools
Each tool has a fairly clear niche: unit_price is per-listing search, category_price is category-level statistics, and bigger_pack is a follow-up alternative for a specific slug. There is some overlap because both unit_price and category_price surface 'good price' thresholds and category medians, so an agent asking 'is this a good price' could plausibly reach for either.
All three names are lowercase snake_case noun phrases (bigger_pack, category_price, unit_price), so the convention is consistent. The lack of action verbs makes names slightly less self-explanatory, and 'bigger_pack' is the vaguest of the three, but style is uniform.
Three tools is on the thin side but each covers a distinct slice of the unit-price-comparison domain (search listings, category benchmarks, pack-size alternatives). The set is well-scoped rather than padded, though it sits near the lower bound of comfortable coverage.
Core workflows are covered: find cheapest listings, judge against category thresholds, and find a cheaper-per-unit pack size, with category_price doubling as a category lister. Gaps remain around browsing all listings in a category or comparing multiple products at once, but agents can work around these for the stated 'picks' purpose.
For one tracked listing, the same product in a materially different pack size that costs less per unit, and by what percentage. Takes a deal slug as returned by unit_price.
| Name | Required | Description | Default |
|---|---|---|---|
| deal | Yes | Deal slug, e.g. "armani-my-way-edp-89ml-a1b2c". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the full burden of explaining behavior. It says the tool compares pack sizes and reports a percentage, but it does not explain what happens when no cheaper pack exists, whether multiple matches are possible, or what shape the response takes.
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-loads the comparison concept, but it is grammatically incomplete and lacks a clear main verb. It is concise, though not as clearly structured as it could 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?
For a simple one-parameter analytical tool, the description gives the core comparison concept. However, without an output schema it should more explicitly describe the return values and the no-match case.
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 deal parameter is already well documented with an example. The description adds useful provenance by saying the slug is returned by unit_price, but it does not add syntax or matching details 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 identifies the resource and comparison: one tracked listing, the same product in a different pack size, the per-unit savings, and the percentage. It is specific enough to distinguish this from a plain unit-price lookup, though it is phrased as a fragment rather than a clear action.
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 only usage clue is that the deal slug comes from unit_price. There is no explicit statement of when to use this tool instead of unit_price or category_price, and no exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Median cost per unit for one tracked category, with the 25th-percentile "good price" threshold and the 75th above which a buyer is overpaying. Call with no known slug to get the list of categories.
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Category slug, e.g. "baby-care", "printer-ink", "skincare". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden, and it does meaningful work by explaining the semantics of the three returned numbers (median, 25th-percentile 'good price', 75th 'overpaying' threshold), which no output schema covers. It is silent on error behavior for an unknown slug and on rate limits or auth, which keeps it out of the top band.
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 core behavior and free of filler. The second sentence is compact but arguably does not earn its place given that it conflicts with the required parameter.
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 tool with no annotations and no output schema, the description adequately covers what is returned and how to read it. The unresolved tension between the 'no slug' discovery instruction and the required parameter is the main completeness gap an agent would trip over.
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 the schema already gives example slugs, so the baseline would be 3. The description's only extra parameter claim, that omitting the slug returns a category list, contradicts the schema's required: ["category"], making the added meaning actively misleading rather than additive.
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 title and description state a specific verb/resource: median cost per unit for one tracked category, and they even define what the returned percentile figures mean. It never names the siblings unit_price or bigger_pack, so an agent must infer how this differs from a generic unit-price tool.
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 one concrete usage hint, 'Call with no known slug to get the list of categories', but no guidance on when to prefer this over unit_price or bigger_pack. That single hint also conflicts with the schema, where category is a required parameter, so the agent is left unsure whether an omitted-slug discovery call is legal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cheapest tracked listings matching a product description, priced per unit (per ml, per diaper, per page, per lb) with the pack size and the gap to that category's median. Use for "what should X cost" and "is this a good price".
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Matches to return (default 5). | |
| query | Yes | Product words, e.g. "aa batteries" or "dove body wash 22 oz". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It explains that results are cheapest tracked listings with unit pricing, pack size, and median gap, but it omits freshness, currency, geography, shipping/tax inclusion, and whether 'cheapest' is ranked by unit price or pack total.
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 tight sentences, front-loaded with what the tool returns and followed by concrete use cases. The unit examples earn their place by clarifying the pricing basis.
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 two-parameter read tool with full schema coverage and no output schema, the description adequately explains the return contents and use cases. It falls short of full completeness because it does not differentiate from sibling tools or disclose source, freshness, and pricing caveats.
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 schema already documents query and limit. The description adds context that query is a product description and results are cheapest matches, but it does not add parameter behavior beyond what the schema provides.
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 retrieval operation: cheapest tracked listings matching a product description, priced per unit, with pack size and median gap. It is clear what the tool returns, but it does not explicitly distinguish itself from siblings like category_price or bigger_pack.
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 explicit usage scenarios: 'what should X cost' and 'is this a good price.' However, it does not state when not to use it or point to alternatives such as category_price or bigger_pack.
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.
bigger_packcategory_priceunit_pricePrice per unit from Amazon, Walmart and grocery scraper rows: best value, bigger-pack traps
Cash-pay MRI prices at 5,419 US hospitals.
S-to-F tier lists for 208 product categories. Every placement cited, with barcodes.
Cached US grocery prices, age disclosed on every row - search, compare across banners, coverage.
Add one secure layer between your agents and this server.
