autocad_array_polar

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

Annotations already declare readOnlyHint=false, destructiveHint=false and idempotentHint=false, so the mutation/safety profile is covered. The description adds real context beyond that: the original entity is retained and (count - 1) new copies are appended, and the call returns a JSON status with the original plus copy handles — telling the agent the write is additive rather than a replacement.

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?

Front-loaded one-line purpose followed by a compact Args block and a one-line return summary; no filler sentences and no repetition of prose. The Args list is dense but every line maps to a distinct, decision-relevant field.

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 mutating geometry tool with an output schema and annotation coverage, the description supplies the key operational facts: what is created, that the source is preserved, and the return shape. It stops short of noting error cases (invalid handle, no active drawing) or how to undo, which are minor omissions given the surrounding toolset includes autocad_undo.

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?

Reported schema coverage is 0% at the tool level, so the description has to carry parameter meaning, and it does: it restates handle, center, count (total instances including the original, 2-500) and angle (total DEGREES, 360 = even spacing). The units/inclusivity semantics are the important disambiguators, even though they largely mirror the nested schema text.

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 — 'Create a polar (circular) array of copies of an entity around a center point' — and the qualifier 'circular' immediately separates it from the sibling autocad_array_linear. An agent can select it correctly without opening the schema.

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 description says what the tool does but never states when to prefer it over alternatives such as autocad_array_linear or repeated autocad_copy_entity calls, nor any precondition (e.g., an open/active document, a valid handle). Usage is only implied by the phrase 'polar (circular) array'.

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