pizzahut_modifiers

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

No annotations are provided, so the description carries the full burden. It transparently describes the output structure in detail, including price delta semantics (zero for default, positive for extras) and examples of slots and options. It does not mention side effects, auth requirements, or rate limits, but for a read-only 'Get' operation, the clear output explanation is strong. No contradictions with annotations (none exist).

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 comprehensive paragraph, front-loaded with the core purpose, then expanding into structural details. Every sentence contributes meaningful information (slots, modifiers, price deltas, source of variant_code). While slightly wordy, it is not bloated and maintains focus throughout.

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 return values, and it does so effectively: it details the hierarchical structure, examples of each level, and the meaning of price deltas. It also tells where to obtain variant_code, which is critical for correct invocation. It does not cover error handling or edge cases, but for a data-retrieval tool of moderate complexity, the coverage is sufficient.

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 parameters are already documented. The description adds value by specifying that variant_code comes from /pizzahut/menu's variant_code or variants[].variant_code fields, which clarifies the data source. It also reiterates the default for channel but that is already in the schema. This extra context elevates it above a baseline 3.

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 the action ('Get') and the resource ('one Pizza Hut product variant's full customization tree'). It provides specific details about what the tree contains (slots, modifiers, weight/placement options) and differentiates from siblings like pizzahut_menu or pizzahut_bundle_choices by focusing on customization. This leaves no ambiguity about the tool's function.

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 implies usage when one needs customization details for a specific variant, but does not explicitly state when to use this tool versus alternatives. It does mention where variant_code comes from (/pizzahut/menu), which is helpful but not a full usage guideline. No exclusions or alternative recommendations are provided.

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