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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, covering the safety profile. The description adds the domain-relevant detail that the hole is non-plated, which is useful context, but says nothing about whether the change is undoable or what it 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?

A single front-loaded sentence with no filler; the key distinction (non-plated) appears immediately after the verb and resource.

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 three-required-parameter creation tool with no output schema and only safety annotations, the description is minimally adequate. It omits coordinate reference frame, drill units/constraints, and whether the hole can be removed later.

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 the three undocumented parameters, but it says nothing about x_mm, y_mm or drill_mm. Only the parameter names themselves hint at coordinates and drill diameter in millimeters.

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 gives a specific verb and resource ('Add a non-plated hole on the board') and clarifies the NPTH nature versus plated features like add_via. It does not explicitly name the sibling it contrasts with, but the 'non-plated' qualifier makes the distinction inferable.

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 '(e.g. a mounting hole)' implies a use case, but there is no explicit when-to-use guidance or a named alternative such as add_via for plated holes. Usage must be inferred from the NPTH qualifier.

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 only declare the generic safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the description carries the real behavioral burden. It does so well by stating the downstream effects ('Pours and the autorouter respect it') and the underlying representation ('EAGLE restrict layers 41/42/43'). It does not say whether the design must be open or whether the change needs save_design to persist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three compact sentences with zero filler, front-loaded with the core purpose followed by the semantic effect and the implementation detail. Every sentence contributes 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?

With no output schema, the description correctly avoids return-value discussion and instead covers what the keepout does and which layers it maps to. Missing only minor operational context (open-design precondition, units, persistence), which for a simple additive geometry tool is a small 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 must compensate for all four parameters. It partly does: 'Circular' explains radius_mm, and the quoted 'top'/'bottom'/'vias' values clarify the layers array and its meaning. x_mm and y_mm are never addressed (presumably the circle center), so the compensation is incomplete.

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+resource: it adds a circular keepout and defines what that means (no copper on 'top'/'bottom', no vias inside). That is far more than a restatement of the name. It does not explicitly name a sibling it differs from (e.g. add_hole, add_pour, rip_up), so it stops short of the top mark.

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 context is implied by the parenthetical example 'e.g. around a mounting hole', which tells the agent a typical scenario. There is no explicit when-to-use vs. when-to-use-something-else guidance, and no mention of alternatives such as add_hole or add_pour, so it remains 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?

Annotations already declare the mutation profile (readOnly=false, idempotent=false, destructive=false). The description adds real value beyond them: it discloses the forward-annotation side effect onto the board and the sheet-creation behavior (existing sheet or sheets + 1), which the agent can't get from 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?

Two sentences, front-loaded with the core action and example, with the sheet behavior appended. Minimal waste, though the parenthetical example is dense and the phrasing could be tighter.

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 mutating, 7-parameter tool with no output schema, the description covers the key behaviors (forward annotation, sheet creation) but leaves most parameters unexplained and doesn't mention prerequisites, so an agent is not fully equipped.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description carries the full burden, yet it only clarifies 'device' (device set + variant with an example) and 'sheet'. The required ref, x_mm, y_mm and the optional angle and library_name are left entirely undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ("Place") and resource (a device from a Fusion library into the schematic), and even gives a concrete device example. It does not explicitly differentiate from the closely-related sibling insert_library_part, so it falls 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?

Usage is implied by the context (placing parts into a schematic), but there is no explicit when-to-use, prerequisite (e.g., a library must be open or device found first), or guidance distinguishing it from siblings like insert_library_part. The agent must infer the workflow.

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 state readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds substantial behavioral detail beyond that: the pour is filled immediately, it respects keepouts, rank controls cut-out priority, thermals come from design rules, and outline width centering affects effective inset.

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 paragraph is front-loaded with the core action and remains information-dense rather than repetitive. It is long for a single description but each clause adds technical meaning for a complex PCB tool.

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 creation tool with no output schema, the description covers most behavior, defaults, and interactions with keepouts and design rules. Minor gaps remain around the layer parameter and points_mm format, but the overall context is strong.

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 parameter burden. It explains net, rank, inset_mm, width_mm, points_mm, isolate_mm, and thermal_width_mm meanings well, but layer is only implied and not explicitly defined with its default or accepted values.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a precise verb and resource: 'Add a copper pour (polygon) on a net.' It distinguishes the action from sibling tools like list_pours and set_pour_thermals by specifying creation and immediate fill, so an agent can select it without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear contextual guidance: omit points to follow the board outline, use inset_mm for edge clearance, rank for overlap priority, and it respects keepouts. It does not explicitly name when to use this versus alternatives such as set_pour_thermals, so it stops short of the top score.

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 non-read-only, non-destructive, non-idempotent. Beyond those, the description discloses non-obvious behavior: bottom-layer mirroring, fabs clipping silk over exposed copper, and JLC manufacturing minimums baked into defaults. This is genuine added transparency and consistent 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?

Dense single paragraph, front-loaded with purpose, and most sentences carry unique information. It leans on jargon (fabs, JLC) and could be broken into structured lines, but there is little waste.

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 mutation tool with no output schema, the description covers the key inputs, layer semantics, manufacturing constraints, and clipping behavior. It does not address return values or error cases, but the practical guidance is otherwise sufficient to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description carries the burden and does so well for the non-obvious params: layer accepted values, size_mm as character height, ratio_pct as stroke percentage, and align options. It omits angle/x/y, but those are largely self-evident from their names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Add board text') with an illustrative use case ('silkscreen pin labels'). It is the only text-adding tool among the siblings, and the description makes its domain unambiguous without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (silk labels, docs) and adds a practical constraint ('Keep text off pads: fabs clip silk over exposed copper'), but never states when to use this vs alternatives or any prerequisites. Context is present, explicit routing is not.

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 this is a non-readOnly, non-idempotent write (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the safety profile is covered. The description adds no behavioral context beyond that: it does not state whether an open design is required, what happens on layer/geometry conflicts, or whether the operation is reversible.

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 the action front-loaded and the syntax details trailing. Every clause carries information; no 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?

For a 4-required-parameter write tool with no output schema, the core geometry and layer inputs are covered. Missing context on prerequisites (open design), return behavior, and how it relates to the other routing siblings leaves it merely 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 does document the two non-obvious parameters well: points_mm as [[x, y], ...] in mm and layer as 'top'/'bottom'/'inner1'.. or a number. It adds nothing for net or width_mm, which are partly self-describing by name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Route a trace through the given points'. The agent understands the action clearly. However, it does not differentiate itself from close siblings like route_trace, route_net, or route_pair, which are also present in the tool list.

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 when-to-use or when-not-to-use guidance is given, and no alternative is named. With siblings such as route_trace and route_pair available, the description leaves the agent to infer which routing tool applies in which situation.

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 disclose readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the write/non-idempotent nature is covered. The description adds one useful behavioral detail — the pad diameter is derived from the design's restring rules rather than user-specified — but says nothing about what happens if a via already exists at that location or what the drill default implies.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two compact sentences with the action front-loaded and the pad-diameter caveat second. No wasted words, though the second sentence could be slightly more informative for the space it occupies.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and 0% schema coverage, the description should do more: it omits the drill parameter entirely and does not state units for drill or what the call returns. For a 4-parameter mutation tool, this leaves meaningful 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 carries full burden. It gives meaning to net and to x/y (mm), which is real value, but drill_mm is never mentioned — its units, default of 0.3, and relationship to the restring-derived pad diameter are left undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Add a through via on a net at (x, y) mm'), which is clearly distinct from sibling placement tools like add_part or add_hole. However it does not differentiate itself from the other via-related siblings (stitch_vias, ground_vias, fanout_pad), leaving the agent to infer which via tool to pick.

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 versus stitch_vias, ground_vias, or fanout_pad, nor any prerequisite or context (e.g. during routing vs cleanup). Usage must be inferred entirely from the name.

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 only cover the basic safety profile (readOnly=false, destructive=false, idempotent=false), and the description adds substantial context beyond them: the board-standing validation that aborts the call with nothing saved, the versioned filename behavior when a model already exists, and the fact that boards keep their old model until refreshed. These are real behavioral traits an agent cannot get from the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three paragraphs, front-loaded with the core action and followed by validation, naming, and propagation detail. Dense and mostly earning its place, though the KiCad-vs-Fusion rotation aside is a mild digression.

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 7-parameter mutation with no output schema and thin annotations, the description covers failure modes, filename versioning, and the downstream refresh chain. The only gap is the undocumented `name` parameter and no hint of the return payload.

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 full burden and explains offset_mm as [x,y,z], rotation_deg as [rx,ry,rz], allow_below_board's semantics, and folder's default role. It leaves `name` unexplained and only implicitly covers `package`/`step_path`, so it compensates well but not completely.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Give a package in the OPEN library a 3D model from a STEP file') and pins the scope to the OPEN library, distinguishing it from siblings like push_3d and check_3d_models. An agent can tell immediately what it does and where the artifact lands.

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?

Gives concrete conditional guidance: pass offset_mm/rotation_deg when a model's origin differs, allow_below_board=true for through-board parts, and fix rotation_deg for Y-up vendor STEPs. It also names the follow-up workflow (save_design, update_from_libraries, push_3d) rather than leaving it to inference, though it never explicitly says when to prefer a sibling such as check_3d_models.

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 annotations only covering the generic safe-mutation flags, the description carries the behavioral burden and does so richly: it explains the `route_past_planes` Fusion prompt semantics (Yes keeps signals off the plane, the pour refills around new vias), the TopRouter hang risk and its temporary override with restoration of design settings, and that metrics are returned before and after.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action and scope, then adds parameter-specific notes as parenthetical asides. Dense but each sentence earns its place; the nested asides about TopRouter and planes make it slightly harder to scan than an ideal layout.

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?

No output schema exists, and the description does state that routing metrics are returned before and after, plus the interaction with pours and the autorouter settings. The only gap is the undocumented `timeout_s` and no default value disclosure for parameters, which the schema does provide.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate, and it explains `nets`, `engine`, `top_router`, and `route_past_planes` semantics in real depth (e.g. engine='fusion' applies the best variant by completeness then fewest vias). It omits `timeout_s` entirely, leaving one of five parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Route unrouted connections with an autorouter, keeping existing traces') and immediately distinguishes itself from manual routing siblings by noting it preserves existing traces and that without `nets` it 'routes everything left.' An agent can tell this apart from route_net, route_trace, and route_remaining without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear operational context: route critical nets, power, and pours before invoking, and the default scope when `nets` is omitted. It does not explicitly name a sibling alternative (e.g. route_remaining or route_trace) for the 'route everything left' case, so routing between tools is 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 declare this is a safe, idempotent, non-destructive read, so the safety profile is covered. The description adds real behavioral value by stating what is compared (part height ranges vs the board) and what is reported (a list of parts whose model sits on the wrong side, with the top/bottom reversal spelled out). It doesn't state prerequisites such as needing models attached or an open design.

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 zero filler: the scope ('the open 3D PCB') and the check come first, and the parenthetical clarifies the failure case concretely. Nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no parameters, no output schema, and annotations covering the safety profile, the description carries most of the remaining burden and does it well by explaining the comparison and the reported result. The one gap is prerequisites (an open design with attached 3D models), which an agent might need to know before calling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. The description correctly implies the operation acts on the already-open board rather than taking a design identifier.

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 gives a specific verb ('Check') and resource ('the open 3D PCB'), then narrows the check to part height ranges versus the board and parts whose model sits on the wrong side. That is far more specific than a generic 'validate 3D' tool. It stops short of naming a sibling (e.g. check_jlc_orientation or attach_3d_model), so differentiation is inferential 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?

Usage is implied: you run this on the currently open 3D PCB to catch mirrored/wrong-side models. There is no explicit when-to-use framing, no prerequisites (design open, 3D models attached), and no contrast with the neighboring checks like check_jlc_orientation or run_drc.

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 readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds real operational depth beyond that by enumerating what is validated (layer set, outline size, every drilled hole's diameter/position, pad flash counts), which tells the agent the scope of the check.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the verb and resource, then a dense parenthetical enumerating the checks. It is long but nearly every clause adds a distinct validation dimension; only the long inline list borders on overloading a single sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter tool with no output schema, the description covers purpose, scope of checks, and when to run it. It does not describe the return format (pass/fail vs. issue list) or failure behavior, which is the main remaining gap since no output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry the parameter. It does meaningful work by clarifying that the single path parameter points to a 'zip or folder of gerbers + Excellon drills' rather than, say, a design file — compensating for the undocumented 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?

States a specific verb (check) and resource (CAM output zip/folder of gerbers + Excellon drills) against the open design. It is clearly distinguishable from the design-side checks like run_drc, run_erc, and check_jlc_orientation because it explicitly verifies a manufactured CAM artifact, not the live design.

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?

Gives a concrete when-to-use instruction: 'Run it on the zip before uploading to the fab.' It frames the workflow trigger well, but names no alternatives and no when-not-to-use case, so it stops short of a full routing guide.

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 cover safety (readOnly, idempotent, non-destructive). The description adds genuinely new behavioral context: the estimation method (IPC-2141 closed form), its accuracy envelope (~10% vs a field solver), and a secondary side effect of flagging P-N gap versus copper clearance rules. Good added value beyond structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action, then adds the flagging behavior and the accuracy caveat in two tight sentences. Dense but every clause carries information; no 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?

With no output schema, the description adequately explains what the tool returns (per-pair impedance estimates, comparison to target, clearance-gap flags) and how reliable they are. The main omission is disambiguation from the sibling 'estimate_impedance' and parameter-level detail.

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. It hints at the stackup input ('using the real stackup') and the comparison target ('compare with the target'), but never names or explains 'tolerance_pct' and gives no formats or defaults, so the compensation is only partial.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource with scope: estimates every differential pair's impedance on its routed layer against the target, plus flags clearance-rule violations. Clear and detailed, but it never distinguishes itself from the sibling 'estimate_impedance', which an agent could easily confuse it with.

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?

Gives useful context about when the result is trustworthy ('use a solver or the fab's calculator for sign-off') and implies it runs against routed geometry, but offers no explicit when-to-use versus the near-identical sibling 'estimate_impedance', nor prerequisites like needing a routed design.

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?

Adds substantial behavior beyond the annotations: name-based pad matching with a geometry fallback, ambiguous matches flagged for human polarity confirmation, pin-function matching (K/A, FB/EN), permanent caching, and a 15 s inter-request throttle. One tension is that annotations declare openWorldHint=false while the description states fetch=true reaches easyeda.com over the internet; the fetch is bounded and cached, so it reads as a nuance rather than a hard contradiction.

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 core purpose is front-loaded in the first clause, and every later detail (matching strategy, ambiguity handling, caching, throttling) is informative rather than filler. It is dense and reads as a single sprawling sentence with nested parentheticals, which slightly hurts scanability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description conveys that the result is a derived rotation/offset plus ambiguity flags, which is the key return concept. It covers the matching logic and network constraints adequately; only the `refs` scoping and the exact report shape remain implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter meaning. It documents `fetch` thoroughly (downloads missing footprints, cache behavior, rate limit), but never explains what `refs` does (default null implies all parts, but this is left to inference), so the compensation is only partial.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: comparing each placed part's footprint against the JLCPCB-assigned footprint and deriving the CPL rotation/offset to align them. This is unambiguous and clearly separable from siblings like export_cpl or update_from_libraries.

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 explains the two operating modes (fetch=true downloads missing footprints; otherwise local cache only) and the 15 s rate limit, which is useful conditional context. However, it never states when an agent should run this relative to alternatives such as export_cpl, run_drc, or update_from_libraries, so the routing guidance is only implied.

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, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, repeatable read. The description adds that lengths are compared 'against the longest', which clarifies the reference point, but says nothing about the tolerance behavior or output.

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 well-formed sentence with the core action front-loaded and no filler. It is efficient, though the terse phrasing leaves semantic gaps that a second sentence could have closed.

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?

No output schema exists, so the description should explain what a check returns (boolean, list of mismatches, measured deltas), but it does not. Combined with 0% parameter coverage, an agent cannot reliably predict inputs or outputs.

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 both parameters. It implies 'nets' is the group being compared but never explains 'tolerance_mm' at all — a critical parameter whose semantics (allowed deviation from the longest) are left entirely undefined.

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 (compare) and resource (routed lengths of a group of nets) with a clarifying example (bus or lanes). An agent can tell what it does without opening the schema, though it doesn't explicitly differentiate itself from potential siblings like check_impedance.

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 'e.g. a bus or lanes' implies the length-matching use case, which is genuine context. However, there is no explicit when-to-use/when-not guidance and no named alternative, so usage must be inferred.

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 carry destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description goes beyond them by specifying exactly what is destroyed (only vias now violating clearance, to any net's pad or other copper) and by prescribing a recovery step, which is genuinely useful mutation context. It stops short of noting whether results are reported back.

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 with no filler; the deletion scope is front-loaded and the follow-up instruction trails it naturally. 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 destructive single-parameter tool whose annotations already disclose the safety profile, the description covers what it does, why the vias qualify, and what to run next. Return value / count reporting is unspecified, but with no output schema that is a minor omission.

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 single 'net' parameter (default 'GND') is documented only by its name. The description implies the operation is scoped to one net's vias, which adds some meaning, but never clarifies that 'net' selects the target net or that it defaults to GND. Baseline-to-slightly-better.

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 (Delete) and a precisely scoped resource (a net's vias that violate clearance to a pad of any net or another net's copper). The conditional qualifier distinguishes it from blanket removal tools like rip_up and from additive siblings like stitch_vias/add_via.

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?

Gives a concrete triggering scenario ('stitching vias left under a part that moved') and an explicit follow-up action ('Run stitch_vias again afterwards to refill'), effectively naming the alternative tool and the sequence in which to use it. Nothing about when to reach for this tool is left to inference.

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 flag destructiveHint=true and readOnlyHint=false, and the description adds real context beyond them: the specific failure mode (refusal on unsaved changes) and the escape hatch (discard_changes). It still doesn't say what happens to the design state afterward or whether the handle becomes invalid.

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, zero waste, with the primary action front-loaded and the conditional failure behavior immediately after. Nothing is padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter close operation with no output schema, the description covers the essential risk (data loss on unsaved changes) and the controlling flag. Only the identity of the 'name' parameter and post-close state are left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the burden. It explains discard_changes well as both a value and an interaction (only needed when there are unsaved changes), but the required 'name' parameter is given no semantic meaning at all in either place.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Close a design') that an agent can act on immediately. It does not, however, differentiate itself from the sibling close_library, nor clarify the design-vs-library scope distinction present in the tool set.

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 unsaved-changes refusal gives a clear precondition for when the call will fail, which implies usage context (use when finished with a design, after saving). But no explicit alternative is named — save_design and undo exist as siblings and aren't referenced.

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, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds the useful rationale that closing frees parts for placement, but it does not say what is lost on close (unsaved edits) or whether the change is reversible.

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 tight sentence with the action front-loaded and the purpose trailing. No waste, though the parenthetical '(saved)' slightly muddies rather than clarifies.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter close operation whose annotations already carry the destructive/idempotent profile, the description is adequate but thin: it leaves the parameter meaning and the fate of unsaved work 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?

There is one parameter ('name') with 0% schema description coverage, so the schema provides no semantics. The description never says whether 'name' is the library document name, a part name, or a path, leaving 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?

States a specific verb (close) and resource (an open/saved library document), and adds the consequence 'so its parts can be placed'. It is clearly separable from close_design and from open_library, though it never names those siblings explicitly.

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 only implied by the trailing clause about placing parts; there is no explicit statement of when to call this versus open_library/close_design, nor any precondition (e.g. whether the library must be currently open).

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 only give generic hints (non-readOnly, non-destructive, non-idempotent, non-openWorld), so the description adds real value: it discloses the geometry produced (a short named wire stub per pin, no wire crossing other parts), the labeling behavior, and a hard guard against merging existing nets. It does not describe the return value or error surface.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tightly-packed sentences, front-loaded with the core action followed by the pin format and behavioral guarantees. Dense but every clause carries information; no padding.

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 4-param write tool with no output schema and only generic annotations, the description covers action, format, side effects, and one safety constraint. It would be stronger with a note on prerequisites (open design/sheet) and failure modes, but it is largely 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?

With 0% schema description coverage, the description compensates well: it documents the pins string format (PART.PIN or PART.PAD), the effect of labels=false (omit net labels), and the effect of allow_merge=true. It adds little for 'net' beyond the name, but covers the ambiguous 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?

States a specific verb+resource: 'Connect schematic pins into a named net.' The word 'schematic' plus 'pins' clearly distinguishes it from PCB-routing siblings like route_net and add_trace, and from net-management siblings like rename_net and label_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 implies usage (connecting pins at the schematic level) and gives one operative constraint (refuses to merge nets unless allow_merge=true), but never states when to prefer this tool over siblings or what prerequisites exist. Usage is inferable rather than 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=false, so the mutation/non-destructive profile is known. The description adds real behavior (symbols are auto-generated, JLCPCB/MF/MP fields are auto-filled from cached EasyEDA data), but it does not disclose overwrite semantics, collision handling, or failure modes, which matters for a non-idempotent create with an overwrite flag.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose and dense with useful detail; almost every clause carries information (input formats, symbol rules, param mappings, next steps). It is a single long block that could be broken up, but there is little waste.

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 13-parameter, 5-required tool with 0% schema coverage and no output schema, the description covers purpose, workflow, and the tricky params but omits meaning for required params like part_id, deviceset, prefix, and value, leaving the agent to guess their format. Adequate but with a real gap given the complexity.

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 coverage the description carries the full burden and does well on the hard params: it explains jlc_native, jlc_code (C-number -> JLCPCB), pin_names (pad -> pin name mapping, shared names join a pin), directions (pin name -> in/out/io/pwr/pas/oc), and MF/MP sourcing. It leaves several params (part_id, deviceset, prefix, value, description, overwrite) undefined, so it falls short of full coverage.

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+resource ("Create a part in this server's component library from a KiCad footprint") and clarifies the exact input format (.kicad_mod from KiCad libs or JLCPCB). It situates itself in the workflow by naming the downstream siblings insert_library_part, save_design, and attach_3d_model, so an agent can tell it apart from add_part and insert_library_part.

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?

Provides clear when-to-use context: use easyeda2kicad --full exports with jlc_native=true, and it prescribes the follow-up sequence (open Fusion library, run insert_library_part, save_design, attach_3d_model). It does not explicitly state when NOT to use it or name a competing alternative for library creation.

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 readOnly/idempotent/non-destructive, so the safety bar is low; the description adds the underlying model (IPC-2141 closed-form) and clarifies that dielectric_mm changes meaning by geometry (height-to-plane for microstrip, plane-to-plane for stripline). It does not discuss accuracy limits or tolerance vs. a field solver.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short, front-loaded statements with no filler: what it computes, the geometry-dependent meaning of the key input, and the two alternative tools. 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?

For a 6-parameter computational tool with no output schema and 0% schema coverage, the description should also say what comes back (e.g. impedance in ohms) and cover gap_mm (likely differential-pair spacing). It handles the core geometry case well but leaves the return value and part of the parameter set implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry parameter meaning. It does explain dielectric_mm per geometry and names the microstrip/stripline values for geometry, but width_mm, copper_mm, gap_mm, and er are left unexplained, so the compensation is only partial.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('closed-form (IPC-2141) impedance estimate for a hypothetical trace') and explicitly scopes it as what-if rather than measurement. It also names the two overlapping siblings (get_layer_stack, check_impedance) so the agent can separate this tool from them without reading any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It routes the agent away from this tool by naming alternatives: get_layer_stack for real stack-up thicknesses/Er and check_impedance for every routed pair. The condition selecting this tool ('hypothetical trace') is implied rather than spelled out, but the sibling differentiation is clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and closed-world, so the safety profile is covered. The description adds real value by disclosing that two CSVs are produced (the BOM plus an excluded-parts CSV) and that the source is the currently open board, but it omits where files are written and whether an open board is strictly required.

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 compact clause with no filler; the format and the secondary output are front-loaded. It is terse to the point of being a fragment, but every word carries 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 zero-parameter, no-output-schema export tool with full annotation coverage, the description supplies the essential facts: the output format, the secondary excluded-parts file, and the dependency on the open board. Only output destination details are missing, which is minor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline is 4 and there is no parameter semantics for the description to compensate for.

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 the concrete artifact (JLCPCB-format BOM CSV) and the source (the open board), so an agent can distinguish it from export_cpl and the other export/report tools. It reads as a noun phrase rather than a verb+resource statement, and it never names the sibling it is not, but the resource and format are 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?

There is no explicit when-to-use guidance, no prerequisite statement beyond the implicit 'open board', and no mention of how it relates to export_cpl or check_jlc_orientation, which an agent would likely need to choose between when preparing a JLCPCB order.

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 readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description still adds real value beyond them: it explicitly states the tool never touches the network and explains the rotation/offset derivation and the library JLC-ROTATION/JLC-X-OFFSET/JLC-Y-OFFSET override precedence, plus that ambiguous derivations are surfaced for review.

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?

It is dense and technical but front-loads the artifact identity before the orientation mechanics, and each sentence adds information about behavior rather than restating the name. Slightly compressed for one paragraph, but nothing reads as 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?

With no output schema, the description still conveys what the agent gets back (a CPL CSV, plus a review list when derivations are ambiguous) and what precondition matters (cache populated via check_jlc_orientation). It stops short of naming the output location or column layout, but it is complete enough to call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry the single parameter's meaning, and it does: it explains what jlc_orientation does (apply derived rotation/offset when footprint data is cached), the precedence of library attributes, and the fallback of listing ambiguous cases for review. It only omits the explicit true/false semantics and the default value.

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 specific artifact produced (a JLCPCB-format pick-and-place/CPL CSV) and explains the placement convention behind it, which distinguishes it from sibling export_bom. It is phrased as a noun phrase rather than a leading verb, relying on the tool name for the action, but the resource and scope are 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?

It gives operational context for the jlc_orientation path and points to check_jlc_orientation(fetch=true) to prime the cache, which is genuinely useful. However, it never states when an agent should call this versus export_bom or get_assembly_quote, so the routing among siblings is only implied.

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 a non-read-only, non-destructive, non-idempotent mutation. The description adds genuine behavioral context beyond them: the automatic geometric constraints it must satisfy and the hard 'never via-in-pad' rule, which tells the agent what the tool will and won't do. It omits failure behavior (e.g. what happens if no valid spot exists) and any undo/permission guidance.

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, front-loaded with the core action and then the use cases, with no filler. The parenthetical constraint list is dense but every item is meaningful, so it stays readable without 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 mutation tool with annotations present and no output schema, the description covers what it does and when to use it, but with 0% schema coverage on five parameters it leaves key invocation details (layer, distance, width, what ref/pad strings look like) undocumented, and does not say how it behaves when no valid via spot is found.

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% across five parameters, so the description carries the full burden of explaining them. It mentions only the pad implicitly; ref, layer, max_dist_mm, trace_width_mm, and the search bound implied by 'nearest' are never explained, so the agent cannot reason about default 3mm distance or trace width from the text.

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 operation on a specific resource: place a fanout via plus a short trace from a single pad to the nearest valid via spot. The clearance constraints ('clear of other nets, every pad, holes, keepouts and the edge; never via-in-pad') make it clearly distinct from manual siblings like add_via or stitch_vias, though those siblings are never named.

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 explicit when-to-use cases ('connect a GND pad that routing cut off from its pour, or power-pin fanout before autorouting'), which gives an agent real context for choosing this over add_via. It stops short of stating when NOT to use it or naming the sibling alternatives, so it falls below the 5 tier.

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 readOnly, idempotent, non-destructive and non-open-world, so the safety profile is covered. The description adds genuine context beyond that: the tool is not connected and performs no network calls, warning the agent that results are stubbed. It stops short of describing the return shape or what the stub data looks like.

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 efficient sentence with no filler, front-loading the tool's purpose. The most consequential detail — that it makes no network calls — is relegated to a trailing parenthetical, which slightly buries the caveat.

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 one-parameter tool with no output schema, the description covers purpose and the stub caveat, but omits what the quote actually returns and what 'quantity' affects. An agent knows the tool exists but not how to interpret or trust its output.

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 single 'quantity' parameter at all, so it does not compensate for the schema gap. The parameter's default and meaning must be inferred from its title alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Get a PCB assembly quote'), which is unambiguous and distinguishable from every sibling tool since none other produces a quote. No explicit sibling differentiation is needed because no competing tool exists, but the purpose itself is 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 parenthetical caveat ('not connected yet: makes no network calls') implicitly signals when the tool is usable — i.e., it returns stub data rather than a real quote. However, it gives no explicit when-to-use or when-not-to-use guidance relative to alternatives like export_bom or check_jlc_orientation.

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, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered. The description adds content scope, but no output schema exists and phrases like 'design-rule highlights' leave the actual return contract ambiguous.

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 compact line with zero filler, listing the summary contents up front. The verbless fragment style is slightly terse but wastes nothing.

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 zero-parameter, read-only overview tool with no output schema, the description carries the return-value burden and does list the main contents. It is nearly complete, with only the vagueness of 'design-rule highlights' and the missing usage context as 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?

The tool takes zero parameters, which is the baseline-4 case. There is nothing to disambiguate, and the schema correctly reflects an empty argument object.

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 enumerates exactly what the tool returns - board size, copper layers, part/net counts, net classes, design-rule highlights - which is a specific, recognizable resource for a summary getter and distinguishes it from narrower siblings like get_layer_stack or list_nets. It omits an explicit verb and never names a sibling, so it falls 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?

There is no statement of when to use this aggregate summary versus drilling into list_nets, list_parts, get_layer_stack, or run_drc. Usage is only weakly implied by the aggregation of other tools' outputs; no conditions or alternatives are given.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description's contribution is only the subject matter of the query (open documents, active editor); it says nothing about return shape, freshness, or cost. With annotations carrying the behavioral burden, a baseline 3 is warranted.

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 short sentence with no filler, and the key noun phrase (which documents) is front-loaded. It is a sentence fragment rather than a full statement of action, which costs a point against perfect concision-and-clarity, but there is no waste.

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 zero-parameter, read-only state getter with full annotation coverage and no output schema, the description is close to sufficient but omits any indication of when the returned context matters or what the agent can do with it. It is adequate but leaves a clear gap given the many editing siblings that would consume this context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. No parameter guidance is required or missing.

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 specific information returned: which Electronics documents are open in Fusion and which editor is active. That is more concrete than the generic name 'get_context' and lets an agent distinguish it from document-manipulation siblings like open_design or close_design. It does not, however, explicitly contrast itself with any sibling tool.

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 statement of when to call this tool, when not to, or what alternative exists. The agent must infer that this is a state-inspection call needed before deciding what to open or edit. No prerequisites or follow-up guidance are given.

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 cover the safety profile (readOnlyHint, idempotentHint, non-destructive). The description adds useful behavioral context: it reads from Fusion's own V2 rules and emits a warning when defaults are still in use, including an example (40 mil edge clearance). It does not cover return format or error behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tightly written sentences that front-load the tool's purpose and then add the warning behavior. 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?

Given the tool is read-only, parameterless, and has no output schema, the description is mostly complete: it explains what rules are returned and the warning condition. It could be more complete by clarifying the return shape or how it relates to list_design_rules.

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 zero parameters, there are no parameter semantics to clarify, so the baseline of 4 applies. The description appropriately adds no parameter details because none exist.

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+resource: read key design rules of the open board, with example rule types (clearances, minimum width/drill, edge clearance, via restring). It is clear what the tool does, but it does not explicitly differentiate itself from the sibling list_design_rules.

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?

Provides no explicit when-to-use or when-not-to-use guidance. It describes the content and a warning behavior, but never says when to call this tool versus alternatives like list_design_rules or run_drc.

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, idempotentHint, and non-destructive, so the safety profile is covered. The description usefully adds the dual data-source behavior (live design rules vs. a supplied file), but says nothing about failure modes when no design is open or the file is malformed. Adequate given the annotation coverage.

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, front-loaded with the returned contents before the source/parameter detail. No filler or redundancy. Slightly terse but 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 read-only tool whose annotations already cover the safety profile, the description covers what it returns, where it reads from, and the parameter's accepted file types. No output schema exists, but the description enumerates the returned fields, so an agent has enough to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the single stackup_file parameter carries no schema description, so the description must compensate. It does: it names the parameter and specifies acceptable formats (.estackup or .edru), which the schema does not provide. That is genuine added meaning, though it omits what happens if the file conflicts with the open design.

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 resource and the exact data returned (copper and dielectric thicknesses, Er, materials), so an agent knows what comes back. The verb 'get' is implicit but the resource is unmistakable. It does not explicitly contrast with the related get_design_rules/get_board_summary siblings, which keeps it out of 5 territory.

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 tells the agent where the data is sourced from (the open design's Fusion design rules, or an external stackup_file), which is an implicit usage cue. But it never states when to prefer this over get_design_rules or list_design_rules, nor any prerequisite like a design being open, so guidance stays implied rather than 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only that the return includes metadata (source, maintainer, link), which is mildly useful given there is no output schema, but it discloses nothing about lookup failure behavior or whether it works across all open libraries.

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 wasted words. It is efficiently structured, though it is arguably too terse given the missing usage and parameter 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?

For a simple read-only getter this is minimally viable, and the description does sketch the return payload. However, with no output schema and no differentiation from sibling retrieval tools like get_part, an agent lacks enough to confidently select and invoke it.

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 single required 'part_id' parameter — not its format, origin, or how to obtain it. With one required parameter carrying no semantics anywhere, the schema cannot compensate and the description fails to fill the gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb+resource: fetching the 'Full definition of one library part.' Using 'library part' distinguishes it somewhat from the sibling 'get_part,' but it never explicitly contrasts the two, so the boundary is left to inference.

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 statement of when to use this versus the many related siblings (get_part, list_parts, search_library, open_library). An agent must guess whether this is the correct retrieval tool for a library-scoped part.

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, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, repeatable read. The description adds the useful detail that the return covers both schematic pins (with direction) and board routing per layer, which is real context beyond the annotations, though it says nothing about error behavior for missing nets.

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 that conveys purpose and the two facets of the return value with zero 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 tool with one parameter and no output schema, the description covers the essentials. However, it does not state whether the design must be open or what happens if the net name is not found, and with no output schema the agent receives no structured detail on the return shape.

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?

Only one parameter (name), and the description's framing as 'one net' makes it clear that name identifies the net to fetch. Schema coverage is 0% and the schema provides no description for name, but the parameter is self-evident given the tool's purpose.

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 (get) and resource (net), and clarifies it returns both schematic pins with direction and board routing by layer. This is more specific than the bare name and distinguishes it from list_nets (which presumably enumerates nets), though it doesn't explicitly name siblings.

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 when-to-use guidance, no mention of prerequisites (e.g., design must be open), and no distinction from alternatives like list_nets or routing_status. The agent must infer that this is for fetching details of a single named net.

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, idempotentHint=true, destructiveHint=false and a closed world, so the safety profile is covered. The description adds the aggregate nature of the response but says nothing about behavior on an unknown ref, error handling, or cost of the call.

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 that earns its place by listing exactly what comes back, with no filler. It loses a point only because the listed facets substitute for any guidance on the input.

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 tool with no output schema, describing the returned payload is the right move and the description does that. It remains incomplete on ref semantics and on any precondition such as an open design, which the agent must guess.

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 required parameter "ref" is completely undocumented. The description says only "one part", never clarifying that ref is a reference designator (e.g. R1, U3) or its format, so it fails to compensate for the schema 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 names a specific verb (get) and resource (one part) and enumerates the returned facets: board placement, schematic device, attributes, pin nets. This distinguishes it clearly from list_parts (plural) and get_net (nets), though it never names those siblings explicitly.

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 singular scope of "one part": an agent can infer this is the detail lookup after list_parts. However, there is no explicit when-to-use, no statement of prerequisites (must a design be open first?), and no routing to 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 only declare the generic safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false). The description adds genuinely useful behavior beyond that: vias are never placed via-in-pad, placement is planned one pad at a time to avoid via collisions, and all writes are grouped into a single undo step. That undo-grouping detail is exactly the kind of context annotations cannot convey.

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, leading with the core action and following with constraints and the skip semantics. Every sentence carries information; only minor tightening is possible.

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 board-mutating tool with no output schema and five undocumented parameters, the description covers the concept, safety-relevant behavior, and one parameter well but omits meaning for dry_run and the two dimension parameters. An agent could invoke it correctly at a high level but would be guessing on the numeric and dry-run 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?

Schema description coverage is 0% across 5 parameters, so the description must carry the burden. It explains only `skip` (with a concrete 'U1.4' example) and confirms the `net` default of GND; `dry_run`, `max_dist_mm`, and `trace_width_mm` are left completely undefined in both schema and description, leaving three of five parameters opaque.

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 gives a specific verb+resource: adding a via next to each SMD pad on a plane net, with the connection mechanism explained (short trace to nearest clear via spot). It is clearly distinguishable from generic add_via, but it does not differentiate itself from close siblings like stitch_vias or fanout_pad, which an agent could easily confuse it with.

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 notes that through-hole pads are skipped and that skip excludes specific pads, which are useful edge conditions, but it never states when to choose this tool over stitch_vias, fanout_pad, or clean_vias. No explicit when/when-not guidance or alternative routing is given despite many overlapping 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=false and destructiveHint=false, and the description meaningfully adds behavioral detail: mounting holes are skipped, preview_only temporarily adds then removes parts, every pin is validated afterwards, and environment-variable fallbacks (FUSION_MCP_GROUND_SYMBOL, FUSION_MCP_POWER_SYMBOL, FUSION_MCP_SHEET_FRAME) exist. It doesn't state whether an existing schematic is overwritten or what happens on re-run beyond idempotentHint=false, so it's strong but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the two core map parameters are front-loaded, then style modes, then flags. The prose is dense but each sentence carries real information (skipped holes, mode semantics, symbol fallbacks). Slightly sprawling given the multiple parenthetical example strings, but nothing is purely redundant.

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 11-parameter tool with nested objects, no output schema, and zero schema-level param descriptions, the description is unusually complete — it explains the layout semantics, the required companion inputs, and the safety modes. It leaves a minor gap around what the tool returns/reports and how it interacts with pre-existing schematic content.

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 the load, and it does for 8 of 11 parameters (part_map, pad_map, style, preview_only, dry_run, ground_symbol, power_symbol, frame). skip, sheet, and pcb_path are left unexplained, so it falls short of full 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 opening sentence states a specific verb and resource — 'Build the schematic of a KiCad board in this design' — which immediately distinguishes it from the sibling import tools (import_routing_from_kicad, import_placement_from_kicad). The two mapping parameters (part_map, pad_map) are explained with concrete examples, so the agent knows exactly what the tool consumes and produces.

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 frames the operating modes: preview_only lays out an HTML preview without drawing, dry_run reports the plan without changing anything, and style='blocks' (default) vs style='grid' (old behaviour) are contrasted. It also redirects mounting holes to add_hole. What's missing is any explicit 'use this instead of X' routing relative to siblings, so it stops short of a 5.

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

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

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

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

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

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

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

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

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

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

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

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

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), but the description adds substantial context beyond them: the operation is one undo step, the coordinate frame matches import_placement_from_kicad, every segment is validated against the Fusion board, and it warns about a severe performance pitfall (pours refilling after every via, 40+ minutes with 490 vias).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action and packed with useful detail, with almost no filler. The single dense paragraph mixes prerequisites, parameter behavior, and a performance anecdote, which slightly reduces scanability, but 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 mutating, no-output-schema import tool, the description covers prerequisites, coordinate frame, parameter effects, dry-run behavior, excluded content (pours), and a critical performance warning. Nothing an agent needs to invoke it safely and correctly is missing.

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. It clearly explains nets (limits import to those nets), vias (vias=false skips vias), and dry_run (counts only), but pcb_path is never described despite being required. Three of four parameters are well covered, leaving a minor gap for the path argument.

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 precise verb (Copy) and resource (a KiCad board's tracks, arcs and vias into this board), and explicitly names sibling tools it is not (import_placement_from_kicad, add_pour). An agent can distinguish it from all routing/import siblings without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit ordering prerequisites ('Run import_placement_from_kicad first'), exclusion rules ('Pours are not copied (use add_pour)'), a sequencing constraint ('Import BEFORE adding pours'), and a diagnostic mode ('dry_run=true only counts'). When-to-use and alternatives are fully covered.

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 annotations already declaring this is a non-read-only, non-destructive, non-idempotent operation, the bar is lower. The description adds genuinely valuable behavior beyond annotations: a crash hazard if the library is left open and the required follow-up call sequence. However, it says nothing about what the operation returns or how the part_id is resolved. This is strong added context but not a complete behavioral picture.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the action, then the required follow-up sequence, then the symbol-style detail. The style paragraph is long but every item earns its place by naming concrete valid values. Structure is clean and skimmable.

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?

No output schema exists, so the description carries the behavioral burden, and it does so well for sequencing, hazards, and symbol handling. The one gap is the unexplained required part_id, which an agent needs in order to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for the single required part_id, and the description never explains what part_id is or where to obtain it (e.g., from search_library/get_library_part). Worse, it references a "style" field as if it were part of the call, but the schema exposes no style parameter, which can mislead the agent about the tool's inputs.

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?

Names a specific action and target: building a library part into the library currently open in the library editor, and explicitly routes the agent to add_part for the later placement step, distinguishing it from create_library_part/get_library_part. The phrase 'Build a library part into the Fusion library' is slightly muddled about whether it creates or inserts, which keeps it 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?

Gives explicit ordering constraints — call save_design, then close_library, before placing with add_part — and states the consequence of ignoring them (placing from a still-open library can crash Fusion). It also tells the agent when to override the default symbol behavior via style.

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 idempotentHint=false, but the description says labels are added only to pieces 'without a label', implying that repeated calls with the same arguments would become no-ops once all pieces are labeled. That contradicts the non-idempotent 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 two sentences, front-loaded with the verb and scope, and the parenthetical convention adds useful context without excessive waste.

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 non-readonly mutation with no output schema, the description covers the operative condition and the scoping parameter. It leaves return behavior, permission requirements, and interaction with existing labels unstated.

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% for the single optional `nets` parameter. The description only says 'Limit with `nets`' and does not clarify whether entries are net names, IDs, patterns, or something else, so it does not compensate for the missing 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?

States a specific verb ('Add a net label') and resource ('net'), with a precise scoping condition: every separately drawn piece of a net that lacks a label. This is clear enough to separate from rename_net, but it does not explicitly name sibling alternatives.

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 supplies the operative convention ('same net, not visibly connected, must be named') and notes that the scope can be limited with `nets`. It does not state when not to use this tool or name any alternative explicitly.

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 the write/safety profile (readOnly=false, destructive=false, idempotent=false), and the description adds genuinely new context beyond them: conflict checking against other nets' copper, holes, keepouts and pitch, and the atomicity guarantee that 'nothing is written if a lane conflicts'. It also explains the dry_run default returning a plan and picture. Only the return format in non-dry-run mode is left implicit.

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 dense paragraph that front-loads the core action and geometry before moving to workflow and safety. Sentences are information-dense and mostly earn their place, though the run-on phrasing around vias and conflict checking could be tightened.

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 six-parameter geometry tool with no output schema and no annotation detail, the description covers the mental model, the follow-up step, ordering heuristics, conflict behaviour and the dry-run contract well. The gaps are the layer/width parameters and the exact result of a committed run.

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 all six parameters. It does well on nets (ordering), path_mm ([[x, y], ...], 45-degree corners), pitch_mm (offset direction relative to travel) and dry_run, but never explains layer or width_mm, leaving two parameters undocumented anywhere.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Lay a bus: one lane per net, side by side along a path') and immediately pins down the geometry (lane 0 on the path, lane i offset i*pitch to the LEFT). This clearly separates it from sibling routers like route_net, route_pair and route_trace.

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 explicit workflow guidance — 'Then join each pin to its lane with route_net' — and practical ordering advice ('Order nets so the taps at the ends cross as little as possible'). It also flags the default dry_run behaviour, though it never states when this tool should be avoided in favour of autoroute or route_remaining.

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 states that copy_to 'copies the files into a folder', which is a filesystem write operation. The annotations declare readOnlyHint=true, meaning the tool does not modify its environment; this is a direct contradiction. Per the rubric, a description that contradicts annotations scores 1 here.

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 paragraph is dense but front-loads the resource description and then explains how to use the files and what copy_to does. The provenance aside about gen_jlc_stackups.py is extra but minor; overall the information is relevant and not repetitive.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and one optional parameter, the description covers what the tool provides (shipped rule files and their contents), how to use them in Fusion, and what copy_to does. It stops short of explicitly stating the return format (e.g., a list of file paths), but that is a minor omission for a simple listing tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single optional copy_to parameter has 0% schema coverage, so the description must carry the meaning. It provides exactly that: 'copy_to copies the files into a folder you can reach from Fusion's file dialog (e.g. Downloads),' clarifying the parameter's purpose and giving a concrete example.

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 specific resource (shipped .edru and .estackup files) and enumerates their contents (copper layers, board thickness, dielectrics, key clearances), so an agent can tell what the tool is about. It does not name the sibling get_design_rules or explicitly state 'list', but the scope is clear enough.

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 that Fusion cannot load rules from a script and that .edru files must be loaded via the DRC dialog while .estackup files go through the Layer Stack Manager, which gives practical context. However, it does not say when to choose list_design_rules over get_design_rules or other sibling tools, leaving the alternative 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 read-only, idempotent, non-destructive behavior. The description adds genuinely non-obvious behavior: folders are not searched recursively, with the rationale that walking a large folder tree froze Fusion. That performance/correctness caveat is real added value beyond the structured fields.

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 dense sentence, front-loaded with the resource and scope, with the operational caveat in parentheses. The examples and the freeze rationale earn their place, though the sentence is long enough that a reader must parse several clauses.

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 list tool with one optional parameter and no output schema, the description covers scope, parameter behavior, examples, and the non-recursion constraint. It stops short of describing the return shape (design names vs paths vs libraries), a minor gap given no output schema exists.

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 the 'folder' parameter. It does so well: it defines the parameter as a single folder path, gives concrete examples ('Live tests', 'Parts/Connectors'), and clarifies that omitting it defaults to the project top folder.

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 (list) and resource (electronics designs and libraries) plus the exact scope (active Fusion project's top folder). An agent can distinguish it from list_parts/list_nets/list_pours by resource, though it never names those siblings explicitly.

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 pass a folder versus leaving it default, and explains the non-recursive constraint. However, it names no alternative tool and gives no explicit when-not-to-use guidance relative to the many other list_* 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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds real value by disclosing that the skew limit defaults to the design's dpMaxLengthDifference rule, but it offers no other behavioral context (e.g., scope of the design it reads).

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, and the returned-field list is front-loaded before the parameter default note. Slightly telegraphic but every phrase carries 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?

An output schema exists, so return values need not be spelled out, and the description covers the resource and the one parameter's default behavior. A note about which design context it operates on would make it fully self-contained.

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% for the single max_skew_mm parameter, so the description must compensate, and it does: it explains that the skew limit defaults to the design's dpMaxLengthDifference rule, giving the parameter meaning the bare schema lacks.

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 (differential pairs identified by _P/_N naming) and enumerates the per-side attributes returned (length, skew, width, gap, vias). The verb is implied by the name rather than stated, but the scope is specific enough to distinguish it from list_nets/get_net.

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 versus siblings such as check_length_match, route_pair, or list_nets, nor any stated prerequisites (e.g., an open design). 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful context that nets are merged across schematic sheets and that pin counts/routed length are included, but says nothing about pagination or how limit/filter behave.

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 that packs the resource, its merging behavior, and its attributes with zero waste. Nothing is padded or buried.

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?

Because an output schema exists, return values need not be explained, and the annotations cover the read-only profile. However, the filter parameter's matching semantics are left entirely undocumented, which is a real gap for a list tool whose primary use is filtering.

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 limit or filter parameters, so their semantics (defaults of 1000 and empty string, matching behavior) must be guessed. With two undocumented params the description fails to compensate.

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 clear verb+resource ('list... Nets') and adds the returned attributes (pin counts, routed length) and the merging semantics. It does not explicitly distinguish itself from the close sibling get_net, which is the only gap keeping it below 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?

There is no when-to-use guidance and the near-identical sibling get_net is never mentioned, so an agent gets no help deciding between listing all nets and fetching one. Usage is only implied by the name.

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, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds that results include placement and JLC attributes, which is mild extra context, but says nothing about ordering, pagination, or default behavior beyond what annotations supply.

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, front-loaded sentences with no filler. The content is efficient, though the terseness leaves the `limit` parameter and usage context uncovered.

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 needn't be described. However, for a read-only listing tool with 0% schema coverage, the description omits any explanation of `limit`, result ordering, or when to use this over sibling listing tools — leaving meaningful 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 carry the burden. It explains that `filter` matches refdes, value, or package, which is genuinely useful, but the `limit` parameter (default 500) is left completely unexplained. Partial compensation for a zero-coverage 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?

States the resource (parts on the board) and the payload returned (placement and JLC attributes), which distinguishes it from the single-part get_part and the mutating add_part/set_part_value siblings. It lacks an explicit list verb and doesn't name alternatives, so it's clear but not fully differentiated.

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 offers no when-to-use guidance, no mention of when to prefer get_part or list_nets instead, and no prerequisites. It describes content only, leaving the agent to infer context from the name.

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, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered. The description adds only that the settings are 'live' (current state rather than cached), which is modest added context beyond 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?

A single sentence with the resource front-loaded and the returned fields listed compactly; 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?

With no output schema, the description usefully enumerates the fields the pours carry, covering the main informational need. It could be marginally stronger by noting whether pours from all layers or the active design are included, but it is complete enough for a zero-argument read tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to clarify beyond the schema's empty argument object.

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 clear resource (copper pours) and enumerates the live settings returned (net, layer, thermal relief width, isolate, rank), so the agent knows exactly what it gets back. It does not explicitly distinguish itself from add_pour or set_pour_thermals, but the read/list framing makes that distinction obvious from the name.

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 statement of when to use this tool versus alternatives such as list_nets or get_board_summary, and no prerequisites or exclusions. Usage is only implied by the tool name.

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, idempotentHint=true, and readOnlyHint=false, so the mutation and reversibility profile is covered. The description adds the useful origin-anchoring detail but says nothing about overwriting existing placement, undo semantics, or coordinate frame (board vs. design).

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 zero waste; the key placement semantic is stated immediately.

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 3-param mutation with annotations covering the safety profile and no output schema, this is nearly adequate, but the completely undocumented 'ref' parameter leaves a real gap for an agent trying to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and there are no param descriptions, so the description's mention of (x, y) in mm usefully clarifies the units for x_mm/y_mm. However, the 'ref' parameter — which part reference is expected — is left 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?

States a specific verb (move) and resource (board part) and adds the precise semantic that the part's origin is placed at (x, y) in mm. This distinguishes it cleanly from siblings like rotate_part or place_clusters.

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 indication of when to use this versus rotate_part, place_clusters, or suggest_placement_moves, and no mention of prerequisites (e.g., needing an open design). The agent must infer usage purely from the verb.

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 only supply the generic safety flags (not read-only, not idempotent, not destructive). The description adds real behavior beyond them: the design is persisted immediately into the active project only when `name` is given, and `folder` is auto-created if missing. That side-effect disclosure is genuinely useful, though return/ID behavior is unstated.

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, front-loaded with the core action and followed by the persistence rule. No filler or restated title content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 2-param creation tool with no output schema and generic annotations, the description covers the essential creation and persistence semantics. The only gap is what the caller receives back (e.g., a design handle) and how to subsequently interact with the new design.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description carries the full burden and does so for both parameters: `name` triggers immediate saving into the active project, and `folder` is an optional destination created if missing. It compensates well, though it doesn't clarify the exact behavior when `name` is omitted.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Create a new electronics design') plus the resulting artifacts ('with a schematic and a board'), which immediately distinguishes it from list_designs and open_design. An agent can identify it as the creation entry point without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied rather than stated: this is the tool for starting a fresh design, contrasted implicitly with open_design/list_designs. There is no explicit when-not-to-use or prerequisite guidance, so the agent must infer 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 establish a non-readonly, non-idempotent, non-destructive write. The description adds genuine context beyond that: Fusion does NOT auto-add a frame, the env-var default fallback, and the return payload (sheet number + drawing area). This is meaningful behavioral disclosure for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core action, then addresses the two non-obvious parameters in order. Dense but every clause is functional. Slightly terse transitions ('or none') keep it from a 5.

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?

No output schema, but the description explicitly names what is returned (sheet number and drawing area). Combined with param and mutation context, an agent has enough to invoke it correctly; only the format/shape of the return value is unspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry the load and largely does: `frame` syntax ('DEVICE@LIBRARY') and default source, `sheet` for targeting an existing sheet, and `title` as the headline/sheet description. Only the null/omitted behavior of frame and title is left slightly 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?

States a specific verb+resource ('Add a schematic sheet') plus the two side effects (frame, headline). This is clearly distinguishable from siblings like new_design, add_part, or add_text. An agent can tell what it produces without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains the two operating modes: pass `sheet` to configure an EXISTING sheet vs. create a new one, with a concrete example ('sheet 1 of a new design'). It also clarifies the frame default resolution order. It stops short of naming an alternative sibling tool, so not a full 5.

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, idempotentHint=false, destructiveHint=false, so the mutation profile is partly covered. The description adds that it makes the design 'current', disclosing a state change, but says nothing about what happens to an already-open design or whether switching is safe.

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 tight sentence with the action front-loaded and 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 non-idempotent mutation tool with no output schema and 0% parameter documentation, the description is thin: it omits the effect on any currently open design and the meaning of 'folder'. It is adequate but leaves real gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so both parameters are undocumented in the schema. The description does not explain what 'name' identifies or what the optional 'folder' parameter does, leaving a required-parameter tool under-specified.

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+resource ('Open a design') and adds meaningful scope detail: it loads both schematic and board from the active project. This clearly distinguishes it from siblings like new_design and close_design, though it does not explicitly name 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 phrase 'from the active project and make it current' implies the context in which this tool applies, but there is no explicit when-to-use vs new_design/close_design/list_designs guidance and no stated prerequisites.

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, destructiveHint=false, and idempotentHint=false, so the agent knows this mutates editor state without destroying data and is not repeatable-safe. The description adds the 'from the active project' scoping constraint, which is useful, but says nothing about what opening does to prior editor state or whether the library must already exist.

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 tight sentence with no waste, front-loading the action and resource. It is appropriately sized, though the brevity comes at the cost of detail rather than through efficient density.

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 state-changing tool with no output schema, 0% parameter documentation, and no annotations covering what opening actually does, the description leaves too much unspecified — notably what 'name' and 'folder' mean and what state results after 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%, so the description carries the full burden, yet it never mentions 'name' or 'folder' or how they interact (e.g., whether folder qualifies the library lookup). With an undocumented required parameter and an optional one, this is a real 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?

States a specific verb (open) and resource (Fusion library .flbr) and scopes it to the active project's library editor. It is distinguishable from siblings like open_design and search_library, though it does not explicitly contrast itself with 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?

There is no guidance on when to open a library versus alternatives such as search_library, get_library_part, or insert_library_part, nor any preconditions beyond 'from the active project'. Usage is only implied by the tool name.

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 flag destructive=true and idempotent=true, and the description adds genuine context beyond them: main parts and `fixed` never move, `keep` members stay, application is 'one undo step', and traces on moved nets are left behind. This materially warns the agent about side effects and reversibility.

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 purpose is front-loaded, but the body is a dense run-on paragraph heavy with semicolons and parentheticals, making it harder to parse than needed. Every clause is relevant, but structure and readability suffer.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex, no-output-schema mutation tool it covers purpose, defaults, effect scope, safety/reversibility, and the rip-up prerequisite, and it even describes the dry_run return ('moves and a before/after picture'). Only the identifier conventions for keep/fixed remain unspecified.

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 and does define all three parameters: `keep` (members to leave alone), `fixed` (never move), and `dry_run` (default returns moves vs. applies them). The semantics are covered, though the exact identifier format expected for keep/fixed is not specified.

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+resource ('place passives around the part they serve, by rule') and enumerates the actual placement rules, so an agent understands exactly what operation it performs. It never names the neighboring siblings (move_part, suggest_placement_moves, score_placement) to differentiate itself, 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?

Gives a clear workflow: dry_run=true returns the moves plus a before/after picture, then run with dry_run=false to apply, and it states the rip-up prerequisite for traces on moved nets ('rip them up first... and re-route with route_close'). It lacks any explicit when-not or comparison against alternative placement 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 destructiveHint=true, idempotentHint=true and openWorldHint=false, but the description adds real context beyond them: it creates the 3D PCB on first run, interacts with Fusion's Push dialog, reports a wrong_side list for mis-oriented models, and notes the transport constraint that the built-in server cancels open commands. It doesn't spell out what state is overwritten by the destructive push, keeping it short of a 5.

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 dense sentences, front-loaded with the core action before the diagnostic and prerequisite details. Every clause carries information, though the parentheticals make it slightly hard to parse at a glance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no parameters and no output schema, the description carries the burden of return semantics and does so by naming wrong_side as the key output. The transport caveat for the first push is also surfaced, leaving only minor gaps (e.g. full shape of the result) for a zero-arg tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters (schema coverage 100%, no enums), so there is nothing to disambiguate. The baseline of 4 applies since no parameter semantics need to be conveyed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Bring the board's changes into its 3D PCB') and elaborates the two phases: creating/syncing the 3D PCB and validating each part's model side. An agent can distinguish it from siblings like attach_3d_model and check_3d_models because it names the 3D PCB sync action and the wrong_side output explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied (run after board changes to sync into 3D and validate part orientation) and it flags the first-push prerequisite (needs the add-in transport). However, it never explicitly contrasts when to use this versus check_3d_models or attach_3d_model, so the agent must infer the boundary.

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?

Goes well beyond the destructiveHint/idempotentHint annotations by disclosing exactly what gets destroyed (ends snapped, ends cut back to a tap/via, whole segments deleted), that the board's copper is checked directly when geometric=true, and the safety guarantee that every change is verified and the run aborts if unrouted connections increase. That is the kind of mutation-safety context an agent needs before invoking a destructive tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the one-line purpose, then dense but relevant detail. Every sentence carries information about behavior or safety, though the parenthetical about Fusion re-anchoring is compact enough to be easily skimmed past.

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, idempotent mutation tool with no output schema, the description covers what is changed, the default parameter behavior, and the safety guarantees. The remaining gaps (meaning of max_rounds, permission/undo interaction) are minor given the annotations already declare the safety profile.

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. It does explain 'geometric=true (default)' as additionally checking the board's copper directly, but it never mentions max_rounds or what a 'round' does, leaving one of two parameters undocumented anywhere.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Fix trace stubs') and then precisely defines what a stub is and what happens to each kind (snap to pad centre, cut back to last junction, or delete the segment). No sibling tool in the list overlaps with this operation, so it is cleanly distinguishable.

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 stated: the note that Fusion re-anchors trace ends off-centre when a part rotates, and that Fusion's DRC misses some stubs, tells the agent when stubs arise and why DRC alone is insufficient. However, there is no explicit 'use this after X / before Y' instruction and no named alternative to run_drc, so the agent must infer the trigger conditions.

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 idempotentHint=true, so the safety profile is covered. The description adds genuine context the annotations cannot: renaming onto an existing name merges nets and is refused unless allow_merge is true, and only_segment_with_pin narrows the mutation to a single pin stub. Minor gap is no mention of error/return behavior beyond the merge refusal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the core rename and merge semantics, then handles the special-case parameter. The closing pin-swap recipe is arguably extra, but it earns its place as non-obvious usage guidance rather than padding.

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 with no output schema and rich annotations, the description supplies the net-merge rule and per-segment mode needed to invoke it safely. It stops short only on return/verification info, which is acceptable given no output schema exists.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description carries the full burden and does so well: allow_merge's refusal semantics are stated and only_segment_with_pin's value format ('REF.PIN') plus its precise effect on scope are explained. old_name/new_name need no elaboration.

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+resource ('Rename a schematic net') and immediately scopes it ('all sheets where it has wires'). An agent can distinguish this from route_net or label_nets without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives clear context for when each mode applies, including a concrete workflow for swapping two pins' nets. It does not explicitly name sibling alternatives (e.g. label_nets, connect_pins) or state when not to use it, keeping it just short of 5.

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 establish readOnly/idempotent/non-destructive, so the bar is lower. The description adds genuinely useful operational context: it is a fresh export, an optional matplotlib dependency is required, and it returns the PNG plus its save location. It 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?

Front-loaded with what the image contains, then parameter hints, then the dependency and return note. The rendered-element list is long but every item is meaningful; little waste.

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 image-producing tool with no output schema, the description tells the agent it gets a PNG and where it lands, plus the dependency requirement. Sufficient to invoke correctly, though it could say more about what 'traces' toggling does.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry the load. It clarifies highlight_nets (regex of nets, colored and labeled at pads), region_mm ([x0,y0,x1,y1] zoom box), and plan (a route_pair plan drawn on top), but leaves 'traces' and 'out_path' only obliquely covered by 'where it was saved'.

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 concrete verb+resource: producing a PNG picture of the board's current state, and enumerates exactly what is rendered (outline, pads, holes, keepouts, part names, traces with colors, vias, pours). No sibling tool renders an image, so it is trivially distinguishable.

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 what each option does and connects 'plan' to a dry_run output, but never states when to reach for this tool versus e.g. get_board_summary or routing_status, nor any exclusions. Usage is implied by the content, not guided.

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, idempotentHint, destructiveHint=false and openWorldHint=false; the description reinforces this by disclosing that the backend is 'not connected yet' and makes no network calls. That is genuinely non-obvious behavior an agent must know before calling, since the call will silently do nothing.

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 an efficient parenthetical. No wasted words, though the parenthetical could be integrated more cleanly into the sentence.

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?

Annotations already carry the safety profile and no output schema exists, so return-value explanation is unnecessary. However, the sole parameter is undocumented and there is no routing guidance against the automated design-check siblings, leaving a modest gap for a tool whose main risk is being confused with 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?

There is one parameter ('notes') with 0% schema description coverage, and the description says nothing about it. The description does not compensate for the undocumented parameter, leaving the agent to guess what to pass.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: 'Request a human design review from Groundplane.' The word 'human' implicitly separates it from automated siblings like run_drc, run_erc, and review_schematic, though it never names an alternative explicitly.

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 when-to-use guidance is given and no sibling is referenced. With run_drc, run_erc, and review_schematic all present in the same namespace, the agent is left to infer that this is the human-fallback path rather than an automated check.

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, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description usefully discloses the analysis scope (which rule categories run), which is real value beyond annotations, but says nothing about result severity, whether findings block anything, or how results are surfaced. Adequate, 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?

A single front-loaded sentence that leads with the tool's identity and then enumerates the checks. No filler, though the parenthetical rule list makes it dense.

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?

No output schema exists, so the description should ideally hint at what a review returns (violation list, counts, severity) and it does not. Combined with the silent parameter, the definition is usable but leaves the agent guessing about results and the ERC toggle.

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 single parameter include_erc has 0% schema description coverage, so the description must carry it. It never names the parameter, but by stating the tool runs 'offline rules ... plus Fusion's ERC' it lets the agent infer that ERC is an optional bundled stage matching the include_erc boolean. Partial compensation only; the toggle semantics remain 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?

States a specific verb (review) and resource (schematic), and enumerates the actual rule classes it runs (unconnected power pins, single-pin nets, output conflicts, undriven nets, missing JLC codes, empty values), which is far more informative than a bare 'review schematic'. It partially distinguishes itself from the sibling run_erc by framing itself as offline rules PLUS Fusion ERC, though it never explicitly contrasts the two.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied (run a review before fabrication/export) but there is no explicit when-to-use, when-not-to-use, or routing to the sibling run_erc. An agent has to infer whether this supersedes run_erc or complements 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 declare destructiveHint=true but not the details; the description adds substantial value by disclosing that traces/vias convert to unrouted connections rather than being lost, that polygons/pours are preserved, and that a ripped net's pours remain unfilled (with a version reference). This is exactly the beyond-annotation behavioral context an agent needs to avoid a costly mistake.

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, front-loaded with the core action before the caveat, with no filler. The parenthetical version stamp '(2705.1.15)' is slightly inside-baseball but the warning it attaches to is substantive, so only a minor deduction.

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 no output schema, it covers what is destroyed, what is kept, and a non-obvious side effect, which is strong. The only real gap is the undefined behavior of the null/default 'nets' argument.

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% for the single 'nets' parameter, so the description must carry the load, and it only references 'a ripped-up net' obliquely. It neither confirms the list-of-net-names format nor explains the nullable default (what happens when nets is omitted), leaving a meaningful 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?

States a specific verb (remove) and resource (routed traces and vias), then clarifies the resulting state ('become unrouted connections again'), which separates it from sibling mutation tools like clean_vias or undo. An agent knows exactly what this tool does without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives a concrete when-to-be-careful rule ('avoid ripping up nets that have pours, or re-add their pours after'), which is real usage guidance. It stops short of naming explicit alternatives (e.g., undo, route_net) or a full when-to-use/when-not matrix, so it falls just short of a 5.

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, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds useful context with 'absolute' (implying existing rotation is overwritten rather than composed) and the meaning of bottom=true, but says nothing about reference origin, whether the change is undoable, or interaction with placement/routing.

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 compact sentence that front-loads the operation and appends the parameter clarification. Every clause carries information; the parenthetical on bottom is slightly redundant with the parameter name but still clarifies semantics.

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 mutation tool with no output schema and a destructive annotation, the description covers the core operation and two parameters but omits the meaning of 'ref', the rotation origin, and any indication of what the call returns or whether it can be undone.

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 the burden; it explains 'angle' (degrees, absolute) and 'bottom' (true = bottom side), which is real added value. However, the required 'ref' parameter is never explained, leaving one of three parameters undocumented in both schema and description.

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 gives a specific verb ('Set') plus resource ('a board part's absolute rotation ... and side'), which is enough to distinguish it from move_part and set_part_value. It does not explicitly name any sibling, but 'absolute rotation' is a meaningful discriminator an agent can act on.

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 statement of when to use this tool versus alternatives such as move_part or set_part_value, no prerequisites, and no note about when a rotation change is appropriate. Usage must be inferred entirely from the name.

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