pattern

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

With no annotations, the description carries the full burden and does substantial work: it discloses that nothing is persisted without model_save, that each call either ends with an active feature or is rolled back, and that out-of-part instances silently change nothing so volume must be compared before/after. The remaining gap is the failure/return behavior of the call itself, which it only gestures at via model_info and preview_image.

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 content is dense and nearly every sentence carries information, but the tool-specific purpose does not lead — the shared preamble about the plugin, units, axes, and save behavior occupies the front half. An agent must read past boilerplate to find what this specific tool does, and the pattern mechanics are packed into one long final paragraph.

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?

For a 9-parameter, mutation-heavy tool with no annotations and no output schema, the description covers modes, defaults, units, and side effects well, and points at model_info/preview_image for verification. It is short of complete only on the 'feature' identifier format and on what the call returns.

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 only 33%, so the description must compensate, and it largely does: it defines count as total instances including the original, ties angle to type=axis with the 360/count default, ties spacing to type=direction along the plane/edge normal, and defines flip. The 'feature' parameter is never explained (feature name vs id), leaving one required parameter's semantics to inference.

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 verb and resource: "Pattern an existing feature," then qualifies it with the two modes (axis vs direction). It is clearly distinct from siblings like extrude, revolve, hole, and chamfer. It stops short of a 5 because the tool-specific purpose sentence is buried after a shared boilerplate preamble and never explicitly contrasts itself with the other feature-creation tools.

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 concrete routing guidance: "There is no mirror tool: build symmetric shapes with symmetric extrudes, revolves or patterns," and "Check results with model_info (volume, bound_box) and preview_image." It explains which parameter combination selects which mode. It does not state when a pattern is a poor choice (e.g. when instances would fall outside the part, beyond the volume-check hint).

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