eda_pcb_primitive_arc_get_all

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the return is a Promise resolving to an array of IPCB_PrimitiveArc, and that filtering by net, layer, or primitiveLock is possible, but it does not disclose whether the returned arrays are raw object references or copies, whether the operation is read-only (it is, by name), what happens with no arguments (likely returns all arcs in the document), or any error conditions. The behavior of the optional filters is also not explained (e.g., how layer filtering works, what primitiveLock does).

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 short and front-loaded with the signature and the key purpose. The Chinese phrase '获取所有圆弧线' is redundant with the signature but confirms the purpose. The return type annotation adds useful detail. No filler words, but the bilingual repetition is slightly redundant.

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?

The tool is simple: a read-only getter returning an array. The description covers the purpose, signature, and return type. However, it lacks details about the meaning of the optional parameters (especially `primitiveLock`, which is opaque), what object the arcs belong to (the active PCB document? a specific window?), and how the optional filters interact. Given the schema has no descriptions for inner parameter types and no output schema, the description could be more complete.

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?

The schema description coverage is 100%, as both `args` and `windowId` are described in the schema. The description lists the official signature `getAll(net?, layer?, primitiveLock?)`, which adds the parameter names and suggests they are optional filters, but it doesn't explain the meaning of `primitiveLock` or the type `TPCB_LayersOfLine`. The description adds the parameter names beyond the generic schema, but the schema already describes the parameters as a JSON array; the description's value is marginal.

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 begins with the method signature `pcb_PrimitiveArc.getAll(...)` and a Chinese phrase '获取所有圆弧线' which translates to 'Get all arc lines.' This clearly states the verb (get) and the resource (all PCB primitive arcs), and the return type `Array<IPCB_PrimitiveArc>` adds specificity. However, it doesn't explicitly distinguish itself from sibling tools like `eda_pcb_primitive_arc_get_all_primitive_id` (which likely returns only IDs), so it's clear but lacks explicit sibling differentiation.

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 does not provide any guidance on when to use this tool versus alternatives. The sibling list includes `eda_pcb_primitive_arc_get`, `eda_pcb_primitive_arc_get_all_primitive_id`, and other primitive get_all tools (e.g., `eda_pcb_primitive_line_get_all`), but the description doesn't explain which one to choose. The optional parameters (net, layer, primitiveLock) imply filtering use cases, but the description never states that.

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