burberry_product

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well by specifying the exact format of the input parameter (site-relative path with an example), and it lists the return content comprehensively. It also clarifies that the tool returns all other purchasable colourways, which is a non-obvious behavioral detail. However, it doesn't disclose potential failure modes (e.g., what happens if the URL is invalid) or note that it's a read-only operation, which is implied but not explicit.

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 a single, well-structured paragraph that front-loads the purpose and then lists the return fields. It includes a concrete example, which is useful without adding clutter. Every sentence earns its place: the first states purpose, the second lists fields, and the third clarifies the parameter format with an example. No redundant information.

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?

Given that the tool has one simple parameter with full schema coverage and no output schema, the description covers all necessary information for an agent to call it correctly: what it returns, how to obtain the URL, and an example. The only gap is the lack of explicit error handling or behavior on invalid input, but that's minor for a retrieval tool. Overall, it's nearly complete.

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 description coverage is 100%, and the parameter is well-documented in the schema ('Site-relative product path, from a search or category result's url field'). The tool description adds a concrete example and further context by explaining where the URL can be sourced. Since the schema already provides the necessary semantics, the description doesn't need to add much, but it does provide a useful example, so a 3 is appropriate as it adds marginal value.

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 clearly states that the tool retrieves product details for a Burberry product page, enumerating fields like name, sku, colour, material, price, etc. This distinguishes it from other Burberry tools like burberry-search and burberry-category, but it doesn't explicitly contrast with potential sibling tools like burberry-related, so I deduct one point.

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 provides explicit guidance on the input parameter: it must be a site-relative product path as returned by burberry-search or burberry-category's products[].url field. This tells the agent exactly where to obtain the URL for calling this tool. However, it doesn't explicitly state when not to use it (e.g., if the agent needs related products, use burberry-related instead).

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