eda_sch_primitive_component_modify

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

With no annotations, the description carries the full burden of behavioral disclosure. It states that it modifies a device and returns a component primitive object, and the `Promise<... | undefined>` return type hints at possible failure. However, it does not disclose whether property updates are merged or replaced, whether null values delete properties, what undefined signifies, or any document-activity or side-effect requirements.

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 a single dense signature plus a short Chinese action phrase and return note. It contains no filler and front-loads the essential invocation details. It is efficient, though it could slightly restructure to separate the human-readable purpose from the technical signature.

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 lack of annotations and output schema, the return type is useful, and the signature covers the major parameters. However, the description does not explain how to obtain a valid `primitiveId`, whether partial updates are supported, what `undefined` means, or what document/window context is required. This is adequate for a straightforward call but incomplete for reliable selection among many primitive-modification siblings.

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 exposes an opaque `args` array and `windowId`, so the description's full TypeScript signature adds critical parameter meaning. It enumerates `primitiveId` (string or ISCH_PrimitiveComponent) and all optional property fields with types, including `otherProperty`. It does not explain units or semantic relationships, but the property names are largely self-explanatory.

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 specifies a concrete operation through the full method signature `sch_PrimitiveComponent.modify(primitiveId, property)` and the Chinese '修改器件' (modify component). It clearly identifies the resource and action: modifying a schematic primitive component. It does not explicitly contrast with siblings like `eda_sch_primitive_object_modify`, but the name and signature are sufficient to differentiate it.

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. It does not name sibling tools, mention prerequisites such as an open schematic document, or explain when `eda_sch_primitive_object_modify` or `eda_pcb_primitive_component_modify` might be more appropriate. An agent must infer usage entirely from the tool name and signature.

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