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

With no annotations, the description carries the full burden, and it delivers: it explains the dry-run vs edit behavior ('With write=true it edits the board'), the automatic re-run of DRC, and the self-protective file restore if any non-silkscreen result changes. It also notes footprints are never moved and KiCad must be closed.

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 dense sentences carry the action, scope, safety behavior, and precondition with no filler. The most important facts (what and when) are front-loaded, and every sentence adds information.

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?

The description is strong on high-level behavior and safety, but incomplete for invocation because it omits the meaning of the required 'board' parameter and 'min_size'. Since there is no output schema or annotation support, these gaps are not filled elsewhere.

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% and the description only clarifies one parameter's effect ('write=true'). It never explains what the required 'board' field should contain (path vs content) or what 'min_size' controls, leaving the agent to guess at important input semantics.

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 names a specific verb ('Move') and resource ('reference designators flagged by DRC...' on the board), and explicitly states what it does not do ('Never moves footprints'). This clearly distinguishes pcb_fix from the schematic-focused siblings like sch_fix and from pcb_lint, which detects rather than fixes.

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 implies when to use it: after DRC flags reference designators, and emphasizes the write=true dry-run/edit split. It also gives a hard prerequisite ('KiCad must be closed'), but it does not explicitly name alternatives or state when not to use this tool.

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

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 explains the default behavior (silkscreen findings only) and the effect of all=true, which is meaningful behavioral context. It does not explicitly state read-only behavior or output format, but 'DRC' and 'findings' imply a non-mutating analysis.

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?

Two short sentences with no filler. The core operation is front-loaded, and the default-vs-all behavior is packed into the second sentence without redundancy.

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 simple two-parameter tool with no output schema, the description covers the essential context: what it operates on, what it checks by default, and how to broaden the check. It leaves minor gaps around output shape and exact board path semantics, but these are not critical for invoking the tool.

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. It does: 'a .kicad_pcb' clarifies the board parameter, and 'all=true for everything' explains the boolean parameter. It does not detail path/format expectations for board, but the core semantics of both parameters are conveyed.

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 names a specific resource (a .kicad_pcb file) and a specific operation (KiCad DRC), which clearly distinguishes it from schematic-focused siblings like sch_lint. It also states the default scope (silkscreen findings), making the tool's purpose concrete.

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 makes clear this is for PCB DRC, so an agent can infer when to choose it over sch_lint or pcb_render. It does not explicitly name alternatives or exclusion conditions, but the resource and operation are specific enough to route usage correctly.

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

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

With no annotations, the description carries the behavioral burden. It discloses the output format (PNG), the default layer set, the coordinate unit (mm), and the overlay behavior of boxing silkscreen findings. It does not define 'findings' further, but enough behavior is disclosed for a render 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?

Two compact sentences pack the core purpose, layer scope, output details, and parameter usage without wasted words. The phrase 'as an image' is mildly redundant after 'PNG', but overall the description is efficient and front-loaded.

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?

The description covers the main rendering behavior and parameter syntax, but there is no output schema and no guidance about the required 'board' parameter, layer list formatting, or relationships/conflicts between 'around' and 'region'. A capable agent could infer a basic call, but important invocation details remain implicit.

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. It explains 'around' and 'region' with units and format, but the required 'board' parameter is completely undocumented, and 'layers' only benefits from the schema default. The compensation is partial.

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 clearly states the tool produces a PNG image of a board region and lists the relevant layers (F.Cu, silkscreen, courtyards, edge). It is distinct from the schematic sibling by explicitly saying 'board region', so an agent can tell pcb_render apart from sch_render.

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: use 'around' with references or 'region' with coordinate bounds in mm. It does not explicitly name alternatives or exclusion conditions, but the PCB/board context and sibling names make the intended use clear.

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

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

No annotations are provided, so the description must carry the behavioral disclosure burden. It states a non-destructive listing action, which implies read-only behavior. It doesn't disclose whether any design context is required or if the list is global, but for a simple query tool, the description adequately communicates its behavior.

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, focused sentence that front-loads the core action ('List') and resource ('lint check codes'). Every word earns its place; no filler or redundancy.

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 tool with no parameters, no output schema, and no annotations, the description is complete. It specifies exactly what the tool returns (codes with severity and meaning) and nothing else is needed for an agent to call it 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?

The tool has zero parameters, and schema coverage is 100% (vacuously). The baseline for zero parameters is 4. The description doesn't need to add parameter semantics since there are none, and it correctly omits any param information.

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 clearly states the tool lists lint check codes with severity and meaning. It uses a specific verb ('List') and resource ('lint check codes'), which distinguishes it from siblings like sch_lint (which likely runs the checks) and sch_inspect (which inspects something). The purpose is unambiguous.

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 implies usage: when you need to know lint codes and their severity/meaning, use this tool. However, it doesn't explicitly state when to use it versus alternatives like sch_lint, nor does it mention exclusions or alternatives. There is no misleading guidance, but it relies on the agent to infer context from the description.

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

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

With no annotations provided, the description carries the full behavioral burden and does so exceptionally well. It discloses the dry-run default, the write-then-verify-and-restore workflow, the hard safety constraint (never touches symbols/pins/wires/connectivity), and the external precondition that KiCad must be closed.

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 dense sentences, each carrying essential information: the operation, the safety boundary, the dry-run/write semantics, and the external precondition. There is no fluff, and the most important action is front-loaded.

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?

The description is largely complete given the schema already covers sheet, project, and horizontal parameters. The main gap is the absence of any statement about what output is produced during a dry run, but this is minor alongside the strong behavioral coverage.

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 60%, so the description needs to add partial value, and it does. The 'dry run by default' statement clarifies the write parameter's default behavior, and 'local labels' maps directly to the labels parameter. It does not explicitly cover sheet or horizontal, but those already have schema descriptions.

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 clearly states a specific action and resource: 'Move symbol fields (reference, value) and local labels out of collisions.' It also adds a differentiating scope clause ('Never touches symbols, pins, wires or connectivity'), which helps distinguish this fix tool from sibling analysis/rendering tools.

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?

Context is implied: use this when symbol fields or local labels collide, and it is safe for a dry run by default. However, there is no explicit statement of when to prefer this over siblings like sch_lint or sch_free_space, and no when-not-to-use guidance beyond the structural exclusion.

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

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

No annotations are provided, so the description must carry behavioral disclosure. The verb 'Find' and the phrase 'without collisions' imply a non-mutating search with grid alignment. However, it does not describe the return shape, behavior when no free space exists, or the optionality/default of 'near'.

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?

Two short sentences with the core capability first and the use case second. There is no filler, no repetition of schema properties, and every sentence earns its place.

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?

With no output schema and no annotations, the description leaves out important invocation details: what the return value contains, how many candidates are returned, and what happens if no free rectangle exists. It is usable but not fully specified.

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 description adds useful meaning to w and h as mm dimensions and clarifies that near is a point. Since schema coverage is only 50%, this partially compensates, but 'count' is undocumented in both the schema and the description, and optional parameter behavior is not explained.

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 names a concrete operation: find free, grid-aligned rectangles of a given w x h mm on a page, nearest to a point. This clearly distinguishes it from sibling tools like sch_lint or sch_render, which perform different inspection or rendering actions.

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?

'Use to place a new block without collisions' provides a clear use context and tells an agent when this tool is relevant. It does not explicitly name alternatives or when-not-to-use cases, but the guidance is specific enough for selection.

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

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

With no annotations provided, the description carries the full burden. It discloses the output categories (pin coordinates, direction, boxes, and conditional labels/wires) and explains the conditional behavior based on the refs parameter. It does not mention side effects (implied read-only) or error handling, but for an inspection tool this is sufficient. It adds value beyond the schema by explaining the refs-dependent behavior.

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 concise sentences: the first states the core output, the second adds the conditional behavior, and the third gives usage advice. Every sentence is purposeful, and the essential information is front-loaded. No redundant or filler content.

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?

The description is complete for a read-only geometry inspection tool. It specifies what the agent will receive (geometry, labels/wires when applicable) and when to use it. It does not describe return format in detail, but without an output schema, the description provides enough context. It could mention read-only nature or error conditions, but these are minor gaps given the simplicity of the tool.

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 schema covers 67% of parameters (project and sheet have descriptions), but refs lacks a schema description. The description adds meaning to refs by stating that without it, labels and wires are also listed, clarifying the parameter's effect on output. This goes beyond the schema's coverage, so the description compensates for the gap.

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 clearly states the tool's function: it provides exact geometry of symbols (pin tip coordinates, pin direction, body box, field boxes) and, conditionally, labels and wires. This distinguishes it from siblings like sch_lint (linting), sch_render (rendering), and sch_fix (fixing) by focusing on geometry inspection.

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 explicit usage guidance: 'Use before drawing wires so they land on pin tips.' This tells the agent when to invoke the tool. It does not explicitly mention alternatives or exclusions, but the purpose is clear enough that the agent can infer it is for pre-wiring geometry checks. No misleading guidance.

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

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

With no annotations provided, the description carries the behavioral burden. It states the tool 'finds' problems and gives the coordinate convention ('mm, y down'), implying a read-only analysis, but it never explicitly says whether the tool modifies files or how it returns results. This is a useful but incomplete behavioral disclosure.

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 two sentences plus a coordinate note, with the core purpose front-loaded and a compact, specific list of checks. No wasted words; every clause contributes directly to selection or invocation.

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?

The tool has no output schema and no annotations, so the description should clarify what the tool returns and whether it has side effects. It gives a good sense of the check scope and coordinate system, but omits output format and read-only guarantee, leaving some ambiguity for an agent deciding how to use the result.

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 75%, and the description adds little beyond the schema. It does not expand on 'codes,' 'sheet,' or 'severity,' but the list of layout problems implies what the checks cover, and the schema already provides useful descriptions for three of the four parameters. The description does not meaningfully compensate for the undocumented severity 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 description opens with a specific verb and resource ('Find layout problems in a KiCad schematic') and enumerates concrete check categories (overlapping texts, text on symbols, dangling wires, etc.), which clearly set it apart from pcb_lint and other schematic tools. The list makes the tool's scope immediately identifiable without needing to open 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?

The description explicitly says 'Run after every schematic edit,' giving a clear trigger and context for use. It does not name alternatives or state when not to use this tool, but the usage context is strong enough for an agent to infer when it applies.

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

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

With no annotations provided, the description must carry the burden of behavioral disclosure. It reveals that output is an image and that findings are overlaid, and mentions tiling behavior. However, it does not explain side effects (e.g., file modifications), limitations (max_images), or the exact return format. While some behavior is disclosed, significant gaps remain, especially given the absence of annotations.

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 two sentences with no filler. It front-loads the core purpose and follows with actionable usage tips. Every sentence adds value, making it appropriately concise and well-structured.

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 tool with 11 parameters, no output schema, and no annotations, the description is notably incomplete. It omits details on the return format (image path, base64, etc.), how findings are overlaid (severity filtering?), the effect of 'max_images', and the difference from sch_inspect. The description covers purpose and a few usage tips but leaves many operational aspects unexplained, making it insufficient for an agent to invoke correctly without further investigation.

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 low (45%), so the description must compensate. It adds meaning for 'region' and 'around' by explaining their zoom purpose, and for 'tiles' via the readable tiles note. However, it does not clarify parameters like 'max_images', 'severity', 'findings', 'grid', or 'boxes', leaving them to the schema or inference. The description adds some value but only partially addresses the coverage gap.

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 clearly states the tool renders a page to PNG with findings boxed and numbered, referencing sch_lint for style. It distinguishes itself from linting tools by focusing on visual output. Specific verb 'Render' and resource 'page' make the purpose unmistakable.

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 practical guidance on using 'region' or 'around' for zooming and 'tiles' for splitting full sheets, which helps the agent decide on parameter usage. It implies the tool is for visual inspection but does not explicitly contrast with sibling tools like sch_inspect or sch_fix. The context is clear enough for typical rendering needs.

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

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

With no annotations provided, the description must carry the behavioral burden. It does explain the comparison activity and the one-time post-update usage, which is helpful. However, it does not disclose whether the tool modifies any files, requires kicad-cli to be installed, produces output, or how failures are surfaced.

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?

Two short sentences with no filler. The main action is front-loaded and the usage timing is given immediately after. Every word earns its place.

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 one-parameter tool with no output schema and no annotations, this is adequate but not complete. The description explains what and when, but lacks return behavior, side-effect expectations, and any mention of external dependencies like kicad-cli availability.

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 schema already fully describes the single 'project' parameter, including acceptable path forms. The description's 'for a project' adds little beyond the schema, so the baseline 3 is appropriate.

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 ('Compare'), the two resources involved ('text geometry model' and 'kicad-cli PDF output'), and the scope ('for a project'). This clearly differentiates it from sibling tools like sch_lint, sch_inspect, and sch_fix, which have distinct purposes.

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 an explicit, actionable usage condition: 'Run once after a KiCad update.' This tells the agent when to invoke the tool. It does not explicitly mention alternatives or when not to use it, but the timing guidance is strong and contextually useful.

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