eda_pcb_primitive_dimension_get_all_primitive_id

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

The description discloses the return type (Promise<Array<string>>) via the signature Fourier, and the Chinese description confirms it returns primitive IDs. However, it does not mention side effects, read-only nature, error conditions, or the meaning of the optional parameters beyond their names. Since no annotations are provided, the description carries the full burden of behavioral disclosure, which it only partially meets.

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 brief and front-loaded with the function signature, followed by a one-line Chinese description and a return line. It avoids fluff and is easily scannable. The slight redundancy between the signature and the Chinese text is acceptable given the multilingual context, and the structure is clear.

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 simple getter that returns IDs, the description covers the fundamental purpose and return type. However, it lacks usage context such as optional filtering behavior (e.g., what happens if `layer` is omitted), or which document it operates on. The sibling list shows many similar 'get_all_primitive_id' tools, and without explicit differentiation, the agent may be uncertain about the exact scope. It is adequate but not 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 generic input schema only describes 'args' as an array in official signature order)Skip without individual parameter meaning. The description's function signature provides the actual parameter names (`layer`, `primitiveLock`) and types (TPCB_LayersOfDimension, boolean), which the schema lacks. This adds critical semantic value beyond the schema. However, it does not explain the purpose or valid values/orange of these parameters in prose, so a full understanding relies on API knowledge.

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 clearly states a specific action ('获取所有尺寸标注的图元 ID', meaning 'get all dimension primitive IDs') targeting a specific resource (dimension primitives). The included function signature reinforces the purpose with an explicit return type. However, it does not explicitly distinguish itself from sibling tools like eda_pcb_primitive_dimension_get_all (which returns full objects rather than IDs), making it slightly less clear without inspecting other 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?

The description provides no guidance on when to use this tool versus alternatives. There is no mention of 'use get_all for full objects, or use this when only IDs are needed.' The agent must infer usage purely from the name and signature. This is a minimal viable description but lacks the explicit usage context needed for robust tool selection.

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