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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds behavior beyond that: it discloses the ordering options (DISTANCE or POPULARITY) and enumerates the returned fields (place_id, name, formatted address, lat/lng, types, rating, opening hours, attributions), which is the only return-value documentation available since no output schema exists.

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 dense sentences that are front-loaded with the core capability and then the routing rule and return fields. Every clause earns its place, though the return-value enumeration makes the second sentence long.

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 usefully enumerates return fields and covers when to use this vs. the text-search sibling. It falls short on the meaning of several search-shaping parameters (field_mask, language_code, max_result_count), but an agent could still call the required lat/lng/radius path 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 only 38%, so the description carries the compensation burden. It restates what the schema already documents (radius in meters, included_types example, rank values) but says nothing about field_mask, language_code, or max_result_count, leaving the majority of parameters undocumented in both places.

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?

States a specific verb and resource ('List places within a radius ... of a lat/lng') plus scope (geographic radius search, optionally filtered by type, ranked by distance/popularity). It explicitly names the sibling it is not (places_search_text) for free-text/name/city queries, so an agent can differentiate it without opening a 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?

Gives the precondition ('a lat/lng you already have, such as the user's location or a geocode result') and an explicit exclusion routing rule ('For free-text, name, or city queries use places_search_text instead'). Both when-to-use and when-not-to-use with a named alternative are present.

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