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

Annotations already cover write/idempotent/non-destructive/open-world, yet the description adds the contract details that matter: the server processes the actual image, exactly one of file/imageUrl/image.data must be supplied, formats and 10 MB cap, the prohibition on inventing file IDs or URLs, and the exact fallback sequence with the same requestId. This goes well beyond what the annotations convey and is internally consistent with idempotentHint.

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?

Front-loaded with purpose and usage, then requirements, then fallback; nearly every clause is actionable. It is dense and slightly long, but no sentence is filler.

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?

For a five-parameter mutation with nested input objects and no output schema, the description covers the trigger, input alternatives, validation limits, anti-fabrication rules, and how to retrieve the result via get_wardrobe_image_activity, leaving nothing essential to inference.

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 80% and nested objects are documented, so the baseline is 3, but the description adds critical semantics the schema omits: the three image inputs are mutually exclusive ('provide exactly one of'), requestId must be generated and reused for retries/fallback, and fabricated IDs are forbidden. The menswearOrWomenswear default is already in the schema, so only modest extra value there.

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?

States a specific verb and resource ('Add one clothing item from the user's original image to their wardrobe') and explicitly scopes it to image-sourced adds, which separates it from the text-based sibling add_wardrobe_item_from_description. An agent can identify the tool without opening the schema.

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?

Gives the trigger condition ('when the user attaches a photo or supplies an image URL and asks to add/save the pictured item'), an explicit exclusion ('Do not replace this flow with add_wardrobe_item_from_description or your own visual interpretation'), and a named fallback path (create_image_upload plus get_wardrobe_image_activity).

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