production.character_analyze_intersections

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so safety is covered. The description adds genuine value by flagging the result as 'conservative' and that confidence and limitations accompany the output, but it does not say what confidence means, how overlaps are counted, or what the limitations are.

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?

Two tight sentences with the core behavior front-loaded and the reference-mode qualifier second. Dense jargon (BVH, topology, region pair) costs a little readability 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?

An output schema exists, so the mention of confidence and limitations is sufficient without spelling out return values. However, the description omits prerequisites such as whether the object needs an active manifest or defined regions before region-pair analysis is meaningful.

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% across 3 parameters, so the description carries the load. It usefully qualifies reference_object (same topology required, changes output to only new overlaps), but manifest is never explained and object_name is only implied by context, leaving one of three parameters undocumented.

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 analysis result: self-intersection detection via BVH triangle overlap, reported per region pair, with an optional reference comparison. That is more concrete than most sibling 'analyze' tools, though it never names a distinguishing scope against nearby candidates like physics_analyze_penetration or deformation_analyze.

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 reference_object clause implies a usage mode (before/after comparison against same-topology geometry) but frames it as a parameter behavior rather than a when-to-use rule. There is no statement of when to prefer this over the other penetration/deformation tools, nor any exclusions or prerequisites.

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