eda_sch_primitive_component_create

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

With no annotations, the description must carry behavioral details. It only states the return type (Promise<ISCH_PrimitiveComponent | undefined>) and that it returns a component primitive object. It does not disclose whether the tool modifies the current schematic, whether it requires a selected page, or the effects of parameters like addIntoBom. These are critical for an agent to use it safely.

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, with a single functional line and a short return note. However, it lacks any front-loaded summary that would help an agent quickly grasp the key aspects. The function signature is long and technical, but not wasteful; yet it could be better structured with a clear description first.

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?

This is a complex creation tool with many parameters (component, x, y, subPartName, rotation, etc.) and no output schema. The description does not explain prerequisites, parameter ranges, or the meaning of the return value (e.g., what undefined indicates). With a rich sibling set of component creation tools, more detail is needed to avoid misuse.

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 input schema only documents 'args' and 'windowId', with general descriptions. The schema coverage is 100% for the wrapper parameters, but the actual function parameters are hidden inside 'args' with no descriptions. The description's function signature lists parameter names and types, but does not explain semantics like rotation units or mirror behavior. The description adds some meaning via the signature but not enough to fully compensate for the opaque 'args' structure.

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 it creates a component primitive ('创建器件') and the method signature makes the resource clear. It is distinct from sibling component tools like create_cbb_symbol or create_net_flag, though it doesn't explicitly name those alternatives. The function signature is detailed, leaving no ambiguity about what it does.

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 are no explicit guidelines on when to use this tool versus others like eda_sch_primitive_component_create_cbb_symbol or place_component_with_mouse. The description does not mention constraints like needing an active schematic page or library access. The agent must infer from the name and signature that it's for creating a component from a library item.

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