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

Extensive disclosure beyond the annotations: availability may be unknown even when a price is returned, quotes may be reused until expiry, a pending search check is joined rather than repeated, the host may create an expiring anonymous price draft, and unsupported/protected sites return unknown. It also states held is always false and that no credentials are required, all consistent with readOnlyHint=false (a draft may be created) and destructiveHint=false.

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 purpose and key constraints are front-loaded, but the block is very long and mixes tool behavior with post-call response-style instructions ('default to 1-3 short sentences', 'do not narrate tools called') that dilute the selection-relevant content. Dense but partially off-purpose.

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 complex open-world quote tool with an output schema present, the description covers the operational envelope thoroughly: confidence signals to inspect (reason, price.completeness, checkedAt, expiresAt), pricing caveats (partyBasis:all_adults, startingNightlyPrice not multiplicable), latency, caching, and the no-booking guarantee. Nothing material for correct invocation is missing.

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 description coverage is only 17%, so the description must compensate, and it largely does: it explains id (the property's id), arrival/departure (YYYY-MM-DD), guests, and the execution:browser/auto trade-off in more depth than the schema. Currency is only alluded to via 'actual currency' in the results, so the input currency parameter's semantics are left thin.

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: check dates and total pricing for a published property's public host website, fed by property id, arrival/departure and guests. It is clearly a per-property quote lookup rather than a search, and the note that 'Search never starts this agent' implicitly separates it from search_properties, though no sibling is named directly.

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 concrete guidance on execution mode: omit execution for fast automatic execution, use execution:browser for the experimental selected-home agent that can take up to two minutes. It does not explicitly compare itself to get_stay_estimate or get_property, so the routing guidance stops short of naming alternatives.

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