jcrew_size_chart

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

With no annotations present, the description carries the full behavioral burden and delivers: it discloses the return shape (per-size measurements, category-dependent subsets, dual units) and the important 0-value quirk where the upstream passes through 'column doesn't apply' as a genuine zero. This is exactly the kind of subtle data-quality trap an agent would misread, and the description surfaces it proactively.

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 sentences, each earning its place: purpose, return format, parameter provenance, and the 0-value caveat. It is slightly dense — the parenthetical about hip on a top and the upstream-passthrough explanation add length — but nothing is fluff and the core purpose 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 and no annotations, the description must cover both return values and behavioral traits, and it does: return format, units, category-dependent subsets, and the 0-value passthrough are all disclosed. The only minor omissions, such as error behavior for a mismatched site, are peripheral for a read-only lookup tool.

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 the baseline is 3, but the description adds value beyond the schema: it names the exact provenance of pid (jcrew-search's products[].id field path) and adds the constraint that site must match the pid's storefront with a default of jcrew. The schema's own descriptions ('style id from a search result', 'storefront the pid belongs to') are vaguer, so the description sharpens both.

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 opens with a specific verb and resource — 'Get the size chart for a J.Crew or J.Crew Factory product' — and elaborates on exactly what is returned: body measurements per size in both inches and centimeters, or a category-dependent subset. It is clearly distinguishable from siblings like jcrew_product, jcrew_search, and jcrew_product_reviews, which serve different purposes.

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 clear usage context: pid must come from jcrew-search's products[].id field, establishing the expected call sequence, and site must match the storefront the pid belongs to, with jcrew as the default. It does not explicitly name alternatives or when-not-to-use conditions, but the implied workflow is unambiguous.

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