accor_destination_hotels

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently states that the result is the static list from one page, describes the fields each hotel carries, and explicitly lists excluded data categories. It does not mention pagination or rate limits, but for a read-only directory-listing tool this is a reasonable and clear behavioral profile.

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 economically written and front-loads the core purpose in the first sentence. The parenthetical list of destination levels and the explicit exclusion list are useful rather than redundant, and no sentence is wasted.

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?

Given there is no output schema, the description provides enough context about what the tool returns: a static list of hotels with code, name, source URL, and broad city/country, and what it excludes. It adequately equips an agent to decide whether this tool fits a request, though it could briefly mention pagination or how to discover slugs.

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?

The schema already documents all three parameters with 100% coverage and detailed enum descriptions, so the description adds little beyond baseline parameter semantics. It does reinforce that theme narrows the list and that destination_type spans world through place, but this largely repeats schema information rather than adding new meaning.

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 action (returns a static list of hotels) and the resource (an Accor destination directory page), with explicit scope across destination levels. It also distinguishes itself from related Accor tools by emphasizing 'static list' and listing what is excluded, so an agent can tell it apart from property-detail or search tools.

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 gives clear context: use this tool to get the static hotel list for a destination directory page, optionally filtered by theme. It also implicitly warns against using it for dynamic data by explicitly excluding booking, rates, rooms, reviews, contacts, and precise location, though it does not name alternative sibling tools directly.

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