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

Goes well beyond the read-only/idempotent annotations: it names each classification rule (inclined_face_bears, overlap_read_as_bearing, side_contact_bears_nothing), distinguishes brep-measured geometry from assumptions and reports deviation_deg / deviation_m, explains that absent LoadBearing values become null with reason not_in_file, warns that undetermined and 'no body' must never be read as 'carries nothing', and discloses the 20-pair cap plus n_untested for capped runs. This is exactly the kind of behavioral detail an agent needs to interpret results correctly.

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?

Informationally dense with no filler – nearly every clause defines a distinct output field or rule, and the core idea is front-loaded. The sentence structure is run-on and hard to scan, but nothing is redundant.

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 carries the return-shape burden and does so: it defines rests_on, beside, undetermined, coverage, rests_on_none, n_untested and the 20-pair limit. Minor gaps remain – it doesn't state whether check_contacts must have been run first or any cost/performance expectations for a pairwise body test.

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%, so the baseline is 3; the description mostly restates parameter meaning ('the elements of of', 'which elements may carry or rest on of'). It adds one useful nuance by explaining that rests_on is measured 'carried above, carrier below by world z', but the 'against' default (of plus hulls within 0.05 m) is already documented in the schema.

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?

Opens with a specific framing – 'What rests on what' – and defines the operation as every pair of the elements in 'of' whose bodies meet, classified as rests_on / beside / undetermined. It distinguishes itself from check_contacts by sourcing contacts from that tool's run and adding the bearing classification on top. The phrasing 'for the elements of of' and 'of of' is awkward and slightly obscures readability, but the resource and verb are unambiguous.

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 closing line ('Double-check where loads go: columns, beams and slabs together with what lies below them') gives a use case, and 'from the same body contact run as check_contacts' implies a prerequisite run of that sibling. However it never explicitly states when to use this instead of check_contacts or accept_contacts, nor what to do if no contact run exists – usage is implied rather than spelled out.

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