find_attraction

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

With no annotations, the description carries the burden and does disclose a real behavioral quirk: omitting cd can mix same-name attractions from different regions. However, it says nothing about return format, pagination, error behavior, or data scope.

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?

Two short sentences with no filler; the primary purpose is front-loaded and the conditional disambiguation advice earns its place.

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 simple two-parameter search tool the description is mostly adequate, but it lacks guidance on where cd comes from (e.g., resolve_area) and what the result looks like, and there is no output schema to fill that gap.

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 0%, and the description partially compensates by explaining that cd is a region identifier used for disambiguation and that name is the attraction name. It still leaves cd's format, possible values, and source unspecified.

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 tool finds tourist attractions by name (관광지명으로 관광지를 찾는다). It implies a search behavior distinct from sibling detail/list tools, but it does not explicitly name or differentiate from siblings such as get_attraction_detail or list_places.

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 a clear conditional: if the region is known, cd should be provided to avoid mixing same-name attractions. This is actionable usage context, though it does not specify when to prefer this tool over alternatives or point to resolve_area for obtaining cd.

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