Update a component in place

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

Annotations already flag destructiveHint=true, so the agent knows the tool mutates. The description adds non-obvious behavior: the update preserves position, matching is by name rather than by unique ID, and dry_run=true enables a no-write preview. It stops short of specifying whether fields omitted from the provided object are wiped or retained, but the position-preservation and match-by-name disclosures go beyond the annotation payload.

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?

Four sentences and roughly fifty words carry the entire operative contract: action, scope, per-library payload selection, matching key, and preview mechanism. It is front-loaded with the action and contains no redundant restatement of the title or schema.

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 destructive 5-parameter tool with two deeply nested payload schemas and no output schema, the description covers the two decisions that determine a correct call: which object to pass per library type and how to preview without committing. It leaves edge cases unstated (how library type is determined, behavior when both symbol and footprint are supplied or neither), but an agent following the read-modify-write workflow has what it needs.

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 description coverage is 100%, so the baseline is met by the schema itself. The description adds cross-parameter semantics the schema cannot express: footprint applies only to PcbLib files, symbol only to SchLib files, component_name is the match key, and dry_run gates the write. This conditional linkage is genuinely additive.

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 action ('Update a component in-place within an Altium library file'), a clear resource (a component in an Altium library file), and explicit scope ('preserving its position', 'matched by name'). The 'in-place' qualifier distinguishes it from sibling whole-library writers such as write_pcblib/write_schlib, and the object-selection sentence anchors which payload each library type expects.

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 gives concrete invocation guidance: 'For PcbLib, provide a footprint object. For SchLib, provide a symbol object', plus the safety path 'Use dry_run=true to preview changes without modifying'. It does not explicitly name alternatives or when-not-to-use cases (e.g., vs update_pad/update_primitive or batch_update), so the differentiation is implied rather than stated.

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