eda_pcb_primitive_via_get

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 states the operation is a get (read), and `undefined` means failure. However, it does not disclose whether the parameter accepts a single ID or multiple IDs (despite plural name 'primitiveIds'), what happens on invalid ID, whether it operates on the current active window, or any side effects. The description is minimal and leaves key behavioral details unstated.

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 very short: a signature line plus '获取过孔' and a one-line return note. It is not verbose, but it is under-specified. There is no waste, but the brevity means it fails to convey important usage context. This is efficient but incomplete, so a 3 is reasonable.

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 the tool has no annotations, no output schema, and the description only states 'get via' plus undefined-as-failure, an agent lacks crucial context: how to format primitiveIds, whether multiple IDs are allowed, whether windowId is required, and what fields the returned object contains. Siblings like via_get_all and via_get_all_primitive_id clarify the family, but the description alone is insufficient for a correct call in all cases.

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 100%, meaning the schema documents the `args` array and `windowId` parameters. The description mentions the signature `pcb_PrimitiveVia.get(primitiveIds: string)` and return type, which adds a bit of meaning beyond the schema's generic 'JSON参数数组'. However, it doesn't explain the format of primitiveIds (e.g., JSON string, comma-separated list, single ID vs array). Baseline 3 is appropriate since the schema does most of the work, but the description adds marginal value.

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 ('get'/'获取') and resource ('过孔'/'via' primitive) and includes the function signature with return type. The name eda_pcb_primitive_via_get is clear, and the description '获取过孔' (get via) confirms it retrieves a via primitive object by ID. It doesn't explicitly distinguish it from sibling eda_pcb_primitive_via_get_all/get_all_primitive_id, but the singular 'via' and parameter primitiveIds make the distinction reasonably clear.

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?

No explicit when-to-use or alternative guidance is given. However, the description implies this tool fetches a specific via primitive by ID, and the sibling names (get_all, get_all_primitive_id) suggest alternatives for fetching all. The parameter 'primitiveIds' and the return type `IPCB_PrimitiveVia | undefined` imply use when you have a specific primitive ID. This is implied usage, not explicit, so it earns a 3.

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