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

No annotations are provided, so the description carries the full burden. It discloses the data source (OpenStreetMap) and that reverse geocoding returns the nearest address, which is useful behavioral context. However, it does not state whether the operation is read-only, whether API keys or rate limits apply, or how results are ordered when multiple matches exist. The output schema covers return values, so that gap is less critical.

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 sentences, front-loaded with the core operations and source, followed by usage contexts. There is no filler or repetition, and every phrase contributes information.

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 tool has five optional parameters, no required parameters, and an output schema. The description explains the two operational modes and the provider but leaves significant ambiguity about which parameters trigger forward versus reverse geocoding, what defaults apply (lang='en', limit=5), and whether q is required for forward geocoding. For a dual-mode lookup tool, this is adequate but incomplete.

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%, so the description must compensate for all five undocumented parameters. It conceptually explains that an address string (likely q) produces coordinates and that coordinates (likely lat/lon) produce an address, but it never maps these concepts to parameter names and does not mention lang or limit at all. An agent can infer the main inputs but not the full schema usage.

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 specific actions: converting an address/place/landmark into coordinates with a structured address, and converting coordinates into the nearest address. It names the data source (OpenStreetMap), making the tool's purpose clear. It does not explicitly differentiate from nearby lookup siblings like postal_code or country_info, but it is specific enough to be understood 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?

The description gives clear usage contexts: maps, delivery, distance calculations, or location lookups. It lacks explicit exclusions or alternative tool guidance, but for a standalone geocoding utility with no direct sibling, this is sufficient context for an agent to know when to use it.

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