List Woolworths categories

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

Annotations already cover read-only and open-world behavior, so the safety profile is established. The description adds meaningful behavioral detail: the tool is hierarchical, has exactly 13 departments at the top level, and switches output granularity based on the presence of the department argument. This goes beyond the annotations without contradicting them.

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?

Four short sentences, each with a distinct purpose: orient the user, describe the no-argument behavior, describe the slug behavior, and explain how to use the output. There is no redundancy or filler, and the most important information is front-loaded.

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 must explain the return shape, and it does: departments and slugs at the top level, aisles and shelves at the department level. It also provides the natural next step (browse_category). For a simple read-only tool with one optional parameter, nothing essential is missing.

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?

The schema already provides 100% coverage for the optional department parameter, so the baseline is 3. The description adds the key semantic that providing a slug changes the result to that department's aisles and shelves, which is not explicit in the schema description. This lifts it to 4.

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 the tool lists the Woolworths browse tree: with no argument it returns 13 departments with slugs, and with a department slug it returns aisles and shelves. This is a specific verb and resource, and the pointer to browse_category distinguishes it from that sibling.

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 clearly explains both invocation modes: omit the argument for top-level departments, or pass a department slug to get its aisles and shelves. It also tells the user to feed the returned slugs into browse_category. It does not explicitly name alternatives or state when not to use the tool, so it falls short of a 5.

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