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

Goes well beyond the readOnly/idempotent annotations by disclosing the metered cost (1 lookup against a monthly cap), data retention terms (30 days on Free, indefinitely on paid), and the required "© OpenStreetMap contributors" attribution. These are billing, privacy and legal obligations an agent cannot infer from structured fields.

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?

Four short sentences, front-loaded with what the tool returns, then usage routing, then cost/retention/attribution. Every sentence carries operational value; only the attribution sentence borders on boilerplate but it is a real obligation.

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 the return shape (coordinates, label, address parts). It covers cost and retention but says nothing about multi-result behavior or what happens when no match is found, leaving some ambiguity for a 5-parameter tool with a nested object.

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 100%, so bbox, near, lang and limit are fully documented in the schema and the description need not repeat them. The description adds nothing about parameter behavior such as how bbox and near interact with the query, so the baseline 3 applies.

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 (look up) plus resource (address, place name, point of interest) and names the concrete return values (lat, lon, readable label, address parts) and data source (OpenStreetMap). It distinguishes itself from siblings by naming static_map and privacy_area_map as downstream consumers.

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?

Explicitly says to use it before static_map or privacy_area_map when you only have an address, which is concrete routing guidance. The gap is that reverse_geocode is the obvious inverse sibling and is never mentioned, so the agent gets no cue for choosing between forward and reverse lookup.

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