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

Annotations already establish the tool as read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond these flags: it operates on 'known listing(s)' (not a search), returns 'day-by-day' granularity, and is limited to 'one platform' per call. This sets expectations about input requirements and output shape that annotations do not cover.

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 sentence of 14 words, front-loaded with the core function ('Day-by-day availability'). It contains no fluff or redundant information; every word contributes to defining the tool's purpose and scope.

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?

Despite lacking an output schema, the description clearly signals the output type (day-by-day availability) and the required context (known listings, one platform, date range). It is adequate for a moderately complex tool with 7 parameters. However, it does not mention edge cases like inclusive/exclusive date boundaries or error behavior when a listing is unknown, which could be helpful given no output schema exists.

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 descriptions already cover 86% of the 7 parameters, including explicit descriptions for url, listingId, listingIds, startDate, endDate, and platform. The description reinforces these by implying their combined use (listing(s) + platform + date range) but does not add new parameter-specific semantics beyond what the schema provides. The high schema coverage warrants the baseline score of 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 tool checks 'Day-by-day availability for known listing(s) on one platform over a date range.' It uses a specific verb (check availability) and resource (known listings) with clear scope (one platform, date range). This distinguishes it from siblings like search_stays (search) and get_price (pricing), making its purpose immediately evident.

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 no guidance on when to use this tool versus alternatives like search_stays or get_listing. It does not mention exclusions, prerequisites, or alternative recommendations, leaving the agent to infer usage from the description alone.

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