eda_pcb_primitive_via_create

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It states the return type (Promise<IPCB_PrimitiveVia | undefined>) and that it returns a via primitive object, but does not explain side effects (e.g., creating an object on the current board), potential failure conditions, or any constraints like coordinate units. The signature is technical but lacks practical 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: a function signature, a one-line Chinese action phrase, and a return type. It front-loads the signature and keeps explanations minimal. No filler, but it could be slightly more structured (e.g., separating signature from human-readable summary). Still, it is appropriately sized and efficient.

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 tool with no annotations and no output schema, the description is incomplete. It lacks explanation of parameter meanings, required preliminaries (e.g., having a PCB document open), units for coordinates, and behavior when creation fails (returns undefined). The generic 'args' array format is described in the schema, but the description does not elaborate on how to pass parameters correctly beyond the signature. An agent would struggle to invoke this correctly without additional context.

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 0% for individual parameters (the schema only describes an 'args' array), so the description must compensate. It does: it lists all parameter names, types, and optionality (net, x, y, holeDiameter, diameter, viaType, designRuleBlindViaName, solderMaskExpansion, primitiveLock). The names are mostly self-explanatory, though it does not explain semantics like the difference between holeDiameter and diameter or coordinate units, so it adds substantial value but not full clarity.

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 name 'eda_pcb_primitive_via_create' and description state it creates a via primitive in the PCB, with the Chinese phrase '创建过孔' confirming the action. This distinguishes it from sibling create tools for other primitives (e.g., pad, line, region). However, it relies on the raw function signature and does not explicitly contrast with the via_modify or via_get tools, so it is clear but not fully differentiated from all alternatives.

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?

There is no guidance on when to use this tool versus other PCB primitive creation tools, nor any mention of prerequisites like an active PCB document or coordinate system. The description is purely declarative and does not advise on contexts or exclusions, leaving the agent to infer usage solely from the name.

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