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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered; the description adds the useful behavioral fact that results differ by scope (global vs city vs destination page) and that country_id takes precedence over city_id. It does not mention pagination, result counts, or freshness of the hot-word list, which would have pushed this to a 5.

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?

It is front-loaded with the core action and the scoping rules follow in a logical order, with no filler. The first sentence is long and packs a six-item payload list inline, making it denser than necessary, but nothing is 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 a two-parameter, zero-required, read-only lookup with an output schema and full schema coverage, the description supplies everything an agent needs: what comes back, how each parameter state changes the result, and which sibling to use instead. Return-value detail is technically redundant with the output schema but does no harm.

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 100%, so the baseline is 3, and the schema already states that country_id selects the destination-page set and that city_id is ignored when country_id is set. The description adds one genuinely new case the schema omits (omitting both yields the global start-page set) plus an example value ("12 Japan"), which is helpful but marginal against a fully documented schema.

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 opens with a specific verb and resource ("Return the hot search keywords Klook shows on its search start page or on a destination page") and immediately enumerates the payload (hot-word list plus curated topic tabs with item ids, titles, prices, icons and landing URLs). It explicitly separates itself from klook_hot, which "returns curated destination/activity lists instead of search keywords," so an agent can distinguish the two without opening either schema.

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?

It gives explicit routing rules for each parameter state: country_id for the destination-page set, city_id for a city-scoped start page, and omitting both for the global start-page set. It also names the downstream action ("pass a hot word to klook_search") and the alternative to avoid (klook_hot), covering when-to-use, when-not, and what to do next.

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