object_intersections

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

Annotations only declare readOnlyHint, and the description does add real behavioral content beyond them: the fail-closed failure semantics ('unsupported solvers fail closed rather than approximate silently'), which an agent cannot infer from structured data. The 'Side-effects: None / Read-only' lines merely restate the annotation, keeping it from a 5.

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 behavior and the failure-semantics caveat are front-loaded in the first sentence. Two of the follow-on lines are partly redundant — 'Side-effects: None' and 'Read-only intersection solver' duplicate the readOnlyHint annotation and each other — but the description stays short.

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 an output schema present (no need to describe return values), full schema coverage, and readOnlyHint annotations, the description supplies exactly the missing piece: that unsupported cases error out rather than silently approximating. An agent can call this correctly without further information.

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 schema already documents first_id, second_id, and the extend_mode values. The description echoes the explicit extension mode but adds no format, ordering, or constraint detail (e.g., what happens when the two ids are identical or of incompatible types), so 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?

States a specific verb and resource ('Compute exact supported intersections between two distinct objects') and names the governing knob (extension mode). It is distinguishable from measurement/mutation siblings, though it never names an alternative tool, so it stops short of a 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?

The 'Disambiguation' line gestures at usage ('computes geometric intersection points with extend options') and the phrase 'two distinct objects' implies a precondition, but there is no explicit when-to-use vs when-not, and no naming of an alternative approach (e.g., object_measure) for non-intersection queries.

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