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

Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description adds useful behavioral context: no DRC is run and the user should check with drc after saving. It also notes the width defaulting behavior, which is not visible in the schema.

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. The core action and key parameters are front-loaded, and the DRC caveat is placed at the end where it is easy to remember. 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?

The description covers the main parameters, units, default width, and the important DRC caveat. The output schema handles return-value expectations, and annotations cover the destructive nature. The only missing piece is the undocumented 'path' parameter, which prevents a perfect score.

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?

With 0% schema description coverage, the description carries the burden of explaining parameters. It explains points format and units, layer, net, and width default, but it does not mention the 'path' parameter at all. This is a meaningful gap in an otherwise helpful parameter explanation.

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 ('Draw track segments') on a specific resource (points, layer, net), and the mention of 'track segments' distinguishes it from sibling tools like add_via. It is immediately obvious what the tool does.

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 clear context: it draws tracks and explicitly warns that no DRC is run, directing the agent to run drc after saving. It does not explicitly name alternatives or when-not-to-use cases, but the usage context is clear enough for correct invocation.

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?

The annotations state destructiveHint=true, so the description does not need to repeat destructiveness. The description adds that diameter/drill default to netclass, which is useful behavioral context beyond the schema (schema gives defaults of null but not that they are overridden by netclass). However, it does not mention what happens to existing vias or whether the via is placed on the active board layer. Given annotations already cover the destructive hint, a 3 is appropriate.

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, concise sentence that packs significant meaning: placement, coordinates, net, and defaults. It is front-loaded with the verb and resource. Every word earns its place, with no filler or repetition. This is an efficient, high-quality description.

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 6 parameters, 0 required, and no output schema details are given beyond that an output schema exists. The description covers x, y, net, and mentions diameter/drill defaults, but leaves 'path' undefined and does not specify units or behavior of optional parameters. For a placement tool with destructive annotation, more guidance on what constitutes a valid call (e.g., coordinate units) might be needed, but the description is adequate for a basic understanding. It is not complete enough to handle all edge cases.

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. The description explains the meaning of x, y, net (placing via at coordinates) and that diameter/drill default to netclass, adding meaning not in the schema (which just gives defaults of null). However, it does not explain the 'path' parameter at all; for a PCB tool, 'path' likely refers to a net path or connection, but this is unclear. With 0% coverage, the description partially compensates but leaves at least one parameter ambiguous.

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 verb 'Place' and the resource 'through via', and specifies coordinates, net, and defaults to netclass for diameter/drill. It is specific and includes key parameters. It does not explicitly differentiate from siblings like 'add_track', but given the distinct resource (via vs track), the distinction is fairly clear.

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 context: it says 'Place a through via at (x, y) mm on net', which implies the agent should use this when adding a via to a PCB. However, it does not provide explicit guidance on when not to use it or mention alternatives like 'add_track' or other placement tools. It lacks explicit exclusionary info, but the action is clear enough for a basic call.

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?

Annotations already declare readOnlyHint and idempotentHint, establishing that this is a safe, side-effect-free read. The description adds useful context about what data the summary includes, but it does not go beyond annotations into details like caching, performance, or how the board path is resolved.

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 concise sentence that front-loads the core purpose ('Board overview') and then lists the report contents efficiently. There is no redundant wording, though the list of items is somewhat dense and could benefit from grouping.

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 described, and annotations cover safety. However, the description omits guidance on the path parameter and contains no usage context for an agent deciding between board_summary and project_info/schematic_summary. It is adequate but has clear 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%, and the single parameter 'path' is left unexplained in the description. With no information about what path refers to (board file, project directory, etc.), an agent cannot confidently determine how to set this optional parameter. Since coverage is low, the description needed to compensate but did not.

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 the tool provides a 'Board overview' and enumerates the specific content: outline, layers, counts, zones, design rules, and netclasses. This makes the resource and scope clear and helps differentiate it from sibling tools like schematic_summary or net_info, though it lacks an explicit action verb like 'get' or 'summarize'.

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 the tool—when a high-level board-wide summary is needed—but it does not explicitly contrast it with alternatives such as project_info or list_nets, nor does it state exclusions. The scope detail partially compensates, but guidance on choosing among closely related siblings is absent.

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?

Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety and repeatability. The description adds the grouping behavior and the included fields, which is useful context. However, it doesn't mention defaults like include_dnp=false or group_by_footprint=true, nor does it disclose how the output is structured beyond the field names. It adds some value but not rich behavioral detail.

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, concise sentence that directly states the core purpose. It wastes no words. However, the brevity comes at the cost of completeness; it's concise but under-specified. For the conciseness dimension, it earns high marks for efficiency, though it fails to convey needed detail.

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 an output schema (not shown), so return format is partly covered, but the description doesn't explain how parameters affect the output or what typical use cases are. With 3 parameters and no parameter descriptions, the description is too minimal for an agent to confidently use it correctly. It lacks any contextual information about what to expect or how to configure the call.

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%, meaning the description provides no explanation of path, include_dnp, or group_by_footprint. The schema itself lacks descriptions, only defaults. The description does not compensate for this gap, so an agent has no explicit help understanding what these parameters do or how they affect the output. This is a significant deficiency.

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 bill of materials grouped by value and optionally footprint, with specific fields (quantity, references, part-number). It distinguishes from list_components (raw list) but doesn't explicitly name an alternative, so it's clear but not fully differentiated from siblings like board_summary.

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?

No guidance on when to use this tool versus alternatives. An agent has no hints about whether to choose this over list_components or board_summary, or what problem it solves that others don't. The description is purely declarative with no usage context.

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?

The description discloses an important non-obvious behavior: results are cached until the board changes, which goes beyond the `readOnlyHint` and `idempotentHint` annotations. It also clarifies output mode differences and the effect of `parity=true`, adding valuable context without contradicting the 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 compact and front-loaded with the core action, followed by concise conditional details. Every sentence adds value with no repetition or filler.

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 core behavior, caching, and key parameter effects are covered, and an output schema exists to document return values. However, with 6 parameters and no schema descriptions, the lack of explanation for `path`, `limit`, and `include_excluded` leaves the definition incomplete for full autonomous invocation.

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 provides semantics for `type`, `severity`, and `parity`, but the input schema has 0% description coverage and the remaining parameters (`path`, `limit`, `include_excluded`) are left unexplained. This partially compensates for the schema gap but leaves several parameters ambiguous.

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 identifies the tool as 'Run DRC' and specifies the output behavior: counts per violation type without `type`, individual findings with positions when `type` is provided. This makes the purpose understandable, but it does not explicitly differentiate the tool from siblings like `erc`, so it falls short of a full 5.

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 clear context on how to use the tool: without `type` for counts, with `type` for findings, and with `parity=true` to check against the schematic. However, it does not explicitly state when to choose `drc` over alternative tools such as `erc`, so usage guidance is strong but not fully explicit about alternatives.

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?

Annotations already signal read-only and idempotent behavior, so the bar is lower. The description adds useful behavioral context beyond annotations: results are cached until the schematic changes, the output shape depends on `type`, and `severity` accepts only `error` or `warning`. This is meaningful added context rather than repetition 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 compact, front-loaded, and free of filler. The conditional structure ('Without type... With type...') and the severity definition are easy to scan and each part adds value.

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 an output schema and read-only/idempotent annotations, the description covers the main no-argument call path and the key `type` switch well. However, it is not fully self-sufficient for less common invocations because `limit`, `include_excluded`, and `path` semantics are unexplained.

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 for parameter meaning. It explains `type` and `severity`, but `path`, `limit`, and `include_excluded` are left entirely to inference from their names and defaults. For a tool with five parameters, this is a material 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 action ('Run ERC') and resource ('the schematic'), then distinguishes the two output modes based on the `type` parameter. It also identifies the valid severity values, which helps an agent recognize what the tool does at a glance.

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 conditional invocation guidance for `type` and notes the caching behavior, so an agent knows the basic call pattern. However, it does not explicitly say when to prefer ERC over sibling tools like `drc` or when not to use it, leaving cross-tool selection 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.

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

The annotations already declare readOnlyHint and idempotentHint, so safety is covered. The description adds useful context by specifying the lookup key ('by reference') and the exact scope of returned data, going beyond what the annotations alone provide. No contradiction exists.

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?

A single, front-loaded sentence with no filler. The purpose comes first, followed by a compact list of returned content. 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?

The description covers the return payload well, and the output schema likely fills in structural details. However, the ambiguous 'path' parameter and lack of explicit guidance on when to supply it leave a meaningful gap for a two-parameter tool with zero schema descriptions.

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 by explaining parameters. It clarifies 'ref' through 'by reference', but the 'path' parameter is entirely unexplained—its type, default null, and purpose are left to the agent to guess.

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 verb and resource: 'Full detail for one footprint by reference.' It enumerates exactly what is returned (position, bbox, courtyard, fields, 3D model, pads with nets), which clearly distinguishes it from list-style siblings like list_components.

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 rather than explicit: an agent can infer this tool is for retrieving complete detail about a single footprint rather than a summary or list. However, the description does not name alternatives or state when not to use it, such as when only a summary is needed.

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?

Annotations already provide readOnlyHint=true, so the read-only nature is covered. The description adds context about what the selection may contain (footprints, tracks, vias), but does not disclose behavior for an empty selection or whether the result is a list. The output schema exists, so return format is partly handled by structured data, but the description doesn't add much beyond the annotation.

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 concise sentence that immediately states the tool's core purpose and gives a concrete usage example. No wasted words.

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 read-only getter with an output schema, the description covers the main use case and selection content. The main gap is the undocumented 'path' parameter, which slightly detracts from completeness but is not critical for typical usage.

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 only parameter is 'path', which has 0% schema description coverage and is not mentioned in the tool description. The agent has no idea what 'path' refers to (e.g., a document path, a layer path, or something else). The description does not compensate for the schema's lack of explanation.

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 clear purpose: retrieve the user's current selection in the PCB editor, listing example element types (footprints, tracks, vias). This directly distinguishes it from sibling tools like select_components (which sets selection) and items_in_region (which queries by geometry).

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 an explicit trigger: 'Useful when they say "this part" or "these tracks"', which tells an agent when to invoke this tool. It does not mention alternatives or exclusions, but the trigger is specific enough for most cases.

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?

Annotations already declare readOnlyHint and idempotentHint, so safety is covered. The description adds valuable behavioral context: the kinds of items returned and that a layer filter narrows results. It does not contradict annotations and gives a clear picture of the operation's scope.

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, front-loaded with the core query, and contains no redundant phrasing. Every clause adds meaning: the item list and the optional filter. It is optimally concise for the information conveyed.

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?

Given the presence of an output schema (defining return structure) and annotations (read-only, idempotent), the description is nearly complete. It covers the geometry input and layer filtering, but omits details about the path parameter and coordinate ordering. These gaps are minor for a read-only query tool with schema support.

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 the rectangle corners in mm and the optional layer parameter, but does not clarify the 'path' parameter or the order/meaning of the coordinates (e.g., bottom-left/top-right). This leaves partial ambiguity for the agent.

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 clear verb+resource: querying what lies inside a rectangle. It enumerates the item types returned (footprints, tracks, vias, zones, text) and mentions the optional layer filter. This distinguishes it from siblings like measure (distance) and search (text-based) without ambiguity.

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 through its purpose but does not explicitly state when to prefer this tool over alternatives or provide exclusions. The optional layer parameter hints at a narrowing use case, but there is no explicit 'use when' guidance, leaving the agent to infer the appropriate context.

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?

The readOnlyHint annotation already covers the read-only nature. The description adds value by disclosing what state is checked (API-enabled status, open boards/schematics) and by framing the tool as a prerequisite for editing operations. There is no contradiction with the annotation.

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 that front-load the tool's purpose and immediately give the critical usage instruction. Every word earns its place with no 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 read-only status tool with an output schema, the description covers purpose and usage well. However, the undocumented 'path' parameter leaves an actual invocation detail unexplained, so the definition is not fully self-sufficient.

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 has one optional parameter, 'path', with zero description coverage, and the tool description does not mention it at all. An agent has no way to know what 'path' refers to or whether passing it changes the query behavior, making this a significant 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 identifies the tool as a status/preflight check: it asks whether KiCad is running with its API enabled and which boards/schematics are open. It also distinguishes itself from sibling editing tools by stating that it should be called before any of them.

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 instruction 'Call before any editing tool' is an explicit, actionable usage condition. It also explains why: editing tools operate on the board currently open in the KiCad PCB editor. It does not mention when not to use it or name a direct alternative, but for a status gate that is a minor gap.

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?

Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds valuable behavioral detail: output units (mm), the fields returned, and the glob/substring filter semantics with concrete examples.

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 tight sentences with no filler. The core purpose and output fields are front-loaded, followed by a compact and useful filter explanation with examples.

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 an 8-parameter list tool with 0% schema description coverage, the description covers the main filters and output fields but leaves pagination (limit/offset) and dnp/path semantics unaddressed. The output schema helps, but the description alone is not fully complete.

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 clarify ref, value, footprint, and side filters, but omits semantics for dnp, path, limit, and offset, leaving a notable gap for 8 parameters.

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 verb ('List') and resource ('footprints on the board') and specifies the returned fields (position, rotation, side). It is clear what the tool does, though it does not explicitly contrast itself with siblings like get_component or list_nets.

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 explains filter syntax but gives no guidance on when to use this tool versus alternatives such as get_component, select_components, or items_in_region. It lacks when/when-not conditions or exclusions.

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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds genuine value by disclosing the output payload (pad count, routed length, via count) and the sortable columns, but it adds no context about filter/limit behavior or how the listing is scoped by path.

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 zero filler, front-loaded with the resource first and the sort syntax second. 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?

The output schema covers return shape and annotations cover safety, but with four parameters at 0% coverage, the description leaves path and filter semantics unexplained and provides no positioning relative to the many net-related siblings. An agent calling this with a filter or path value would have to guess the expected format.

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 documents the sort parameter's allowed values ('pads | length | name'), which is genuinely useful given the schema offers no enum. However, path, filter, and limit remain entirely unexplained in both the description and the schema.

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 identifies the resource ('nets on the board') and the payload (pad count, routed length, via count), making the purpose evident among PCB-focused siblings. The verb 'list' is implied by the name rather than stated in a full sentence, and differentiation from sch_nets/net_info is implicit via 'on the board' rather than explicit.

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?

No guidance is given on when to use this tool versus siblings such as sch_nets, net_info, list_components, or bom. There are no exclusions, conditions, or alternative tool references — the agent must infer usage from the name alone.

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 readOnlyHint=true already declaring the safety profile, the description adds meaningful context by stating the result reflects unsaved editor edits and the current editor view. It does not contradict the annotation and gives agents a clear expectation that output may differ from the saved board.

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?

One compact sentence with no filler, and the key qualifier ('including unsaved edits') is right at the end but still clear. 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?

Output schema and readOnlyHint cover return shape and safety, and the description conveys the tool's live, unsaved-edits semantics. However, the lack of parameter semantics and explicit usage guidance leaves an agent guessing about invocation details.

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% and the description does not explain what 'ref' or 'path' mean or how they identify a footprint. Mentioning 'footprint' gives a minimal domain hint, but the agent cannot tell which parameter is the footprint identifier or what 'path' refers to.

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 identifies the resource (a footprint) and the data it reports (position, rotation, side), and clarifies it reflects the live editor state rather than a saved board. It lacks an explicit verb like 'get/return,' but the meaning is unambiguous and distinct from siblings that query saved/board data.

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 by the phrase 'as shown in the editor (including unsaved edits)': choose this tool when you need the in-memory/unsaved state of a footprint. It does not name alternatives such as get_component or state when not to use it, leaving the when-to-use guidance implicit.

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?

Annotations already declare readOnlyHint and idempotentHint, so safety is covered. The description adds valuable behavioral details beyond annotations: it specifies the output (dx/dy, centre distance, compass direction, edge-to-edge gap) and the input formats, which enriches the agent's understanding of what the tool does and returns.

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 purpose and then details input formats and outputs. Every sentence earns its place, making it 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 read-only measurement tool with an output schema present, the description covers inputs and outputs well. The only gap is the unexplained 'path' parameter, but since the tool is simple and read-only, the description is largely complete. The output schema handles return value details, so the description does not need to repeat them.

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 provides no descriptions (0% coverage), so the description must compensate. It explains the semantics of parameters 'a' and 'b' (footprint ref, pad, or point in mm) but leaves 'path' completely unexplained. This partial coverage earns a 3, as it helps but does not fully clarify all parameters.

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 measures distance between two items, with a specific verb and resource. It also explains the accepted input formats (footprint refs, pads, points) and lists the returned values, making it distinct from siblings like search or list_components, which serve different 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 implies usage (when you need distance between two items) but does not explicitly state when to use it versus alternatives or mention any exclusions. Since no sibling tool measures distances, the context is clear, but explicit guidance is absent.

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?

Annotations already indicate mutation and destructiveness, and the description adds useful context beyond that: the operation is one undo step and operates on the in-memory open board. This helps an agent understand recoverability and scope, though it does not elaborate on further side effects.

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 tightly packed sentences: the first gives the operation and scope, the second maps parameters to their behavior. Every sentence adds value, and there is no repetition of schema 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 covers most parameter semantics and the operation is reasonably clear, but it does not explain how the target footprint is identified via ref/path or whether either is required. Since all 9 parameters are optional and there is no explicit selection guidance, an agent may struggle to invoke the tool correctly in all cases. Output schema exists, so return values need no explanation.

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?

With schema description coverage at 0%, the description compensates well by explaining the meaning of x/y, dx/dy, rotation, rotate_by, and flip. However, it omits ref and path, which appear to identify the footprint to move; this is a meaningful gap for a 9-parameter tool.

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 ('Move/rotate/flip') applied to a specific resource ('one footprint in the open board'). The singular 'one footprint' helps differentiate it from the sibling tool move_components, which likely handles multiple footprints.

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 clear context: this tool operates on a single footprint in the currently open board. It does not explicitly name alternatives or exclusions, but the singular scope and 'open board' prerequisite are enough to guide basic tool 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?

Annotations already indicate a destructive, non-read-only operation, and the description adds the useful behavioral detail that all moves are grouped into one undo step. However, it does not describe side effects or what happens to existing positions, though the annotation lowers the burden.

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 front-loaded with the purpose, then gives the data shape and a concrete example in three concise sentences. There is no filler or repetition of schema-provided 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?

For a tool with a complex nested moves parameter, the description provides enough structure and an example to invoke it correctly, and an output schema exists so return values do not need explanation. It is slightly incomplete because path is unexplained and the semantics of flip/locked/rotate_by rely on inference.

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 substantially compensates for the schema's empty items definition by specifying exactly what keys are allowed and providing a concrete example. However, the path parameter is completely undocumented in both schema and description, and the units or reference frame for x/y/dx/dy/rotation are left implicit.

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 ('Move'), a clear resource ('several footprints'), and a defining characteristic ('one undo step'). The plural 'several' differentiates it from the sibling move_component, so an agent can distinguish the tools without opening schemas.

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 phrase 'several footprints as one undo step' clearly signals batch usage, implying this is the right tool when multiple footprints need coordinated moves. It does not explicitly name move_component as the single-item alternative or state exclusions, so it falls just short of full 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds behavioral detail about result ordering (nearest first) and included fields (courtyard gap, direction), but it omits edge cases such as behavior when no footprints are in range or how limit applies.

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 sentence with no filler, front-loading the core behavior and using backticks for the parameter. It is appropriately terse, though the brevity leaves some gaps addressed in other dimensions.

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 output schema and annotations reduce the burden, but the description still does not explain `path` or `limit`, which are optional but could affect results. For a simple read-only query tool, the core use case is decipherable, making this minimally adequate.

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 clarifies `radius` is in mm and implies `ref` is the reference footprint, but it does not explain `path` or `limit`. With 0% schema coverage and 4 parameters, this is only partial compensation.

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 the tool's output: footprints near a reference footprint within a radius, sorted nearest first, with courtyard gap and direction. Though it lacks an explicit verb, the resource and spatial relationship are clear, and it is distinct from siblings like items_in_region or search.

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 no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or preferred conditions, so an agent must infer usage solely from the tool's name and phrasing.

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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds the net-matching semantics (case-insensitive, unique substring), which is a behavioral trait of input handling, but it doesn't disclose error conditions, required board state, or performance implications. It adds some value but not substantial behavioral context beyond 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 zero filler. The first sentence front-loads the tool's main payload (what data is returned), and the second gives the relevant input rule. It is appropriately concise for a query tool of this simplicity.

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 presence of an output schema and annotations reduces the burden, but the unexplained path parameter is a notable omission. The description also doesn't clarify whether net is required or how path interacts with it. For a tool with two parameters, this is incomplete.

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 for both parameters. It explains the net parameter's matching rules, but the path parameter is completely undocumented—no explanation of what it is, when to use it, or how it relates to net. This leaves a significant gap for the agent to invoke the tool correctly.

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 identifies the resource (a single net) and the complete set of data returned: pads with pin names, track lengths per layer, widths, vias, zones, and netclass rules. The verb is implied ('get'/'show') but unmistakable. This distinguishes the tool from siblings like list_nets (which only lists net names) and measure (which measures geometry).

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 input formatting guidance ('exact, case-insensitive, or a unique substring') which helps the agent pass the net parameter correctly. However, it does not explicitly state when to prefer this tool over siblings like list_nets or measure, nor does it mention exclusions. Usage context is implied by the purpose, so it's adequate but not explicit.

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?

The readOnlyHint and idempotentHint annotations already communicate that this call is safe and repeatable, so the description bears less burden. It adds useful output content (files, board statistics, sheets) but does not describe any additional behavioral traits such as path resolution or error conditions.

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?

One front-loaded sentence that immediately names the resource and the information returned, ending with a crisp workflow directive. No filler or repetition.

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 read-only tool with one optional parameter and an output schema, the description is largely complete: it tells the agent what it returns and where it fits in the workflow. The only notable omission is path-argument detail, which is minor given the schema's simple optional 'path' property.

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 input schema has a single 'path' parameter with no description, so the description must compensate. Naming the target a 'KiCad project folder' clarifies that the path should point to a project folder, but it doesn't explain expected format, whether null means the current project, or what happens if the folder is invalid.

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 exactly what the tool delivers—an overview of a KiCad project folder—and enumerates concrete contents: files, board size/counts, and schematic sheets. This makes it easy to distinguish from finer-grained siblings like board_summary and schematic_summary, and 'Start here' positions it as the entry point.

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?

'Start here' gives an explicit usage cue that this is the first tool to call before diving into more specific tools. It does not name alternatives or state when not to use it, but the entry-point instruction is clear context.

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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description does not need to repeat the safety profile. It adds useful context about board-wide scope and the typical workflow trigger, but it does not disclose what the refill destroys or replaces, such as existing copper pours.

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, front-loaded sentence with no filler. The core action appears first, and the usage trigger is neatly contained in a parenthetical. 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?

The presence of an output schema and annotations covers safety and return values, and the description gives good trigger context. However, the path parameter remains unexplained, which is a notable gap for an agent that needs to know whether to pass a value or rely on the 'open board' default.

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% and the description never explains the 'path' parameter. The phrase 'open board' weakly implies that path may be unnecessary, but an agent still has no real guidance on what path refers to or when to supply it. With such low coverage, the description should compensate and does not.

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 uses a specific verb ('Refill') and a clear resource ('all copper zones in the open board'), which immediately distinguishes it from sibling tools like add_track, ripup_net, or move_component. It also states the scope ('all') rather than leaving it ambiguous.

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 parenthetical 'needed after moving parts or routing near zones' gives explicit trigger conditions for when this tool is appropriate. It does not name alternative tools or exclusions, but the context is sufficiently clear for an agent to decide when to call it.

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?

Annotations already mark this as readOnly and idempotent, so no mutation warning is needed. The description adds useful behavioral context: it returns a path to a rendered PNG and explains zoom magnification 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?

Two tight sentences, no filler. The core action and key parameter constraints are front-loaded, and every clause adds useful 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 tool is simple and annotations cover safety, but the unexplained 'path' and 'output' parameters create a real usage gap. It is adequate for a basic render call, but an agent may not know how to control output or identify the input board path.

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?

With 0% schema description coverage, the description must carry parameter meaning. It explains 'side' and 'zoom' well, but the 'path' and 'output' parameters are never defined; 'path' in the description sounds like a return value, not a 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 states a specific verb and resource: 'Render the board to a PNG'. The qualifier 'raytraced-lite' distinguishes it from the sibling render_layers and makes the tool's purpose 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 'so you can view it' phrase implies the intended use case, and side/zoom options give helpful context. However, it does not explicitly explain when to choose render_3d over siblings like render_layers or other viewing tools.

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?

Annotations already declare the tool read-only and idempotent. The description adds useful behavioral context beyond that: it returns SVG paths, produces a PNG path on macOS, and explains mirror semantics for bottom-layer viewing. It does not disclose every detail, but with annotations covering the safety profile, this is a solid 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?

Two sentences, zero filler. The purpose and layer-example are front-loaded, and the return format and mirror hint are appended efficiently. 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?

Although the output schema reduces the need to explain return values, path and output remain undefined. An agent cannot reliably know whether path refers to the board file or an output location, or how output relates to the returned SVG/PNG paths. For a tool with four optional parameters rough language model-assisted invocation, this is a meaningful 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 description coverage is 0%, so the description carries the full burden for explaining parameters. It explains layers via comma-separated examples and gives the mirror=true usage, but it completely omits what path and output mean. Since two of four parameters are undocumented both in the schema and description, the description only partially compensates.

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 identifies the tool as a 2D plot of specified layers fitted to the board, with concrete examples of layer names. The '2D' qualifier helps distinguish it from sibling render_3d, and the verb 'plot' plus resource 'layers' makes the purpose explicit.

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 use for 2D board-layer visualization and mentions mirror=true for bottom-side viewing, but it never explicitly states when to prefer this tool over render_3d or other siblings. It provides clear context but no direct exclusions or alternative recommendations.

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?

Annotations already indicate destructive behavior (destructiveHint=true). The description adds the crucial fact that the operation is undoable in the editor, which is beyond the annotations. It also clarifies the conditional vias behavior (unless vias=false). No contradiction with annotations is present.

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 sentence that front-loads the primary action and key options. Every word earns its place; there is no redundant phrasing or filler. It is concise yet covers the essential behavior.

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 destructive nature (via annotations), undoability, and most parameters, but the undefined 'path' parameter is a notable gap. The existence of an output schema may help, but without seeing it, the description itself leaves the tool slightly incomplete for an agent to call correctly with all possible arguments.

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?

With 0% schema description coverage, the description is the only source for parameter meaning. It explains 'net' (the net to delete), 'vias' (whether to delete vias), and 'layer' (optional layer restriction), but completely omits 'path', which remains undefined. This partial coverage leaves a gap for one of the four parameters.

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 action (delete), the resource (tracks and optionally vias of a net), and the optional layer restriction. It distinguishes itself from sibling tools like add_track and add_via, which are additive, and from query tools like list_nets. The verb and resource are specific and 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 use when you want to remove all routing for a net, but it does not explicitly state when to use it versus alternatives, nor does it mention any prerequisites or conditions. There is no 'when not to use' or comparison to other deletion methods, leaving the agent to infer the context.

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?

Annotations already indicate this is a mutating/destructive operation, and the description adds that it persists edits to disk so file-based tools see them. However, it does not disclose overwrite behavior, whether saves are reversible, or what happens when path is omitted. The description does not contradict the 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 a single sentence with the action front-loaded and the rationale in a short dependent clause. Every word adds value; there is no redundancy or unnecessary detail.

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 adequate for a simple save operation and correctly ties the tool to downstream file-based siblings. However, the meaning of the path parameter is left undocumented, and the destructive behavior is only signaled by annotations rather than explained in prose. Output schema presence reduces the need to describe return values.

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%, and the description never mentions the sole path parameter. An agent cannot determine whether path specifies a destination file, is optional, or what the null default means. The tool's only parameter is entirely unexplained.

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 and object: 'Save the open board to disk'. It also clarifies the purpose—making edits visible to file-based tools like measure, drc, and render—which distinguishes this persistence action from the many read-only or in-memory sibling 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?

The description clearly implies when to call this tool: after editing the board and before invoking file-based tools such as measure, drc, or render. It does not explicitly state when not to use it or name alternatives, but there are no obvious competing save tools among the siblings.

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?

Annotations already declare readOnlyHint and idempotentHint, covering the safety profile. The description adds a useful output convention ('blank = unconnected') but does not disclose selection behavior, error cases, or how path/ref interact. No contradiction with 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?

One tightly written sentence, with the key resource first and the detail packed after the colon. 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?

The output schema and annotations cover the return shape and idempotence, and the description communicates the essential payload. However, selection semantics and usage context are missing, so the definition is not fully self-sufficient for an agent choosing among sibling tools.

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?

Both parameters (ref, path) have no schema descriptions and the description never mentions them, so an agent cannot learn how to target a component. With 0% schema coverage, the description was responsible for explaining these but doesn't. The 'one' wording only hints that a selector is needed.

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 the resource ('schematic symbol') and enumerates its contents (fields, library part, sheet, pins with nets), so an agent knows what the tool returns. The word 'One' distinguishes it from the plural sch_components, but the lack of an explicit verb and no distinction from get_component keep it from a 5.

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 no when-to-use guidance, no exclusions, and names no alternatives. 'One' weakly implies a single-component use case, but the agent is not told when to prefer sch_component over get_component or sch_components.

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?

The annotations already indicate read-only and idempotent behavior. The description adds useful behavioral context beyond that by specifying that filters are substrings or globs and listing the output fields, which helps the agent understand matching semantics and what the result contains.

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 short sentences with no filler. The action and key result are front-loaded, and the filter behavior is stated efficiently. 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?

An output schema exists and the read-only behavior is covered by annotations, so the core invocation is understandable. However, the description does not clarify parameter semantics or when to choose this tool over sibling list/component tools, leaving noticeable gaps for a five-parameter tool with 0% schema description 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 description coverage is 0%, and the description does not explain individual parameters like 'ref', 'path', 'limit', 'sheet', or 'value'. It only states that filters are substrings or globs, which is relevant but does not map clearly to the five parameters.

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 verb ('List') and resource ('schematic symbols') and names the returned fields: value, footprint, sheet, and DNP flag. This is clear, though it does not explicitly distinguish itself from the similar-sounding sibling 'list_components' or 'sch_component'.

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 no guidance on when to use this tool versus siblings like 'list_components', 'get_component', or 'sch_component'. It only mentions filtering behavior, not selection criteria or exclusions, so an agent is left to infer appropriate usage.

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?

The annotations already declare readOnlyHint and idempotentHint, so the read-only nature is covered. The description adds useful operational context by specifying the input source (exported netlist) and the kind of aggregated data returned, but it does not disclose edge behaviors such as null path handling.

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, front-loaded sentence with no filler. Every listed item—sheets, symbol counts, nets, power nets, DNP parts—adds meaningful 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?

For a read-only summary tool with an output schema, the description is largely sufficient: it names the input source and the summarized content. The only minor gap is the lack of explicit guidance about the optional path parameter, but the output schema likely fills in the return structure.

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 has a single optional 'path' parameter with 0% description coverage. The phrase 'from the exported netlist' gives some hint that path likely points to an exported netlist, but it does not explain accepted formats, file vs directory, or what happens when path is null.

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 behavior: generating a schematic overview from an exported netlist, and enumerates the concrete contents (sheets, symbol counts, nets, power nets, DNP parts). This clearly distinguishes it from sibling tools like board_summary or project_info.

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 the tool should be used when a schematic-level overview derived from an exported netlist is needed. However, it does not explicitly state when not to use it or how it compares to alternatives such as board_summary or project_info.

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?

Annotations already declare the tool read-only and idempotent, so the safety profile is covered. The description adds useful behavioral detail about exact, case-insensitive, and unique-substring name matching, but it does not disclose what happens on no match or how the optional path affects the lookup.

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 compact sentence with no filler. Every phrase adds value, especially the parenthetical matching modes, though it is slightly under-specified rather than optimally 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 simple read-only tool with an output schema, the description is largely adequate for basic invocation with the net parameter. However, the optional path parameter is undocumented, and there is no guidance about multi-sheet or no-match scenarios, leaving meaningful gaps for correct advanced use.

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 carry parameter meaning. The 'net' parameter is reasonably inferable from the tool name and the matching-mode note, but the 'path' parameter is entirely unexplained, including whether it is a file path, sheet path, or something else.

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 identifies the resource (a schematic net) and the result scope (all pins on it), which is specific enough to distinguish it from sibling tools like sch_nets or list_nets. It lacks an explicit verb like 'returns' or 'lists', but the intent is unambiguous. The matching modes further clarify what kind of net-name lookup is supported.

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 no guidance on when to use this tool versus similar siblings such as net_info, sch_nets, or search. It implies the net-pin lookup use case but never states alternatives, exclusions, or preconditions.

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?

Annotations already declare readOnlyHint and idempotentHint, so the description does not need to restate that this is safe and repeatable. It adds behavioral context beyond the annotations: results are ordered by pin count descending, and the filter performs case-insensitive substring matching. There is no contradiction with the 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 very concise: two short sentences with no filler. The main resource and ordering are front-loaded, and the filter nuance follows. It earns its place, though it is slightly under-specified in ways that affect other dimensions.

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?

Given that an output schema exists and annotations cover safety, the description conveys the core behavior needed to invoke the tool: list schematic nets sorted by pin count, optionally filtered. However, it omits any explanation of the 'path' parameter and lacks guidance on when to prefer this over similar sibling tools, so it is not fully complete.

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 provides no per-parameter descriptions (0% schema coverage), so the description must compensate. It meaningfully explains the 'filter' parameter as a case-insensitive substring, but it does not explain 'path' or 'limit'. 'limit' is somewhat inferable from its default, but 'path' is ambiguous, leaving a significant 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 identifies the resource (schematic nets) and the key attribute (pin counts), and states the ordering (largest first). It is not a tautology and gives a concrete sense of what the tool returns. However, it does not explicitly say 'list' or 'get' and does not distinguish it from sibling tools like list_nets, sch_net, or net_info.

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?

There is no guidance on when to use this tool versus the many related sibling tools such as list_nets, sch_net, or net_info. The only usage hint is the filter parameter behavior, which is a parameter detail rather than a selection criterion. An agent must infer when this tool is the right choice.

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?

Annotations declare readOnlyHint and idempotentHint, which the description does not contradict. The description adds the scope ('on the board') and the list of searchable fields, which is useful. However, it doesn't disclose return format, pagination, or any limitations beyond what the output schema might convey, so the added value beyond annotations is modest.

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, efficient sentence that front-loads the purpose and lists the search targets without any fluff. Every word contributes to understanding, making it highly 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?

While the core action is clear and read-only behavior is covered by annotations, the tool has three parameters that are entirely undocumented in the description. Without guidance on 'path' and 'limit', an agent may call the tool incorrectly or misunderstand its capabilities. The output schema exists, but parameter semantics remain a significant gap, making the description incomplete for confident usage.

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%. The description only implies that 'query' is the search string (since it talks about a string), but it provides no explanation for 'path' or 'limit'. The agent has no idea what 'path' means (likely a filter scope) or what 'limit' controls (likely result count), and the description fails to compensate for the lack of schema documentation.

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 action ('Find where a string occurs') and resource ('on the board'), and enumerates the specific search targets (references, values, footprint names, fields, net names, silkscreen text). It distinguishes from siblings like net_info or list_components by covering multiple field types, but doesn't explicitly name an alternative tool, so it's not a 5.

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?

No guidance is given on when to use this search tool versus more specific siblings like net_info or list_components. The description doesn't mention any exclusions, preferred use cases, or conditions under which another tool would be better, leaving the agent to infer usage.

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?

Annotations already declare readOnlyHint=false and destructiveHint=true, so nothing is contradicted (no annotation contradiction). The description adds meaningful behavioral context — that add=true preserves the existing selection and that the tool changes visible selection state — but it does not disclose what happens to the previous selection when add=false (implied replacement only).

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 tightly written sentences with the purpose front-loaded before parameter details. Zero filler; every clause 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 3-parameter tool with an output schema, the purpose and two of three parameters are covered. The path parameter is undocumented in both schema and description, making the definition nearly-but-not-fully complete for correct invocation.

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?

With schema description coverage at 0%, the description must compensate. It documents refs ('JSON list of references') and add ('keeps the existing selection'), but path is left entirely unexplained with no schema description to fall back on, leaving a real gap for the agent.

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 (select), resource (footprints in the PCB editor), and the intent behind it ('so the user can see which ones you mean'). This is unambiguous about what the tool does and lets it be distinguished from the read-oriented sibling get_selection.

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 phrase 'so the user can see which ones you mean' gives implied context for when to use the tool, but there is no explicit when-to-use/when-not-to-use guidance and no named alternative such as get_selection. Usage context is present but inferred rather than stated.

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?

Annotations already indicate destructiveHint=true and readOnlyHint=false, but the description adds no behavioral context beyond that. It does not mention that this modifies the PCB, that changes may affect BOM/position output, or that the locked flag has implications for future edits.

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 with no filler. The key action and target are front-loaded, and every word contributes to understanding the tool's purpose.

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 mutation tool with six parameters, no required parameters, and zero schema descriptions, this description is too thin. It lacks guidance on how to identify the footprint via ref/path, what happens when flags are set, and when this tool should be preferred over alternatives. The output schema exists but does not compensate for these 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. It does add meaning for four of the six parameters by explaining dnp, exclude_from_bom, exclude_from_pos, and locked as flags. However, it omits ref and path, which are critical for identifying which footprint to modify, and does not explain how these selectors work.

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 uses a specific verb ('Set') and resource ('flags on a footprint'), and lists the exact flags: DNP, exclude-from-BOM, exclude-from-position-files, and locked. This clearly differentiates it from sibling tools like set_component_field, which would handle arbitrary field values.

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?

No guidance is given about when to use this tool versus alternatives, such as set_component_field or move_component. The description only states what the tool does, leaving the agent to infer appropriate use cases.

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?

The annotations already convey mutation via readOnlyHint=false and destructive potential via destructiveHint=true. The description adds the scope distinction that this edits board footprints, not schematic items, but it does not explain persistence, undo/save implications, or failure behavior. Given the annotations already cover the main hazard, this is acceptable but not rich.

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 concise sentence that front-loads the action and scope. Every word adds information, and there is 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 destructive mutation tool with four parameters and zero schema descriptions, this description is too thin. It does not explain how ref/path identify the component, what values are acceptable, or what the destructive edit implies. The presence of an output schema helps with return values, but the invocation ambiguity remains significant.

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 clarify that 'field' can be value, datasheet, or description text, but it leaves ref, path, and value semantics unexplained, and gives no guidance on how to target a specific footprint or how the optional parameters interact.

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 uses a specific verb 'Set' and names concrete targets: value, datasheet, or description text of a footprint. It also explicitly scopes the tool to the board rather than the schematic, which helps distinguish it from schematic-focused siblings. It does not differentiate it from the nearby set_component_attributes tool, so it stops short of a 5.

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 parenthetical '(not the schematic)' provides an explicit boundary, implying this is for board footprint fields rather than schematic components. However, it does not name alternatives or state conditions for when to choose this tool over siblings like set_component_attributes or get_component.

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