buildings_near

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered by structured data. The description adds two useful facts beyond that: results are radius-bounded and EGIDs are returned as identifiers. It says nothing about ordering of results or what happens when nothing falls inside the radius.

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?

A single compact fragment with the resource and the spatial qualifier front-loaded and no filler. It is arguably too terse — written as a noun phrase rather than a sentence — but nothing is wasted.

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?

For a 4-parameter read-only lookup with full schema coverage and complete annotations, the description covers the essentials: point-based lookup, radius bound, EGID output. It leaves the agent guessing about result ordering, empty-result behavior, and how it relates to search_buildings, which keeps it at minimum viable.

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 100%, with lat/lon marked WGS84 and radius/limit carrying defaults and maxima, so the schema does the heavy lifting. The description only echoes the WGS84 coordinate frame and the small-radius constraint, adding no new parameter meaning; 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?

The description names a specific resource (GWR buildings) and operation (nearest to a WGS84 point), plus the key returned identifier (EGIDs). It is distinguishable from siblings like search_buildings or get_building, though it never explicitly states that contrast.

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 parenthetical '(small radius)' implies this is for tight proximity lookups rather than broad searches, which is useful routing information. However, no alternative tool is named and no explicit when-not condition is given (e.g. use search_buildings for attribute-based queries).

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