audit_find_off_grid_components

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

No annotations exist, so the description carries the full burden, and it does well: it explains the failure mode being detected (ERC silently passes, netlist connection missing), the read-only audit nature implied by 'Find', and the corrective action ('snap to -dx/-dy or whichever direction is closer'). It never explicitly states the operation is non-mutating or that no changes are applied, which is the one disclosure gap for an unannotated tool.

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?

Purpose is front-loaded in the first line, followed by justification and then Args/Returns. The 'ERC silently passes' paragraph is longer than strictly necessary for tool selection, but it does earn its place by making the stakes of the check concrete rather than decorative.

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?

An output schema exists, yet the description still documents the return shape (checked, violations, grid_mils, items with dx/dy) and even how to act on the magnitudes. Combined with the parameter guidance, an agent has everything needed to invoke and interpret this audit correctly.

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 compensate, and it does: it names grid_mils, states the default of 100 mils, and gives a concrete decision rule (use 50 for half-step grids) that the schema's bare integer does not convey. The added value is real but limited to a single parameter.

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 opening line states a specific verb and resource ('Find schematic components placed off the snap grid'), which is immediately distinguishable from sibling audits such as audit_find_floating_ports or audit_find_invalid_regions. The follow-up paragraph makes the precise defect class unambiguous (symbol looks wired, pin doesn't touch, ERC passes silently).

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?

It gives clear situational context for running the audit (grid best practice, the 'edited around it and never resnapped' trap) and tells the agent when to deviate on the parameter ('use 50 if your sheets are set to a half-step grid'). It stops short of naming explicit alternatives (e.g., obj_set_grid or pcb_snap_to_grid for remediation) or stating when not to run it.

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