List hotel chains

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by stating 'No parameters required' and enumerating the returned fields (chain list, numeric IDs, names), which matters since there is no output schema.

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 the answer in the Overview, and the four header sections are easy to scan. It slightly over-structures a trivial 0-param lookup and repeats the 'use chain IDs in search filters' point in both Overview and Quick Start, which is mild redundancy rather than waste.

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 zero-parameter reference-data tool with no output schema, the description covers what it returns, that it needs no input, and how the result is consumed. Nothing an agent needs to call it correctly 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?

The tool takes zero parameters, which is the baseline-4 case. The description reinforces this ('No parameters required. Returns all hotel chains with IDs'), leaving no ambiguity about invocation.

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 Overview states a specific verb and resource ('Get all available hotel chains'), gives concrete examples (Marriott, Hilton, IHG), and names the downstream purpose ('Use chain IDs to filter hotel searches by brand'). This clearly separates it from sibling reference-data tools like get_data_cities, get_data_hoteltypes, and get_data_hotels.

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 'When to Use' section gives three concrete scenarios (chain filters, brand selection, reference data), which is good context. However, it doesn't contrast with the nearest siblings such as get_data_hoteltypes or explain when you'd want chains versus other hotel reference data, so it stops short of explicit alternatives.

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