plasticity_export_obj

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

Annotations declare destructiveHint=false and readOnlyHint=false; the description corroborates and enriches this by stating it never overwrites, specifies output units (millimeters) and orientation (Z up), and says the result reports counts and bounds parsed from the saved file. It omits any mention of write permissions or failure modes, hence not 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?

Three tight sentences, front-loaded with what the tool does, then units/return behavior, then the usage caution. No filler and every clause carries information.

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?

No output schema exists, and the description usefully compensates by describing the returned counts and bounds, which is good. However, for a tool with five required/optional parameters at 0% schema coverage, it leaves parameter behavior entirely unexplained, which is a material gap for correct invocation.

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 does not meet it: ids, path, revision, chordToleranceMm, and angleToleranceDegrees are never mentioned. The unit statement (millimeters) only incidentally hints at chordToleranceMm; the trade-off between tolerance values and mesh quality/file size is 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?

Names a specific verb and resource ('tessellate exact Solid or Sheet bodies' to a 'validated Wavefront OBJ') and states the key constraint ('without overwriting'). Among the export siblings (export_stl, export_step, export_parasolid) the OBJ-format target is 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?

Gives clear context for when this format is appropriate ('a derived mesh for interchange or rendering') and implicitly when not ('retain .plasticity, STEP, or Parasolid as the editable source'). It does not explicitly name a sibling export tool as the alternative, so routing is by inference 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.