eda_sch_primitive_circle_get_all

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

No annotations are provided, so the description carries the full burden. It does state a return type (Array<ISCH_PrimitiveCircle>) and the Chinese return description, which is useful. However, it discloses nothing about side effects (it's a getter so likely safe, but not stated), scope (current window? the windowId parameter suggests window targeting), pagination/limits, or whether it returns empty array vs throws. The description is a terse API doc line, not behavioral context.

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 description is compact: one code signature line, one Chinese phrase, one return description. It's brief but not padded. However, the code signature 'sch_PrimitiveCircle.getAll()' is redundant with the tool name and the mixed-language content could be clearer for an AI agent. Still, every line earns its place.

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?

Given no annotations and no output schema, the description is incomplete. It doesn't explain what 'circles' refers to (schematic primitive circles in the current document?), how windowId affects the result, what the args array is for (this getAll takes no args?), or any error behavior. For a getter with no schema on return, an agent would benefit from knowing scope and return shape. The name and code signature provide some context, but the description leaves too much implicit.

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 both parameters (args, windowId) are described in the schema. The description adds nothing about the parameters—'args' as a positional JSON array and 'windowId' for target window are only in the schema. Baseline 3 applies since the schema already covers the parameter meanings.

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 'sch_PrimitiveCircle.getAll()' and '获取所有圆' (get all circles), clearly indicating a get-all operation for circle primitives in the schematic. It returns '圆图元对象数组' (circle primitive object array). While it doesn't explicitly emphasize the 'no filtering' aspect, the verb 'getAll' and the return type make the purpose clear. Sibling tools like eda_sch_primitive_circle_get or eda_sch_primitive_circle_get_all_primitive_id are distinguishable by name, but the description doesn't explicitly differentiate from them.

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 lacks any guidance on when to use this tool versus alternatives. There's no mention of when to choose getAll vs get vs getAll_primitive_id, no context about whether it operates on the active document or all documents, and no exclusions or alternative tool references. The windowId parameter hints at document targeting but the description doesn't clarify its behavior.

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