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

Annotations already mark this as read-only and open-world, and the description adds important behavior beyond them: output is TOON text, not JSON; missing fields mean the source did not tag them; opening hours and prices are not present; unknown availability is not treated as free for `only_available`. This gives the agent a realistic model of what the tool can and cannot return.

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 text is long but well-structured: bold labels break it into purpose, required/optional parameters, format, further guidance, and anti-fabrication rules. The core purpose is front-loaded, and while some details are dense, each sentence carries practical information. It is comprehensive rather than wasteful.

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 no output schema, the description compensates by naming the return format (`TOON`), the kinds of fields a hit carries (`category`, `modality`, `parking`, `contactInfo`), and the data limitations. It covers defaults, edge cases, exclusions, and how to get more detail. For a complex eight-parameter tool, nothing essential 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?

Although the schema already documents every parameter, the description adds valuable semantics: `node_types` is one comma-separated string rather than an array, `'any'` does not cover park-and-ride kinds, `'poi'` alone activates a special filter, and shared-mobility offers split the limit. These operational details go well beyond the schema text and materially affect how the agent should construct calls.

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 precise verb and resource: finding stops, POIs, and addresses within a radius around a coordinate, with a clear geographic focus. It also distinguishes itself from name-based search by explicitly routing those cases to `search_place`, so an agent can tell it apart from siblings without opening the 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 clearly states when to use this tool (a coordinate is present) and that name-only queries should first go through `search_place`. It also points to `get_usage_guide` for finer details and flags the `'any'` exception for park-and-ride kinds. It does not explicitly mention other siblings like `reverse_geocode`, but the coordinate-vs-name distinction is sufficient guidance.

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