Tourist attractions

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

Annotations already declare this a safe, idempotent, open-world read, so the safety profile is covered. Beyond that, the description discloses a meaningful behavioral trait: the result shape depends on mode, and the `attraction_id` mode returns text, coordinates, and type. It leaves the list-mode return shape and any truncation/paging behavior unaddressed.

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?

Three sentences, front-loaded with the primary list behavior before the detail mode, and no filler or marketing language. There is mild redundancy, since "read the description of one" and "you get its text, coordinates and type" describe the same mode twice.

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?

With five parameters, no output schema, and rich annotations, the description does enough: it explains both invocation modes, the key parameter that switches modes, and the cross-tool workflow. The remaining gaps, pagination/`limit` behavior and the exact list-mode payload, are modest given the schema.

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 80% and the schema already explains `city`, `type`, `query`, and `attraction_id`. The description mostly restates the `attraction_id` mode rather than adding new meaning, and it says nothing about `limit` (default 20, cap 60) or how `query` interacts with `type`. Baseline 3 is appropriate when the schema carries the parameter load.

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 names a specific verb and resource and describes its dual mode, listing ('sights, shrines, malls and other places of a city') or reading a single attraction's detail. An agent can immediately tell this is the POI-lookup tool rather than a hotel or search tool. It does not, however, explicitly state what it is not relative to closer siblings like eg_cities or eg_photos.

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 two concrete scenarios: acting as a city guide ("what to see in Mashhad") and sourcing an attraction `id` to pass to eg_search as `attraction_id`. That is actionable routing guidance between tools with a clear handoff. It stops short of stating when to prefer a different tool or what happens if the city is unknown or empty.

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