import_placement_from_kicad

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

Annotations already declare destructiveHint=true and idempotentHint=true; the description adds substantial beyond that: all moves run as one verified command (one undo step), Ignore Violators mode, the consequence that parts may overlap on opposite sides, the side/angle mirroring rule, and the footprint_differs report. Edge cases remain implicit (e.g. parts in the board but absent from the KiCad file, or reference designators that don't match).

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?

Front-loaded with the core action, then organized into a coordinate-frame paragraph and a fit_pads paragraph, so structure is good. It is dense and fairly long, and a couple of parenthetical examples (SOT-23-6, header origin) could be trimmed, but nearly every sentence carries information an agent needs.

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 complex destructive import with no output schema, the description covers the key behaviors: matching key, coordinate conversion, single undo step, dry-run, and the footprint_differs result. Missing pieces are the meaning of 'skip' and how unmatched/extra parts are handled, which leaves a small completeness gap.

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%, so the description must carry the parameters. dry_run and fit_pads are well explained (dry_run reports only; fit_pads default true with the pad-matching behavior and 0.1 mm threshold), and pcb_path is self-evident. However, the 'skip' parameter is never mentioned anywhere, leaving one of four parameters undocumented.

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?

States a specific verb and resource ('import placement ... from a KiCad board (.kicad_pcb)') and names exactly what is transferred (position, rotation, side, matched by reference designator). It cleanly distinguishes itself from siblings import_netlist_from_kicad and import_routing_from_kicad, the latter explicitly ('Routing is not imported').

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?

Explains the operational modes (dry_run=true only reports the moves; fit_pads default true with rationale) and explicitly excludes routing, which routes the agent to the routing-import sibling. It stops short of stating prerequisites such as what board state is expected or when to prefer this over move_part/place_clusters, but the when-to-use context is clear.

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