Kicad Drc

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

No annotations are provided, so the description carries the full burden. It discloses that a report is produced and that schematic_parity changes what is inspected, which is useful. But it omits whether the tool mutates anything, what occurs when outdir is empty, whether failures raise errors or are reported in the output, and any exit/severity semantics.

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?

Three short sentences, front-loaded with the core action and the target file. 'Returns the report' is mildly redundant given an output schema exists, but nothing is bloated or disordered.

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, so return values need not be detailed. Still, for a 3-parameter tool with zero annotation coverage and zero schema descriptions, the definition leaves outdir unexplained and says nothing about side effects or failure handling, leaving real gaps.

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 0%, so the description must compensate and largely does not. It explains schematic_parity's behavior and implies pcb is the target file, but outdir is never mentioned and no path/format expectations (absolute vs relative, default output location) are given for pcb.

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 (Run) plus the named resource (KiCad Design Rules Checker) and the exact input artifact (.kicad_pcb file). The mention of schematic_parity against the sibling .kicad_sch clarifies what this tool is not (it is not the schematic-side kicad_erc). An agent can distinguish it from siblings without opening the schema.

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?

Usage is implied: run this to check a PCB for design-rule violations. However, it never states when to prefer this over kicad_erc, when parity checking is warranted, or any prerequisite (e.g. board must exist / be readable). The flag semantics are explained but routing guidance is absent.

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