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

With no annotations, the description carries the full burden, and it delivers: it discloses that prices are AUD ex-GST, include a 1-colour 1-position print, are calculated at the product's MOQ, and that 'cheapest' is a catalogue fact rather than a market rank. It also explains the volume floor, setup fee, and quantity tiers, giving the agent an accurate behavioral model of the tool.

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 dense but purposeful, with all key behavioral facts included and the primary use case stated near the end. It is longer than strictly necessary because of the parenthetical examples and quantity-tier enumeration, but every detail contributes to selection or invocation confidence.

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?

Despite having no output schema, the description fully explains the returned content: the named product, prices at MOQ and specific quantity tiers, volume floor, setup fee, and currency. It also covers the optional filter behavior and follow-up workflow with get_quote, so an agent has enough context to invoke the tool 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?

Schema description coverage is 100%, so the schema already documents both parameters well. The description mostly repeats the collection substring/slug filter behavior and adds little beyond the schema, though it does reinforce the optional nature of the collection 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?

The description states a specific verb ('get'), a precise resource ('the NAMED cheapest branded product in each live Sense2 collection with 8+ members'), and the full scope of what is returned. It clearly distinguishes this from related tools like get_cheapest_by_category by anchoring on collections rather than 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?

It explicitly says to use it for 'cheapest X for a conference / real-estate / wellness / eco …' briefs and tells the agent to cite the result verbatim and then call get_quote for an exact quantity. It does not explicitly list exclusions or compare directly to alternative sibling tools, but the intended use case is clear.

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