add_plane

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the mutation profile is covered. The description adds genuinely new context — the unit system (mm, degrees, kg) and that verified measurements and error evidence should be inspected — but never explains what a failed or duplicate plane addition does to the model.

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?

Three short sentences, front-loaded with the action, with no filler or repetition. The second and third sentences read as boilerplate shared across the tool family rather than tool-specific detail, which slightly dilutes the density.

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?

This is a destructive, non-idempotent mutation tool with five undocumented parameters and no output schema, so the description must do heavy lifting. It covers units and post-call verification but leaves the parameter contract and the effect of the operation on the document unspecified.

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 0% across five parameters, so the description carries the full burden and mostly fails it: 'base', 'name' and especially 'about' are never explained. The only help is indirect — the stated units imply angle_deg is in degrees and offset_mm in millimetres — which is insufficient for the three string parameters.

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 verb and resource ('Add plane') and identifies the engine that executes it, so an agent knows this creates a reference plane. It does not distinguish the tool from the many other add_* siblings or say how the plane is defined (base/offset/angle), leaving the geometry model implicit.

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 guidance on when to use this versus siblings such as add_sketch, cut_profile_through_plane, or add_extruded_profile_on_plane, and no prerequisites (e.g. an active part document) are stated. 'Inspect verified measurements and error evidence' is post-call advice, not selection guidance.

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