Pinch Grocery Prices (Australia)

decompose_product

ADVANCED / single item. Do NOT use this to build a shopping list: for any list of 2 or more items, call build_basket (one call, server-side). Use decompose_product only to break ONE item into structured search attributes when you intend to override build_basket's pick for that single item. This does not call any API; it is a structured reasoning step.

OUTPUT: canonical_query, disqualifiers, and suggested_category for that single item.

Fill in every field based on what a typical Australian family would mean by this item. CORE RULE: Unless the user literally specifies a brand, brand_preference MUST be null and the strategy is cheapest-first (unit_price_asc, no retailer filter).

Input Schema

TableJSON Schema

Name	Required	Description
`quantity`	Yes	Target size. Use to filter results after search. Family intent means prefer larger sizes for better unit price.
`raw_input`	Yes	The item exactly as the user wrote it
`qualifiers`	Yes	Soft preferences that improve a match but don't disqualify if absent. e.g. ['skinless', 'boneless'] for chicken breast, ['Australian'] for sultanas
`category_path`	Yes	Ontological path from general to specific, e.g. ['meat', 'poultry', 'chicken', 'breast'] or ['pantry', 'cereal', 'wheat biscuits']
`disqualifiers`	Yes	Terms that indicate a WRONG product. Results containing these MUST be excluded. e.g. for 'chicken breast': ['thigh', 'drumstick', 'wing', 'nugget', 'schnitzel', 'crumbed', 'marinated']. For 'Vegemite': ['twist', 'scroll', 'shapes', 'cheesy bite']. For 'strawberries': ['yoghurt', 'jam', 'ice cream', 'flavoured']. For 'milk': ['flavoured', 'chocolate', 'coffee', 'almond', 'oat', 'soy', 'coconut'].
`canonical_query`	Yes	The cleaned search term to use with search_products. Strip sizes and brands (unless brand IS the product, like 'Vegemite'). 'chicken breast bulk pack' becomes 'chicken breast fillets'. 'Sanitarium Weet-Bix' becomes 'Weet-Bix'. 'full cream milk 2L' becomes 'full cream milk'.
`barcode_eligible`	Yes	true for branded packaged goods (Weet-Bix, Vegemite, cheese slices, chips). false for fresh produce, meat, and store-brand generics. When true AND a result has a barcode, call compare_prices to check if another retailer has it cheaper.
`brand_preference`	No	ONLY set this if the user LITERALLY named a brand (e.g. 'Weet-Bix', 'Vegemite'). If the user wrote a generic item like 'milk', 'chicken breast', 'eggs', 'bread', this MUST be null. When null, Pinch finds the cheapest option regardless of brand.
`suggested_category`	No	The grocery store category to filter search results. Use this to prevent wrong-category contamination. e.g. 'Pantry' for rice crackers (prevents dairy lunch packs), 'Fruit & Vegetables' for fresh produce, 'Meat & Seafood' for meat, 'Dairy, Eggs & Fridge' for dairy, 'Frozen' for frozen items. Only set when the item clearly belongs to one category and cross-category results would be noise.

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It clearly states 'This does not call any API; it is a structured reasoning step', discloses the core rule about brand_preference being null unless a literal brand is given, and explains the cheapest-first strategy. This is comprehensive behavioral context for an AI agent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the most critical usage warning ('ADVANCED / single item'), then proceeds to usage limits, no-API disclosure, output fields, and the core rule. Every sentence serves a functional purpose, and the line breaks make it easy to scan. It is appropriately sized for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers when to use the tool, how it behaves (no API), and the key rule for brand_preference. It lists three output fields (canonical_query, disqualifiers, suggested_category) but does not fully enumerate the complete return object, which given the 9-parameter schema could be slightly more explicit. Overall, it is largely complete for invoking the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 an instructive semantic layer: 'Fill in every field based on what a typical Australian family would mean by this item', which helps interpret parameter values like qualifiers and disqualifiers. However, much of the core rule is already embedded in the schema's parameter descriptions, so the added value beyond the schema is moderate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's specific function: 'break ONE item into structured search attributes'. It distinguishes itself from the sibling build_basket by explicitly limiting usage to single items and overriding build_basket's pick. This is a specific verb+resource definition that leaves no ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use and when-not-to-use guidance: 'Do NOT use this to build a shopping list: for any list of 2 or more items, call build_basket' and 'Use decompose_product only to break ONE item... when you intend to override build_basket's pick'. It also clarifies that it is a reasoning step, not an API call, which helps decision-making.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Pinch Grocery Prices (Australia) tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0

Disambiguation4/5

Most tools have distinct roles with explicit workflow guidance, but search_products and get_cheapest overlap in purpose (both search by name and return price data), and batch_search vs search_products could be confused without careful reading. The detailed descriptions mitigate this but don't eliminate it.

Naming Consistency4/5

Tool names are consistently snake_case, mostly verb_noun or get_noun. batch_search is a minor deviation (noun+verb) but still readable and consistent with the style.

Tool Count5/5

10 tools is well-scoped for a grocery price comparison server, covering search, details, history, specials, and basket management without excessive redundancy.

Completeness4/5

The server covers the core domain well: product search, price comparison, history, specials, and basket building/saving. Minor gaps include no way to fetch a saved basket programmatically and no explicit basket editing, but these can be worked around.

Resources

Need Help?