check_contacts

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

Annotations already declare a safe read-only, closed-world operation, and the description adds genuinely useful behavioral detail beyond them: the exact states returned and, for overlaps, the deep-sample/median-depth/inside-share metrics with an illustrative donut-glaze example. It stops short of noting performance or mesh-validity prerequisites, but the output semantics are unusually well disclosed.

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 state definitions are front-loaded and the two sentences carry no filler; the donut example earns its place by clarifying a non-obvious metric. Density is high but readable.

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 explains the returned states and overlap metrics, covering the return-value gap. It still leaves the parameters undefined and mirrors the floating-parts use case of a sibling (find_floating) without disambiguating, so an agent has enough to try the call but not to call it confidently.

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% and the two required parameters are named only 'a' and 'b'. The description's phrase 'two meshes' indirectly implies they are mesh identifiers, but it never states that a and b are mesh names/IDs, their format, or their ordering effect. The parameter gap is largely uncompensated.

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 states a specific operation on a concrete resource: reporting the contact state (intersecting/touching/apart) between exactly two meshes, including depth metrics. It is clearly distinguishable from most siblings, though it never explicitly contrasts itself with closely related tools like check_mesh, measure or find_floating.

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?

It gives one concrete use case ('find floating or sunken parts'), which is real usage guidance. However, it names no alternatives (e.g. find_floating, line_of_sight, check_mesh) and states no when-not-to-use conditions, so routing among similar siblings is left to inference.

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