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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description only needs to add context. It does: the returned page URL is the facility's detail/booking page, and the presentation must be plain bullets plus Markdown links with no map or place-card widgets. It does not cover result ordering behavior or pagination beyond what the schema states.

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, front-loaded with the core search capability before the keyword fallback and output-format rule. Each sentence carries distinct information; density is high but nothing is obviously redundant.

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 an 8-parameter, zero-required search tool with no output schema, the description covers search facets, the meaning of returned URLs, and presentation constraints. Remaining gaps (default behavior with no filters, how conditions interact with area/age) are minor and largely inferable from the schema.

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. The description adds real meaning on top: conditions are described as verified facilities with a cross-reference to list_conditions (53 types, AND semantics implied), and keyword is framed as a partial-match name lookup usable as an alternative entry path.

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 (日本の宿を検索) plus the exact facet set (エリア・子どもの年齢・価格・検証済み条件), and cross-references list_conditions for the 53 condition IDs. It also implicitly separates itself from get_hotel by noting keyword is the path when the hotel name is already known.

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?

Explicitly says when to use keyword (已知宿名) versus the facet search, and points to list_conditions to resolve condition IDs. It gives no explicit 'when not to use' case (e.g. when to prefer get_hotel for a single known facility), so it stops short of a full routing guide.

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