resolve_area

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

With no annotations, the description carries the full burden and does well: 'Builds nothing' declares the operation is non-mutating, and it previews the shape of the returned information. It doesn't address failure modes (unknown place name, malformed bbox) or any lookup limitations, which a zero-annotation tool ideally would.

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 short sentences, each earning its place: capability and return contents first, then input forms, then the non-building caveat. Nothing redundant and nothing buried.

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?

An output schema exists, so return values need not be spelled out, and the description still usefully summarizes them. The remaining hole is input precedence/defaults across three all-optional parameters, which neither schema nor description resolves.

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 0%, so the description must compensate, and it largely does: bbox is given as [west, south, east, north] in degrees and width_km is explained as a square around a place name. It leaves the interaction between the three optional parameters ambiguous — what happens if both place and bbox are supplied, or neither.

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 ('Describe an area') and enumerates exactly what comes back: size, elevation range, available data, and named streams, roads, lifts and peaks. The closing 'Builds nothing' cleanly separates it from the create_model/update_model siblings, so an agent can route without opening schemas.

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?

'Describe an area before building' gives a clear situational trigger, and 'Builds nothing' implies the build step belongs to a sibling tool. It stops short of naming create_model explicitly or stating when-not to call it, so it is clear context rather than a full decision rule.

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