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

readOnlyHint=true already covers the safety profile, so the description earns credit for adding response-level behavior: a rated response exposes rate.status, rate.available, a price breakdown, and the SLIP used to book. The parent/child rating rule is a genuine gotcha not derivable from the schema. No output schema exists, so this disclosure matters.

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, then the rated-mode detail, the parent/child caveat, and the underlying endpoint. Four compact sentences with little waste; the trailing API route is the only arguably expendable element.

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?

Ten parameters with no output schema and only a readOnlyHint annotation, so the description carries the response-shape burden and does so for the rated path. The non-rated response shape and how the many optional time/package/discount parameters compose are left to the schema, which is acceptable given 100% coverage.

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 baseline is 3, but the description adds real value by tying start_date/end_date/param together into the 'rated response' workflow and showing a concrete param shape ({"adults": 2}). This explains why those optional parameters exist, which the per-field schema text only hints at with '(rated)'.

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 ('Fetch one inventory item's details') and the singular 'one' implicitly separates it from checkfront_list_items. It never names a sibling, so an agent must infer the browse-vs-fetch split rather than being told it.

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 conditional guidance on how to invoke it: supply start_date/end_date plus param for a rated response, and rate the CHILD for parent/child grouped items. It never states when to prefer this over checkfront_list_items or checkfront_get_availability_calendar, so alternative selection is left to inference.

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