check_overlap

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

With no annotations supplied, the description carries the full disclosure burden and does substantial work: it defines the geometry used (collision box, otherwise clipping box), states the penetration depth unit, and explicitly says objects without a known box are named rather than silently treated as non-colliding. It also explains the two-tier comparison behavior under 'precise' and that each result pair records which method was used. It does not state whether the call mutates anything or what permissions/limits apply, though 'check' implies a read.

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?

The core question is front-loaded in the opening clause, and both sentences carry information rather than filler. The syntax is dense and slightly convoluted (nested parentheticals, 'project objects ... project objects'), but no sentence could be removed without losing semantics.

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 five-parameter tool with nested placement input, no annotations and no output schema, the description covers geometry, units, the unknown-box case, the precise-mode fallback, and the per-pair comparison provenance, which effectively sketches the response shape. Gaps are minor: no mention of defaults for map/session and no note on cost or expected result size when precise rasters are used.

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 60%, so the description must compensate for the gaps and partially does: it clarifies that 'ids' refers to project objects and that 'placement' is a hypothetical object, and it explains the meaning of 'precise' (raster confirmation of box intersections, handling L-shapes, roofs and gaps) beyond a bare boolean. It says nothing about 'map' or 'session' beyond what the schema already documents, and adds no detail on the placement sub-fields.

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 operation (intersection/overlap check) and the objects it compares: project objects selected by ids, or a hypothetical placement, against static map objects and other project objects. It also states the comparison geometry (rotated boxes) and output metric (penetration depth in m). It does not explicitly differentiate itself from siblings such as query_objects or object_ground, which keeps it below 5.

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?

There is no explicit when-to-use or when-not-to-use guidance, and no alternative tool is named for cases where the caller only needs plain object listings or ground height. The only conditional guidance is embedded in the 'precise' explanation, which describes mode behavior rather than when to pick this tool over a sibling.

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