recommend_quiet

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

With no annotations, the description carries the full behavioral burden and delivers substantially: results are ordered by lowest average concentration rate within the same region, the agent must not reorder them, and it must tell the user that the recommendation is congestion-based and based on predicted values. It also discloses that concentration rate does not combine with categories. These are concrete behavioral traits well beyond what the tool name implies.

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 compact and well-structured: purpose first, then ordering and presentation rules, then the routing exception to list_places. Every sentence earns its place — the don't-reorder instruction and the category exclusion are both material to correct invocation and response formatting, with no filler.

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?

The description is complete about behavior and routing but silent on parameter semantics (especially the required cd) and the return shape, with no output schema or annotations to fill those gaps. For a 3-parameter tool with one required opaque code and no documented result format, an agent still needs additional context — likely resolve_area — to invoke it correctly.

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 0%, and the description does not explain any of the three parameters: cd (required), days (default 7), and limit (default 5). The phrase 'a few days' hints at days' purpose and 'region' hints at cd, but limit is entirely unexplained and cd is opaque, so an agent cannot confidently populate the required argument without external context.

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 states a specific verb and resource: 'recommend tourist attractions predicted to be quiet in the region over the next few days' (지역에서 앞으로 며칠간 한적할 것으로 예측되는 관광지 추천). It specifies the scope (region, multi-day prediction) and the basis (concentration/congestion rate), and it explicitly differentiates itself from list_places for category-specific requests, so an agent can distinguish it from siblings.

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 an explicit when-not-to-use rule: for requests that pin down a category (camping, wellness, food), use list_places instead, with the rationale that the concentration rate targets tourist attractions and does not combine with categories. This is a clear exclusion with a named alternative, but it does not establish routing boundaries against the other siblings such as get_crowding or find_attraction.

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