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

With no annotations, the description must carry behavioral disclosure. It does disclose the key behavior of not applying working XML, which is valuable. However, it does not explain side effects (e.g., whether session state is deleted, whether any cleanup occurs) or mention safety/irreversibility.

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

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

The description is a single, focused sentence that front-loads the action and key qualifier. It is concise and free of fluff.

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 tool with one parameter and an output schema, the description is mostly sufficient. It captures the core purpose and behavior, though it does not explain the relationship to finish_live_session or the broader transaction lifecycle, which could be useful.

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 100% because the only parameter (reason) has a description that mirrors the tool description. The tool description adds no new information about the parameter's format or semantics beyond what the schema already provides.

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

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

The description clearly states the action ('Abandon stale local session state') and the key behavior ('without applying its working XML'). It distinguishes from siblings like finish_live_session by focusing on stale state and explicitly noting no XML application.

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 for stale sessions by using the word 'stale', but does not explicitly state when to prefer this over finish_live_session or provide alternative guidance. No exclusions or context cues 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?

With no annotations provided, the description carries the full burden of behavioral disclosure, and it delivers: the 'millimetres regardless of document Units' gotcha is a genuinely non-obvious behavior that would cause subtle bugs; the dry_run preview semantics with the expected_sha256 confirmation flow is a rich side-effect disclosure. This goes well beyond what a minimal read of the schema would reveal, though it could note whether the operation participates in the transaction system visible among siblings (begin_transaction/commit_transaction).

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-written sentences with zero fluff. Sentence one states what + the units gotcha; sentence two states the dry_run contract; sentence three states the confirmation workflow. Every word earns its place and the structure follows a logical safety-first order.

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 10-parameter mutation tool with 0% schema coverage and no annotations, the description captures the essential operational recipe: units, preview mode, and confirmation handshake. The 'net-bound' vs text nuances and multi-sheet implications (sheet param) could use a sentence, but with an output schema present, return-value explanation isn't needed. The coverage is appropriately proportional to the tool's 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?

Schema description coverage is 0%, so the description must compensate. It does clarify the most critical params — units for x/y, the dry_run/default-true safety behavior, and expected_sha256 as the confirmation token. However, the relationship between `net`, `text`, and `path` remains ambiguous: is `text` the displayed label while `net` is the target net? What is `txid` used for? The description covers maybe 4 of 10 parameters functionally, which is a partial but incomplete compensation.

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

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

The description uses a specific verb+resource+scope: 'Add a net-bound text label shape to a schematic sheet.' The qualifier 'net-bound' differentiates it from plain text annotation tools, and 'to a schematic sheet' scopes the operation. This clearly distinguishes it from siblings like set_text_visibility or add_wire.

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

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

The description gives clear operational context ('dry_run=true previews... Set dry_run=false only after inspecting the preview') but never explicitly addresses when to use this tool vs alternatives. No named siblings or exclusion criteria are provided. The workflow is clear but the tool-selection guidance is only implied, not stated. Compared to the HIGH calibration example that explicitly says 'use search_calls_extensive instead,' this lacks an explicit alternative reference.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It clearly states that dry_run=true previews without writing and that committing requires expected_sha256, which is meaningful safety/behavioral context. It does not mention reversibility, transaction interactions, or error states, but the disclosed workflow is substantive.

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 primary action, and every sentence adds value. The dry-run guidance is compact and actionable with 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?

The description covers the core preview-then-commit workflow but omits context around optional parameters like txid, path, and sheet_type, and does not clarify transaction or document-state requirements. The output schema likely fills return-value gaps, but for a 6-parameter mutation tool with no annotations, the description is only partially complete.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It explicitly explains dry_run and expected_sha256 semantics and their relationship. However, it does not explain the other four parameters (name, path, txid, sheet_type), leaving gaps for required inputs and optional context.

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

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

The description uses a specific verb+resource ('Add a new sheet to a schematic document') that clearly states the tool's function. It distinguishes itself from sibling tools like add_wire or add_trace by specifying 'sheet' and 'schematic document', and the dry-run workflow adds further precision.

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

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

The description provides a clear usage workflow: first run with dry_run=true to preview, then after inspecting the preview set dry_run=false and pass expected_sha256. It gives a concrete when-to-use and when-to-avoid, though it does not explicitly name alternative tools or conditions for choosing a different operation.

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?

Discloses that distances are in millimetres regardless of document units, that the operation is atomic, and that dry_run previews without writing. This adds meaningful behavioral context beyond the schema, though it doesn't describe failure modes or what the preview 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?

Three sentences, front-loaded with purpose and then key safety details. Each sentence is essential and non-redundant, making it concise and well-structured.

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

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

For a write operation with nested parameters and a dry-run/commit pattern, the description covers the essential workflow and safety requirements. It doesn't detail the preview output format or transaction integration, but the output schema and sibling transaction tools provide surrounding 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 description explicitly explains the critical parameters: dry_run's behavior and expected_sha256's role as a safety check. It also clarifies units for all distance parameters. Path and txid are left implicit, but the nested operation schema already documents most distance 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?

Description states 'Add explicit standalone-pad testpoints and connect them to existing nets atomically' with a specific verb and resource, clearly distinguishing from sibling tools like move_testpoints or remove_testpoints. It also clarifies the atomic nature, which is a key differentiator.

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 a clear workflow: use dry_run=true to preview, then set dry_run=false with expected_sha256 after inspection. This gives clear context for safe usage, though it does not explicitly exclude alternatives like find_testpoint_candidates for discovering locations.

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

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

With no annotations provided, the description carries the full burden and does well: it reveals critical behavioral traits such as unit normalization ('All distances are in millimetres'), the safe dry-run default, and the integrity check via expected_sha256. It goes beyond a generic 'add trace' statement by explaining the validation mechanism.

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 long, front-loaded with the primary purpose, and every clause adds value. It avoids repetition and effectively communicates the essential workflow in minimal space.

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 11-parameter tool with no annotations, the description covers the critical usage context: preview-before-commit, expected_sha256 verification, and unit handling. It does not explain all parameter relationships or the structure of points, but the output schema and the focused safety workflow make the tool actionable enough.

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

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

The schema has 0% top-level parameter descriptions, forcing the description to compensate. It adds meaning for dry_run and expected_sha256, and clarifies units for distance parameters. However, it does not explain the meaning or format of core parameters like net, start/end_object_id, points, layer, or width, leaving a significant gap in parameter understanding.

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

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

The description clearly states the tool's function: 'Add an explicit validated trace path between two normalized pad endpoints.' It specifies a verb (add), a unique resource type (trace path), and the specific target endpoints, distinguishing it from sibling tools like route_net or 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?

The description provides a clear two-step workflow: use dry_run=true to preview, then set dry_run=false and pass expected_sha256 only after inspecting the preview. It implies this is for explicit manual trace placement rather than automatic routing, though it does not name alternative tools 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?

With no annotations provided, the description carries the burden of disclosing behavior. It reveals that all distances are in millimetres regardless of document units, dry_run=true prevents writing, and expected_sha256 must be provided for the actual write. This is useful behavioral context, but it does not explain what 'verified' entails or potential failure scenarios, so not 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?

The description is three sentences, front-loaded with the core purpose, then units, then the safe workflow. Every sentence adds distinct value with no redundancy or filler.

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

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

The output schema exists, so return values are covered. The description covers the core workflow and units, but leaves gaps: the meaning of 'verified', the role of path/txid/layer_before/layer_after, and any prerequisites beyond having an existing segment. For a complex PCB editing tool, this is moderately complete but not comprehensive.

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 only elaborates on dry_run and expected_sha256. The other eight parameters (x, y, trace_id, via_style, path, txid, layer_before, layer_after) receive no semantic explanation beyond their names/types. This is insufficient for a 10-parameter tool, especially with obscure fields like layer_after and expected_sha256.

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

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

The description states a specific action ('Add a verified ViaStyle trace point') on a specific resource ('existing segment'), clearly differentiating it from sibling tools like add_trace or set_via_style. The verb and object 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?

The description provides clear workflow context: distances are always in millimetres, and the dry_run preview step precedes the actual write, with the requirement to pass expected_sha256 after inspection. However, it does not explicitly mention when to choose this tool over alternatives (e.g., add_trace, move_via), so it misses the 'when-not' guidance for 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?

With no annotations, the description carries the burden of behavioral disclosure. It covers the critical unit override, dry-run preview behavior, and the safety requirement for expected_sha256. It does not detail failure modes or side effects, but the guidance provided is substantial and directly useful.

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 three sentences, all front-loaded and each adding distinct value: the core operation, the unit caveat, and the dry-run workflow. There is no redundancy or extraneous information.

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

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

The description captures the essential workflow and unit behavior, and an output schema exists, so return-value documentation is less critical. However, with 10 parameters and 0% schema coverage, many input semantics remain underdocumented, leaving the agent to guess about start/end structures and other fields. This makes the description adequate but not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate by explaining parameter meanings. It only clarifies dry_run, expected_sha256, and the millimeter units for points; it leaves net, start, end, path, txid, sheet, and hidden_power unexplained. This is insufficient for a 10-parameter tool with nested endpoint types.

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

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

The description clearly states the action ('Add a wire to a schematic net') and specifies the target resource (schematic net). It also distinguishes from sibling tools like add_trace (PCB trace) and delete_wire by clarifying the schematic context and the official XML structure.

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 explicit operational guidance: all distances are in millimeters regardless of document units, and the dry_run workflow is described with a clear sequence (preview first, then set dry_run=false only after inspecting and passing expected_sha256). It does not explicitly mention alternatives or when-not-to-use scenarios, so a small deduction.

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

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

With no annotations, the description carries the full burden of disclosing behavior. It clearly states the atomic transaction nature, the unit handling, and the required dry-run-to-commit workflow with expected_sha256 verification. It does not discuss locked components or failure modes, but the 'allow_locked' parameter partially addresses this, and the description is notably more transparent than typical mutation tools.

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 three sentences long, front-loaded with the primary purpose, and every sentence adds value: the core action, the unit caveat, and the safety workflow. No fluff or repetition, making it highly efficient.

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

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

The description covers the most critical operational aspects: the atomic behavior, unit rule, and the dry-run/commit flow. Given the output schema exists, return values need not be described. However, it does not clarify how the alignment enum interacts with target_value or the selector's scope, leaving some gaps for a tool with 8 parameters and a nested schema.

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

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

The description explains the non-obvious dry_run and expected_sha256 parameters, which is valuable given the 0% schema description coverage. However, it leaves selector, alignment, allow_locked, and target_value semantically undefined, relying on their terse names and the enum. Since schema coverage is 0%, the description should compensate more, but it only addresses two of eight parameters.

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

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

The description clearly states the action ('Align PCB component body bboxes') and the resource ('PCB component body bboxes'), with an explicit scope ('as one semantic transaction') that distinguishes it from sibling tools like 'move_components' and 'distribute_components'. It is a specific verb+resource combination with clear intent.

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

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

The description provides clear usage directives: distances are always in millimetres regardless of document Units, and the dry_run=true preview must be inspected before setting dry_run=false with an expected_sha256. While it does not explicitly name alternative tools (e.g., move_components), it conveys when and how to use this tool safely.

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 only behavioral disclosure is that distances are interpreted in millimetres regardless of the document's Units attribute, which is useful. However, with no annotations, the description does not state whether the tool mutates anything, what it validates, or what side effects/return behavior to expect.

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 only two clauses and has no filler; the units note is worth stating. It is front-loaded, but its brevity comes at the cost of essential purpose 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 a nested constraints schema, 0% top-level parameter descriptions, many closely related sibling tools, and no annotations, this description is far from sufficient. It does not enable an agent to understand when to invoke the tool or how to structure the input.

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 top-level path and constraints parameters, so the description carries the burden. It adds unit semantics for all distances, but does not explain that constraints is an array of ImpedanceConstraintInput objects or how target_ohm/tolerance_ohm/width_mm interact.

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

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

The description only provides an alias ('validate_impedance_constraints') and a units note; it never states what analyze_controlled_impedance actually does. The tool name carries the verb and resource, but the description itself is nearly tautological and does not differentiate it from sibling impedance tools.

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

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

No guidance is given about when to choose this tool over calculate_impedance, validate_impedance_constraints, suggest_trace_geometry_for_impedance, or analyze_stackup_for_impedance. The alias hints it overlaps with validate_impedance_constraints but provides no selection criteria.

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 lists what is measured, which gives some behavioral insight, but it does not disclose whether the tool is read-only, what it returns, whether it requires an existing pair, or if it has side effects. Since there are no annotations, the description carries the full burden, which is not met.

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

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

The description is a single concise sentence that front-loads the primary verb and lists all key measurement types. It is succinct without unnecessary words, though it could benefit from better structure to separate purpose from usage/parameter details.

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 existence of an output schema, return values need not be described, but the description omits critical context such as whether this analyzes a single pair (vs. plural), how to specify the pair, and prerequisites. The tool is simple but the description leaves significant ambiguity about its scope and usage 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?

Schema coverage is 0% and the description does not explain the meaning, format, or expected usage of the parameters 'pair' and 'path'. The description adds no value beyond the schema field names, so it fails to compensate for the complete lack of parameter documentation.

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

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

The description uses a specific verb 'Measure' with a clear resource 'differential pair' and enumerates the key measured attributes (pair lengths, skew, via balance, coupled length, edge gap). This clearly distinguishes it from sibling tools like validate_differential_pair (which validates) and analyze_differential_pairs (which likely handles multiple pairs).

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

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

No guidance is provided on when to use this tool versus alternatives such as analyze_differential_pairs (plural) or measure_net_lengths. The description implies analysis of a single pair, but does not explicitly state that this is for one pair or when to prefer it over similar 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?

No annotations are provided, and the description does not disclose potential side effects, performance implications, or the nature of the analysis. The only behavioral hint is that it processes 'all normalized' pairs, suggesting a bulk operation, but this is minimal and leaves the agent uncertain about reversibility, read-only status, or output structure.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes to identifying the action and scope, making it highly concise.

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?

Despite the presence of an output schema, the description lacks essential contextual information: no parameter semantics, no usage guidance, and no explanation of what 'normalized' means or how this tool differs from related singular/batch tools. The one-parameter optionality and broad sibling set demand more context for safe and correct invocation.

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

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

The schema has one optional parameter 'path' with no description, and the description does not mention it at all. With 0% schema description coverage and no explanation in the description, the agent cannot infer what 'path' refers to (e.g., project path, file path, filter), leaving the parameter meaning completely 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 clearly identifies the action ('Analyze') and the resource ('all normalized project differential pairs'), and the plural form distinguishes it from sibling 'analyze_differential_pair'. However, 'analyze' is somewhat generic and doesn't specify what the analysis entails or what outputs are produced.

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 guidance on when to use this tool versus alternatives like 'analyze_differential_pair' or 'list_differential_pairs'. The phrase 'all normalized project differential pairs' implies a batch operation, but no clear context, prerequisites, or exclusions are provided.

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

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

With no annotations, the description carries the full burden. It discloses a key behavioral trait: distances are always in millimetres, regardless of document units. However, it does not state whether the operation is read-only, what happens if nets are unrouted, or any error behavior. The unit disclosure is useful but leaves other aspects unspecified.

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

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

The description is two sentences, front-loaded with the core purpose and then a valuable unit caveat. Every clause adds information without redundancy, achieving high efficiency.

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 explained. However, the description does not explain the optional parameters (path, tolerance_mm) or their interaction with the tool's behavior. For a tool with three parameters, the description is too sparse to fully support correct invocation without additional assumptions.

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 only references 'nets' indirectly through 'explicit group of nets' and does not explain the meaning or purpose of 'path' or 'tolerance_mm'. The parameter names in the schema are minimally informative, but the description adds no clarity for the optional parameters.

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

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

The description uses a specific verb ('compare') and resource ('routed geometric lengths for an explicit group of nets'), clearly distinguishing it from siblings like measure_net_lengths (which measures individual nets) and analyze_differential_pair (which targets differential pairs). The scope is explicit: the tool operates on a user-specified group of 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 phrase 'for an explicit group of nets' implies when to use this tool (when you have a specific set of nets to compare), but there is no explicit guidance on when not to use it or how it compares to alternatives such as measure_net_lengths or analyze_differential_pair. The context is clear but exclusions are absent.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It adds a key non-obvious detail: all distances are in millimetres regardless of the document's Units attribute. However, it doesn't explicitly state that the tool is read-only/non-destructive (though 'measure' implies it), nor does it reveal any potential limitations or failure modes. The unit disclosure is useful but not comprehensive.

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 extremely concise and front-loaded. Two sentences: the first states the purpose, the second provides a crucial unit detail and points to the schema. No wasted words; every sentence earns its place.

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

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

The tool has an output schema, so return values don't need explanation. However, the description lacks context about when to run this analysis, whether a document must be open, or how it relates to other placement tools. For an analysis tool with 4 parameters, it's minimally adequate but leaves room for clarification.

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 adds meaning to the distance-related parameters (spacing, board_edge_clearance) by stating they are in millimetres. However, it doesn't explain 'path' or 'selector', which remain ambiguous. The reference to the input schema is helpful but not a substitute for semantic explanation.

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

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

The description uses a specific verb and resource: 'Measure current component overlap, containment and placement score.' This clearly states what the tool does. It doesn't explicitly distinguish from sibling tools like 'score_placement' or 'generate_placement_candidates', but the mention of 'overlap, containment, and placement score' gives enough specificity to infer its scope.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention typical use cases, prerequisites, or exclusions. The only contextual hint is 'current', implying analysis of the existing state, but there is no explicit comparison to other placement-related 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?

With no annotations, the description carries the full burden. It does disclose a behavioral limitation ('without claiming final-refill continuity'), which hints that the tool is non-committal about a certain property. However, it does not explain side effects, read/write nature, permissions, or what 'exported pour boundaries' means, leaving significant behavioral ambiguity.

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

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

The description is a single short sentence, making it extremely concise and front-loaded. However, it is so terse that it becomes cryptic, sacrificing clarity for brevity. Still, structure-wise it is efficient with 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?

The tool likely performs a complex PCB analysis, but the description provides almost no context. It does not explain the input path, the nature of the output, or the meaning of 'final-refill continuity'. An output schema exists, so return values are covered, but the overall behavior and use case remain under-specified for a tool with this name.

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

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

The input schema defines a single optional 'path' parameter with no schema description, and the tool description does not mention this parameter at all. With 0% schema coverage and zero compensation from the description, the agent has no idea what 'path' refers to or how to use it.

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 a clear verb ('Inspect') and resource ('exported pour boundaries'), but the qualifier 'without claiming final-refill continuity' muddles the purpose. It is not clear what 'final-refill continuity' means or why this distinction matters, making the tool's exact function ambiguous. It does not explicitly distinguish from sibling tools.

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

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

There is no guidance on when to use this tool versus alternatives. The description only states what it does, not when it should be invoked or what prerequisites exist. No exclusions or alternative tool mentions are provided.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it falls short. It doesn't clarify whether the tool performs read-only analysis or whether it records/imports the XML, whether findings are persisted, or what 'bounded' means operationally. The single 'exported XML' clue hints at the input source but leaves critical behavior untold.

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

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

The description is a single 12-word sentence with zero filler, front-loading the action ('Report') and scoping it clearly. Every token 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 tool with just one optional parameter and an output schema, the description is nearly adequate but leaves gaps on important details: what 'bounded' modifies, the role of the path, and the difference between this and other findings/review tools. It's minimally viable but not comfortably so for an agent deciding between many analysis tools.

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

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

Schema description coverage is 0%, and the lone `path` parameter is not explained in the description. While one might infer that `path` refers to the exported XML location, the description never confirms this, leaving the agent to guess the parameter's purpose, format, and whether it's required for the tool to be meaningful.

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

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

The description uses a specific verb ('Report') with a well-scoped resource ('bounded DFM/DFA/DFT release-readiness findings from exported XML'). It clearly signals this is a findings-reporting tool operating on pre-exported data. However, the word 'bounded' is opaque and there's no explicit differentiation from siblings like get_findings or run_manufacturing_review.

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

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

No guidance is provided on when to use this tool versus the many sibling tools that could overlap (e.g., get_findings, run_manufacturing_review, analyze_placement). There is no mention of prerequisites (e.g., does the XML need to be exported or imported first?) or exclusions, leaving the agent to guess when this tool is the right choice.

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

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

With no annotations provided, the description carries the full burden. The unit note ('All distances are in millimetres, regardless of the document's own Units attribute') is a concrete behavioral detail that goes beyond the schema. However, it doesn't disclose whether the tool is read-only, what side effects exist, or what 'low-confidence' means, leaving important behavior unspecified.

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 long with no fluff. The first sentence states the core action, and the second provides a crucial unit caveat. It is front-loaded and each sentence earns its place. Not a 5 because the first sentence is too vague to be maximally useful, but structurally concise.

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 has 4 parameters, no annotations, and an output schema, the description is quite incomplete. It doesn't explain the context of 'return path' analysis, when to use it, or what the heuristics produce. The output schema exists, so return values need not be detailed, but the purpose and input semantics are too underspecified for reliable invocation.

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

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

Schema coverage is 0%, so the description must compensate. It adds meaning for the required parameter (stitching_radius_mm) by stating distances are in millimetres, but it does not explain the semantics of 'nets', 'path', or 'reference_nets'. The optional parameters remain ambiguous, and their role in the analysis is unclear.

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

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

The description uses a specific verb ('Run') and references 'geometry heuristics', but the resource is vague: 'low-confidence geometry heuristics' does not clarify what 'return path' means or what specific analysis is performed. It doesn't distinguish from sibling analysis tools like analyze_placement or analyze_length_group, but it's not a tautology of the tool 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 guidance on when to use this tool versus alternatives. The only extra statement about units (millimetres) is a unit clarification, not a usage guideline. Without any context for when this heuristics analysis is appropriate, the agent cannot decide between this and sibling analysis 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?

With no annotations provided, the description carries full behavioral disclosure. It clearly states 'without editing' (non-destructive), explains the deterministic congestion ranking, details the clearance resolution logic (maximum of explicit, board defaults, NetClass rules), notes the output includes 'clearance_rule_status' and effective value, emphasizes this is not a full DRC sign-off, and specifies units (millimetres regardless of document Units). This is comprehensive and transparent.

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 concise and well-structured, with three dense sentences. The first sentence states the primary purpose, the second explains clearance resolution and output contents, and the third gives units and a limitation. Every sentence adds value with no redundancy or filler.

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

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

The description covers the main purpose, behavioral rules, output structure, and a key limitation, which is good for a complex analysis tool. However, it lacks parameter semantics, which is a significant gap given the input schema has no descriptions. The presence of an output schema and the tool's non-editing nature partially compensate, but the lack of parameter explanation keeps it from being fully complete.

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

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

Schema description coverage is 0% and the description does not explain the three parameters (path, ordering, connections). It mentions 'explicit requested clearance' which may relate to a field in connections, but provides no explanation of what 'connections' should contain, how 'ordering' works, or what 'path' refers to. The description fails to compensate for the lack of schema descriptions, offering almost no parameter guidance.

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

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

The description clearly states 'Rank route connections by deterministic corridor congestion without editing', a specific verb and resource, and explicitly notes it is non-editing. This distinguishes it from editing tools like 'route_connection' and other analysis tools, making the purpose unmistakable.

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

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

The description implies usage for analyzing and ranking congestion without modification, but it does not explicitly state when to use this tool versus alternative analysis tools (e.g., 'get_route_details' or 'list_unrouted_connections'). It also offers no exclusions or clarifications of when not to use it, leaving usage context inferred 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?

With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states what the tool finds, not how results are returned, what 'complete' means, whether it is read-only, or any side effects. Critical behavioral context is missing.

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

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

The description is a single, focused sentence that front-loads the action and object. It is concise without wasted words, though the brevity borders on under-specification.

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

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

Although an output schema exists, the description lacks essential context about the intended use within an impedance analysis workflow, what qualifies as a 'complete' geometry, and why this tool exists alongside siblings. The description is too sparse to be fully actionable.

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

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

The only parameter 'path' has 0% schema coverage and is not mentioned in the description. The description adds zero semantic meaning for the parameter, leaving the agent with no guidance on what value to provide or how it affects the search.

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

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

The description uses a specific verb ('Find') and resource ('complete outer-layer microstrip geometries in the physical stackup'), making the core action clear. It also implicitly distinguishes itself from sibling impedance tools like calculate_impedance by focusing on geometry discovery rather than calculation. However, the term 'complete' is ambiguous and not defined.

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

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

No guidance is provided about when to use this tool versus alternatives such as analyze_controlled_impedance or suggest_trace_geometry_for_impedance. The description gives no context about prerequisites, workflow positioning, or exclusions.

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

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

With no annotations, the description carries the full burden. It discloses that dry_run=true previews without writing, and that committing requires expected_sha256, which implies a safety check. It does not mention mismatch handling or rollback, but key behavioral traits are covered.

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 no wasted words. The dry_run/expected_sha256 guidance is concise and directly actionable.

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

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

The description covers the main workflow and safety mechanism, and the output schema handles return values. However, it does not explain the txid parameter or the relationship to transaction lifecycle tools like begin_transaction/commit_transaction, leaving some context 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 coverage is 0%, so the description must compensate. It explains dry_run (preview mode) and expected_sha256 (hash from preview), but plan_id and txid are left to inference from names and the transactional context. Partial compensation, not complete.

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

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

The description clearly states the tool stages or commits a stored component-placement plan transactionally. This distinguishes it from siblings like plan_component_placement (which creates plans) and apply_route_plan/apply_silkscreen_plan (which apply other plan types).

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

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

The description provides explicit workflow: use dry_run=true to preview, then set dry_run=false only after inspecting the preview and passing expected_sha256. It lacks explicit when-not-to-use or alternative recommendations, but the workflow is clear and actionable.

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

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

No annotations exist, so the description carries the full burden. It discloses that dry_run=true is non-writing and that expected_sha256 must match after preview, implying a safety check. It lacks details on error behavior, reversibility, or what happens on hash mismatch.

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 main action, and all details are relevant. No fluff or repetition of schema information.

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

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

With an output schema present, return values are likely covered. The description covers the core workflow and safety mechanism but omits behavior on hash mismatch and txid semantics, leaving minor gaps for a 4-parameter mutation 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 description adds meaning to dry_run and expected_sha256 beyond their names, explaining their roles in the preview/commit flow. It does not explain txid, and plan_id is only implicitly referenced, leaving some parameter coverage gaps despite 0% schema 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?

The description clearly states the tool stages or commits a stored local route plan atomically, with a specific verb ('stage or commit') and resource ('stored local route plan'). The dry-run language separates it from sibling route-planning tools, such as plan_route_nets or commit_transaction.

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 provides an explicit two-phase workflow: run with dry_run=true to preview, then inspect and set dry_run=false with expected_sha256. This gives clear context for when to use the tool, though it does not name alternative tools or exclusions.

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

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

With no annotations, the description discloses important behavior: transactional staging/committing, non-destructive preview via dry_run, and checksum verification on commit. This goes beyond simply 'apply the plan' and informs the agent of safety mechanisms.

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 the second sentence adds essential safety guidance. No filler or redundancy.

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

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

The description covers the essential workflow and safety mechanism for applying a plan, and an output schema exists for return values. Missing some context around txid usage, but overall adequate for this 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?

Schema description coverage is 0%, so the description must explain parameters. It clearly explains dry_run and expected_sha256 but leaves plan_id and txid implicit. It partially compensates for the schema gap 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?

The description specifies the exact action ('Stage or commit') and resource ('stored schematic placement-repair plan'), clearly distinguishing it from planning siblings like plan_schematic_placement_repair. The dry_run semantics further clarify the two operational modes.

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: use dry_run=true to preview, and only set dry_run=false after inspecting the preview and providing expected_sha256. However, it doesn't explicitly contrast with similar apply tools like apply_component_placement_plan.

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

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

With no annotations provided, the description carries the full burden and does well: it explicitly states that dry_run=true 'previews without writing' and that dry_run=false commits, implying mutating behavior. It also discloses the safety requirement of passing expected_sha256 after preview, which is valuable behavioral context beyond the schema.

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

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

The description is two sentences, front-loaded with the main purpose and followed by the critical safety workflow. Every sentence earns its place with no redundancy or fluff.

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's complexity and lack of annotations, the description provides the essential workflow (dry-run then commit with hash) and references the stored plan. It could benefit from clarifying txid and how it relates to transaction siblings, but it is sufficient for an agent to invoke correctly in the primary use case.

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. It explains dry_run and expected_sha256 meaningfully, but plan_id is only implied by 'stored silkscreen plan' and txid is not explained at all. This is partial compensation for a 4-parameter schema.

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

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

The description states a specific action ('Stage or commit a stored silkscreen plan') on a clear resource, and distinguishes it from sibling planning tools by emphasizing the transaction and dry-run/commit workflow. This makes the tool's role unambiguous.

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

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

The description gives a clear usage workflow: start with dry_run=true to preview, then set dry_run=false and provide expected_sha256 after inspecting the preview. It does not explicitly name alternatives or exclusions, but the workflow context is strong enough to guide correct invocation.

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

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

With no annotations, the description carries the full burden. It discloses key behavioral traits: dry_run previews without writing, the write operation uses SHA/match guards and creates a backup, and the expected_sha256 must be passed after preview. This is valuable actionable safety context, though it does not detail failure modes or the exact nature of the 'bounded diff resource'.

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 only two sentences, so it is concise. However, the first sentence is dense and cryptic, using jargon like 'bounded diff resource' without explanation. It could be more transparent while remaining brief.

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

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

The description covers the safe application workflow (dry-run then commit) but does not explain what a 'bounded diff resource' is, what the edits do, or any prerequisites. Given the complexity of the edits array and the presence of an output schema, more context would be helpful. It is minimally complete.

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

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

Schema description coverage is 0%, so the description must compensate. It explains dry_run and expected_sha256 well, clarifying their roles and relationship. However, it does not elaborate on 'path' or 'edits', which are left to the schema's inherent names. This partial coverage earns a middle score.

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 does not clearly state that the tool applies XML edits to a document. It uses vague language like 'Store a bounded diff resource' and 'write with its SHA/match guards and a backup', which obscures the primary function. The tool name 'apply_xml_edits' carries the meaning, but the description itself lacks a specific verb+resource statement.

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

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

The description provides a clear usage workflow: start with dry_run=true to preview, then set dry_run=false only after inspecting the preview and passing the expected_sha256. This gives the agent explicit instructions on safe invocation. However, it does not mention when to use this tool over alternatives or any exclusion criteria.

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

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

With no annotations provided, the description carries the burden of disclosing side effects. It explicitly states that all distances are in millimetres regardless of document units, a non-obvious unit quirk, and that dry_run=true previews without writing, while false requires expected_sha256. This gives a clear safety workflow, though it does not mention failure modes or what happens if the class doesn't 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?

The description is front-loaded with purpose and keeps the safety workflow concise. However, the sentence 'Input schema: diptrace://schemas/tool-inputs' is redundant since the input schema is already provided, and it adds no value for the agent. This wastes a sentence without earning 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 mutation tool with no annotations, the description covers core behavior (assignment, unit quirk, dry-run workflow) but leaves gaps: no guidance on when to use it vs. alternatives, no explanation of path/txid/selector semantics, and no side-effect detail beyond 'assign.' The output schema may cover return values, but overall completeness is adequate but not thorough.

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

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

Schema description coverage is 0%, so the description must compensate. It explains dry_run and expected_sha256, and 'selected nets' implies the selector, but it says nothing about path, txid, or class_name beyond the obvious name. Given 6 parameters and no schema descriptions, this is only partial compensation.

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

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

The description opens with 'Assign selected PCB or schematic nets to an existing net class,' which clearly identifies the action (assign), the resource (nets), and the destination (existing net class). This distinguishes it from sibling tools like rename_net or update_net_class_rules, which address different operations.

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 states the operation and provides a workflow: use dry_run=true first, inspect preview, then set dry_run=false with expected_sha256. It does not explicitly name alternatives or exclusions, but the context of 'existing net class' implies a contrast with class creation or rule updates, making usage reasonably clear.

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

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

No annotations are provided, so the description carries the full burden. It states only what the tool creates, but does not disclose side effects (e.g., invalidating an existing transaction), state prerequisites, concurrency limitations, or what happens to prior snapshots. This leaves the agent without behavioral expectations.

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 concise sentence that front-loads the verb and object, with no filler words or redundant information. Every word adds meaning.

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

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

The tool belongs to a transaction workflow (siblings include preview/validate/commit/rollback) and has three parameters plus an output schema, yet the description provides no context about workflow ordering, required state, or parameter semantics. The agent is left with insufficient information to use it correctly.

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

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

The schema has three optional parameters (path, notes, expected_sha256) with 0% description coverage, and the tool description does not explain their meaning or expected format. An agent cannot determine correct values or why they are needed.

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

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

The description uses a specific verb 'create' with a clear object 'transaction snapshot' and scopes it 'for a document or live session.' This clearly differentiates it from sibling tools like commit_transaction or rollback_transaction.

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

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

The description provides no guidance on when to start a transaction, how it relates to preview/validate/commit/rollback, or any preconditions. The phrase 'for a document or live session' hints at scope but does not explain when to use this tool versus 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?

The description discloses an important behavioral trait: all distances are in millimetres regardless of the document's Units attribute. This is beyond what the schema or annotations (none provided) convey. However, 'explicit assumptions' is vague and does not detail the analytical model or limitations, so it is not a perfect disclosure.

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

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

The description is two sentences with no filler. The key unit rule is front-loaded in the second sentence, and every word contributes to purpose or behavioral context.

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

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

The tool has 9 parameters and an output schema, but the description provides only the core purpose and the unit rule. It lacks usage guidance and parameter semantics, which are partly mitigated by self-explanatory parameter names and the presence of an output schema. Still, the description is adequate for a simple calculation but not comprehensive.

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 should compensate by explaining parameters. It only mentions units, which is already implied by the '_mm' suffix on many parameter names. There is no explanation of optional parameters like target_ohm, tolerance_ohm, or frequency_hz, or how structure enum values differ.

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

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

The description clearly states a specific action ('Calculate') and a resource ('impedance'), with a modifier 'preliminary analytical' that sets expectations. It does not explicitly distinguish from sibling tools like analyze_controlled_impedance, but the name and phrasing make the primary purpose evident.

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

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

The description gives no guidance on when to use this tool versus alternatives such as suggest_trace_geometry_for_impedance or analyze_differential_pair. There is no mention of preferred scenarios, exclusions, or prerequisites, leaving the agent to infer usage from 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?

With no annotations, the description must disclose safety and side effects. It only says 'request cancellation,' which suggests an asynchronous request but does not explain whether the job is forcibly killed, whether results are retained, or any reversibility. This leaves significant ambiguity.

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

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

The description is a single, focused sentence that gets straight to the point. It earns its place with no redundancy.

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

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

For a mutation-like operation with no annotations and no parameter details, one sentence is too sparse. Even though an output schema exists, the tool's effects and preconditions are unexplained, making it incomplete in 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 description provides zero information about the jobid parameter beyond what the schema already states (a required string). With 0% schema description coverage, the description should explain how to find or format the jobid, but it does not.

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

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

The description clearly states the action (request cancellation) and the target resource (a running external job). It distinguishes from sibling job-related tools like get_job_status and get_job_result, which are read-only.

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 for running external jobs but provides no guidance on when to use versus alternatives, no prerequisites (e.g., how to obtain jobid), and no when-not-to-use conditions. This is insufficient guidance.

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

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

There are no annotations, and the description adds no behavioral context. The alias note reveals nothing about side effects, return values, permissions, or what the check actually does.

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 extremely short but this is under-specification rather than conciseness. It fails to earn its place as it conveys zero useful information beyond the tool name.

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 check-type tool with no annotations, no output schema details, and a single undocumented parameter, the description is completely inadequate. It lacks all necessary context for an agent to understand the tool's purpose or behavior.

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

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

Schema description coverage is 0%, and the description does not mention the 'path' parameter at all. The agent receives no semantic guidance for the single optional parameter, making correct invocation impossible.

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 is only 'Alias: run_silkscreen_check.' It does not state any verb, resource, or action, merely referencing an alias. This is a tautology that provides no functional meaning beyond the tool's 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?

No guidance is provided on when to use this tool versus alternatives. Sibling tools such as run_manufacturing_review, run_assembly_review, and run_silkscreen_check itself are not differentiated, leaving the agent without any basis for selection.

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

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

No annotations are provided, so the description carries the full burden. It discloses that dry_run=true previews without writing and that dry_run=false requires an expected_sha256 from the preview, which is a meaningful safety protocol for a destructive operation. It does not elaborate on the effect of txid or what exactly 'remove panelization settings' entails, but the safety mechanism is well explained.

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: the first states the purpose, the second explains the safe execution workflow. Every word earns its place, and the description is entirely front-loaded.

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

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

The description covers the core usage pattern well with the dry_run workflow, and an output schema exists to describe return values. However, it omits the meaning of path and txid, and does not discuss transaction context despite a txid parameter, leaving some gaps for an agent 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%, so the description must compensate. It explains the roles of dry_run and expected_sha256 and their relationship, but path and txid are not mentioned. This leaves those parameter semantics entirely to the schema, which lacks descriptions, 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 uses a specific verb 'Remove' and identifies the resource 'panelization settings' from a 'PCB document', clearly distinguishing from the sibling tool set_panelization. It leaves no ambiguity about the tool's primary function.

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

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

The description provides clear context on the two-step process: first run with dry_run=true to preview, then set dry_run=false only after inspecting the preview and providing the expected_sha256. It does not explicitly name alternatives, but the purpose itself differentiates it from set_panelization, so the guidance is clear but not exhaustive.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. 'Commit' strongly implies an irreversible finalization, but the description does not state whether the operation is destructive, locks resources, requires special permissions, or what side effects occur. This leaves significant behavioral ambiguity 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?

The description is a single, concise sentence that front-loads the primary action and condition. It contains no redundant words or filler, making it easy for an agent to parse quickly.

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 complexity of a transaction lifecycle (evidenced by siblings like stage_operations, preview_transaction, validate_transaction, rollback_transaction), the description provides insufficient context. It does not explain the relationship to staging, the effects on staged operations, or what the output schema represents. The agent is left without a clear mental model of how commit_transaction fits into the overall workflow.

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 input schema's bare parameters. The mention of 'source SHA-256' gives some meaning to expected_sha256, but txid is entirely unexplained. The description adds only partial clarity to one parameter and leaves the other undefined, which is insufficient for a 2-parameter tool.

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

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

The description clearly states the action: 'Commit a staged transaction' with a verb and resource. It also adds a specific condition 'after verifying the source SHA-256', which distinguishes this from related operations like begin_transaction, preview_transaction, validate_transaction, and rollback_transaction.

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 'after verifying the source SHA-256' implies a prerequisite and suggests a sequencing relative to verification steps, but it does not explicitly mention alternatives or exclusions. There is no direct guidance on when to prefer commit_transaction over preview_transaction or validate_transaction, though the wording implies it is the finalizing step in a transaction 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?

No annotations are provided, and the description only states that a comparison is performed. It does not disclose whether the operation is read-only, what happens for mismatches, what the output contains, or any side effects. The RefDes matching detail adds a bit of behavioral context but is insufficient.

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 immediately states the action and scope. It contains no filler or redundant repetition of the tool name, making it concise and well-structured.

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

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

Given that the tool involves a nested external_records structure and an optional path, the description is too sparse. It doesn't clarify the role of path, the expected shape of external records beyond 'typed', or how matching discrepancies are reported. The output schema reduces some burden, but the tool's context is still incomplete.

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

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

The description adds meaning to external_records by calling them 'typed external BOM rows' and mentions RefDes as the join key, but it does not explain the optional path parameter at all. With schema description coverage at 0%, the description should carry more weight but leaves parameter semantics largely to the schema.

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

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

The description uses a specific verb ('Compare') and identifies both operand types ('typed external BOM rows' and 'normalized design records') plus the matching key ('by RefDes'). This clearly distinguishes it from BOM-related siblings like get_bom or review_bom.

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 explicit guidance is given about when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or related tools such as compare_schematic_to_pcb or validate_mpn_consistency, leaving usage context entirely 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Rank' implies a read-only analysis, but the description does not explicitly say whether it modifies the design, whether it runs physics simulations, what input state is required, or what the output represents. It adds only a hint about physics and sourced rules.

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

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

The description is a single, compact sentence with no filler or repetition. It is front-loaded and easy to scan, though the ambiguity of 'A-D candidates' and the vague term 'physics' reduce clarity slightly. It is concise but perhaps too terse for the tool's complexity.

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 complexity of the engineering_rules nested object, four optional parameters, and no annotations, the description is incomplete. It does not clarify how candidates are supplied, what the profiles do, how include_existing_board affects ranking, or what the output schema contains. The output schema exists, so return values do not need explanation, but too much operational context 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 compensate for undocumented parameters. 'Optional sourced rules' hints at engineering_rules, but path, profiles, and include_existing_board are not explained at all. The description adds minimal meaning beyond the raw schema and is insufficient for a 4-parameter tool.

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

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

The description clearly states the core action: rank PCB placement candidates using physics and optional engineering rules. It distinguishes the PCB focus from the sibling rank_schematic_placement_candidates, but does not explicitly differentiate from score_placement or explain what 'A-D candidates' means, leaving some ambiguity.

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

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

Usage is implied: you call this when you have PCB placement candidates that need ranking with physics and optionally sourced rules. However, it does not state when to prefer it over alternatives like score_placement, generate_placement_candidates, or rank_schematic_placement_candidates, nor does it mention any exclusions or 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?

No annotations are provided, so the description must disclose behavioral traits on its own. It only lists what is compared but does not mention whether this is a read-only operation, what the output format is, whether it reports only mismatches or full data, or if any prior setup is needed. This is a significant gap for a comparison 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?

The description is a single focused sentence that gets straight to the point, using an active verb and specific comparison targets. There is no redundancy or filler; however, its brevity leaves out important usage and behavioral context, though that is more of a completeness concern.

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

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

The tool is relatively complex (multi-file comparison with multiple comparison dimensions), and while an output schema exists, the description gives no context on prerequisites, return behavior, or how it fits into the overall design review workflow. With 2 required parameters and no explanation, the description feels incomplete for effective tool selection and invocation.

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

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

Schema description coverage is 0% and the description does not elaborate on the two required path parameters. The names schematic_path and pcb_path are self-explanatory to a degree, but the description adds no detail about expected formats, file types, or relationships. It fails to compensate for the lack of schema descriptions.

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

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

The description clearly states the tool compares specific attributes (RefDes, values, net names, pin/pad sets) between schematic and PCB. The verb 'Compare' is specific and distinguishes it from sibling comparison tools like compare_bom_to_design which focuses on BOM items rather than these electrical/net attributes.

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

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

The description implies the tool is used for comparing schematic and PCB on specific electrical attributes, but provides no explicit guidance on when to choose this over alternatives like validate_pin_pad_mapping or compare_bom_to_design. No exclusions or precondition details 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?

With no annotations, the description carries the full burden. It discloses important behavioral traits: net creation when missing, dry_run preview mode, and the requirement for expected_sha256 after preview. This goes beyond what the schema conveys. However, it does not explain the behavior of allow_reconnect, whether existing connections are disturbed, 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 sentences, front-loaded with the core function and side effect. The safety workflow is stated compactly with code formatting. Every sentence earns its place with no redundant content.

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

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

The tool has 7 parameters, no annotations, and an output schema. The description gives the essential purpose and a critical safety workflow, which is sufficient for basic correct invocation. However, given the complexity, the unaddressed parameters (especially allow_reconnect) leave some gaps that the agent must infer from schema defaults alone.

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

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

Schema description coverage is 0%. The description adds semantics for dry_run and expected_sha256 but does not explain net, pins, path, txid, or allow_reconnect. While net and pins are inferable from the verb, allow_reconnect remains ambiguous. The description compensates for only a fraction of the parameter space.

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

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

The description clearly states the action: 'Connect part pins to a net; the net is created when missing.' This is a specific verb+resource that distinguishes it from similar tools like disconnect_pins or set_pin_no_connect. It also notes the side effect of net creation, leaving no ambiguity about the tool's function.

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

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

The description provides clear usage context: it is for connecting pins to nets, with the net auto-created if absent. It also gives a safety workflow ('dry_run=true previews without writing; set dry_run=false only after inspecting the preview and pass its expected_sha256'), which guides the agent on how to invoke it safely. However, it does not explicitly name alternatives or specify when not to use 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?

With no annotations, the description carries the full transparency burden. It discloses key behaviors: preserving unknown XML, deriving validation from a verified provenance sidecar, falling back to 'synthetic_parser_only' without one, and requiring the target's current SHA to overwrite. This goes beyond the name and input schema, though it omits details about reversibility or permissions.

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 three sentences that front-load the purpose in the first sentence, then add essential caveats about validation, seed preference, and overwrite requirements. Every sentence earns its place, with 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?

The description covers the core purpose and important caveats (unknown XML preservation, validation dependency, overwrite SHA requirement), which is good for a tool with this complexity. However, it leaves the mapping of concepts like 'provenance sidecar' and 'current SHA' to specific parameters unclear, and the absence of explicit when-to-use guidance relative to sibling creation tools is a gap. The output schema presumably covers return values, so that is not a deficiency.

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 references a 'provenance sidecar' and 'current SHA' without mapping them to expected_seed_sha256 and expected_sha256. It also does not explicitly explain seed_path or target_path. The description's jargon adds ambiguity rather than clarifying the five parameters.

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

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

The description opens with a specific verb+resource: 'Copy a valid DipTrace-shaped XML seed while preserving unknown XML.' This clearly states the tool's function and distinguishes it from sibling creation tools like create_schematic_document or create_pcb_document, which likely create new documents rather than copy a seed.

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

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

The description provides a clear preference: 'Prefer a real export seed when DipTrace compatibility matters,' which guides when to use this tool vs synthetic alternatives. It also warns that replacing an existing target requires its current SHA, giving a precondition. It does not name specific sibling alternatives, but the context is clear enough.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses that the content is synthetic, has correct XML structure but is NOT verified by DipTrace open/save, and that distances are always in millimetres regardless of the document's Units attribute. This is substantial transparency, though it could further clarify behavior when overwrite=false or when the target already exists without a SHA.

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

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

The description is two short paragraphs with no fluff. The first sentence states the purpose; the second paragraph delivers critical caveats and usage guidance. Every sentence earns its place, making it concise and well-structured.

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

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

Given the tool's complexity (6 params, no annotations, output schema exists), the description covers key caveats: synthetic nature, compatibility warning, alternative tool, SHA requirement, and unit behavior. It does not explain return values, but the output schema covers that. It could detail the pcb scaffold more, but overall it provides enough context for an AI agent to use the tool safely.

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

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

Schema description coverage is low (17%), so the description must compensate. It adds meaning for units (all distances in mm) and expected_sha256 (required for replacing an existing target). However, it does not explain the pcb scaffold structure or the format_version semantics beyond what the schema already provides. The reference to the input schema helps, but the added parameter-level guidance 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: 'Create a new DipTrace PCB XML document (outline, layers, stackup, rules)' and clearly distinguishes this from siblings like create_schematic_document (PCB vs schematic) and create_document_from_seed (synthetic vs seed-based). This leaves no ambiguity about what the tool does.

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

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

The description explicitly names an alternative: 'Use create_document_from_seed with a real DipTrace export when DipTrace compatibility is required.' It also provides important usage context for overwriting: 'Replacing an existing target requires its current SHA.' This is clear when-to-use and when-not-to-use guidance.

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

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

With no annotations, the description carries the burden of disclosing behavior. It explicitly states the output is synthetic and not verified, and that overwriting requires a current SHA—critical behavioral context beyond the schema. However, it does not mention what happens if the target exists without overwrite, nor the return format, though an output schema exists.

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

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

The description is a single, front-loaded sentence that wastes no words. It clearly states the core purpose first, then adds the essential overwrite prerequisite. Every element earns its place.

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

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

The tool has 6 parameters and no annotations, making the description the primary source of guidance. It does not explain the semantics of units, sheets, or path, nor error conditions when overwrite is false and the file exists. The output schema covers return values, but the description is too sparse for the tool's 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?

Schema description coverage is only 17%, so the description must compensate. It adds crucial meaning for overwrite and expected_sha256 ('overwrite needs current SHA'), but it fails to explain units, sheets, format_version, or path. The schema already documents format_version and expected_sha256, so the description adds only marginal value for most parameters.

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

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

The description clearly states a specific verb and resource: 'Create synthetic, not DipTrace-verified Schematic XML.' It distinguishes this tool from create_pcb_document and other generation tools by explicitly noting the synthetic, unverified nature. The overwrite note adds further specificity.

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 a clear prerequisite for overwrite scenarios: 'overwrite needs current SHA.' However, it does not explicitly state when to use this tool over alternatives or when not to use it, such as when a DipTrace-verified schematic is required. The context is partial but not fully framed.

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

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

With no annotations, the description carries the full burden and does well: it discloses that deletion may cause connectivity regression, that distances are always in millimeters, and that dry_run previews without writing. It also explains the expected_sha256 handshake. It does not mention undo/transaction behavior or auth, but the disclosed safety semantics are substantial.

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 sentences cover purpose, units, and a safe invocation workflow with no filler. Information is front-loaded and every sentence adds meaningful guidance.

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

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

The description covers the critical safety workflow and units, and an output schema exists so return values need not be described. However, given the tool's complexity and the absence of annotations, the lack of detail about the selector object and transaction-related parameters prevents this from being fully complete. It is adequate but leaves clear gaps.

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

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

Schema coverage is 0% and the description compensates only partially. It explains dry_run, expected_sha256, and allow_connectivity_regression indirectly, but says nothing about the required selector field or the optional path/txid parameters. The selector is a required nested object and is left entirely unexplained, which is a significant gap for a destructive tool.

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

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

The description opens with 'Delete selected traces', which is a specific verb+resource combination that clearly distinguishes this tool from siblings like delete_wire and delete_via. It also adds the important scope qualifier about connectivity regression requiring opt-in.

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

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

The description provides clear workflow guidance: use dry_run=true to preview, then set dry_run=false only after inspecting the preview and passing expected_sha256. It does not explicitly name alternatives or exclusion criteria, but the dry-run/opt-in context effectively tells the agent when and how to invoke safely.

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

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

No annotations exist, so the description carries the burden. It discloses key behavioral traits: distances are always in millimetres regardless of document units, and the dry-run + expected_sha256 safety mechanism prevents unintended writes. This goes beyond what the schema provides, though it does not mention permissions, rollback, or transaction requirements.

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 concise and front-loaded with the core action. The sentence 'Input schema: diptrace://schemas/tool-inputs' is redundant with the provided input schema and adds no value, slightly reducing efficiency. Otherwise, it is well-structured and readable.

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

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

The description covers the essential safety workflow (dry-run, expected_sha256) and units, but it lacks guidance on transaction context (e.g., whether to use inside a transaction) and does not explain the nested selector object. Given the tool's destructive nature and complexity, the absence of these details makes it incomplete. The output schema exists but does not replace operational 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?

Schema description coverage is 0%, and the description does not explain critical parameters like selector, path, txid, or expected_sha256. It implies the roles of dry_run and expected_sha256 through behavioral guidance, but leaves 5 parameters' semantics largely to the schema. The 'all distances in millimetres' note touches selector geometry but does not compensate for the overall 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 uses a specific verb+resource: 'Remove ViaStyle from selected trace points.' It clearly distinguishes this tool from siblings like add_via, move_via, and set_via_style by focusing on removing an aspect of vias. No ambiguity.

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

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

The description provides clear operational guidance: 'dry_run=true previews without writing. Set dry_run=false only after inspecting the preview and pass its expected_sha256.' This tells when to use the tool and the required safety workflow. It does not explicitly compare with alternatives, but the context is sufficient.

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

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

With no annotations, the description fully covers the safety profile: it preserves net connectivity, always uses millimeters regardless of document units, and details the dry_run and expected_sha256 mechanism. This is model transparency for a destructive operation.

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 three concise sentences with purpose front-loaded. Every sentence carries essential information: scope, unit behavior, and the confirmation workflow. 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 destructive tool with an output schema, the description covers the essential protocol and unit caveat. Minor omissions like txid and path semantics are acceptable given the focus on safety and the presence of an output schema.

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%, but the description explains dry_run and expected_sha256 in actionable terms. It does not explain path, txid, or selector structure, but the most critical safety parameters are well documented.

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

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

The description states a specific action ('Delete selected schematic wires') and a key constraint ('without touching net connectivity'), clearly distinguishing it from PCB trace deletion tools like delete_trace. 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 provides a clear safety workflow: use dry_run=true to preview, then set dry_run=false only after inspecting the preview and passing expected_sha256. It implies when not to use (only after preview), but does not explicitly name alternative tools or state when to prefer them.

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

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

No annotations are provided, so the description carries the burden. The verb 'List' clearly implies a read-only operation and the description specifies the output (identity groups with multiple RefDes). However, it omits details about the meaning of 'path', error behavior, or any prerequisites, leaving some behavioral aspects undisclosed.

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

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

The description is a single concise sentence that is direct and free of fluff. It front-loads the verb and object, making the core purpose immediately visible.

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?

Despite having an output schema, the description is incomplete for effective tool selection and invocation. It lacks parameter semantics, usage guidelines, and behavioral context, making it difficult for an agent to know when and how to use this 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?

The schema defines one optional 'path' parameter with no description, and the tool description does not mention it at all. With 0% schema description coverage, the description fails to compensate, leaving the agent without any clues about what 'path' refers to.

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

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

The description uses a specific verb 'List' and identifies the resource as 'identical BOM identity groups containing multiple RefDes', clearly indicating detection of duplicate BOM entries. It is distinguishable from sibling BOM tools by focusing on duplicate detection, though the terminology is somewhat specialized.

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

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

The description provides no guidance on when to use this tool over alternatives like review_bom or run_bom_review. It only states the action, without conditions, prerequisites, or exclusions.

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

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

With no annotations provided, the description carries the burden of conveying behavior. 'Show' implies a non-mutating read operation, and the phrase 'if any' correctly warns that an active session may not exist. However, it does not mention error cases, output format, or whether any server-side state is touched, leaving some ambiguity.

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

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

The description is a single, clear sentence that states exactly what the tool returns. Every word earns its place, with no fluff 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?

This is a simple, parameterless status tool with an output schema available. The description covers both return subjects (server paths and bridge session) and sufficiently frames the tool's purpose; the output schema can handle detailed return value documentation.

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

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

The tool has zero parameters, so the baseline is 4. There is nothing to explain beyond the empty schema, and the description correctly avoids inventing parameter details.

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

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

The description uses a specific verb ('Show') and identifies two distinct resources: server paths and the active DipTrace bridge session. This unambiguously distinguishes it from sibling status-like tools such as get_job_status or get_capabilities, which cover different subjects.

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 explicit guidance is given about when to use this tool versus alternatives. It is implied that one calls this to inspect server paths or the active bridge session, but there are no usage scenarios, prerequisites, or notes about when another status tool would be more appropriate.

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

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

With no annotations provided, the description carries the full burden of disclosing behavioral traits. It clearly indicates that `dry_run=true` does not write and that setting it to false performs a write, and it highlights the millimetre unit behavior. While it omits details like reversibility or transaction requirements, it gives crucial preview-and-commit guidance 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?

The description is concise and front-loaded, with the main purpose in the first sentence and the dry-run workflow in the final sentence. However, the line 'Input schema: diptrace://schemas/tool-inputs' is somewhat redundant because the schema is already provided in the input-schema block, slightly reducing efficiency.

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

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

The description covers the core workflow and unit caveat, but given the tool's complexity and the presence of a transaction-oriented sibling set (begin_transaction, commit_transaction, etc.), it does not mention whether this operation requires an active live session or should be wrapped in a transaction. The selector parameter is also not elaborated, leaving a completeness gap despite the output schema.

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

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

The schema has 0% description coverage, so the description must compensate. It explains `dry_run` and `expected_sha256` in prose, but does not clarify the meanings or formats of `path`, `txid`, or `selector` beyond the hint 'selected pins'. The mention of 'selected schematic pins' implicitly references the selector but leaves its structure unspecified.

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

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

The description opens with a specific verb and resource: 'Disconnect selected schematic pins from their nets.' This clearly identifies the tool's action and differentiates it from siblings like connect_pins, which perform the opposite operation.

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

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

The description provides clear usage context by detailing the safe workflow: use `dry_run=true` to preview, then set `dry_run=false` only after inspecting the preview and providing the expected SHA-256. However, it does not explicitly state when to use this tool versus alternatives or mention any prerequisites or exclusions.

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

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

With no annotations present, the description carries the full burden of behavioral disclosure. It explicitly reveals that operations are transactional, that all distances are in millimetres regardless of document units, and that commit requires inspecting the preview and passing expected_sha256. This is substantial safety-relevant behavior beyond what the schema alone conveys.

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 three sentences long, front-loads the core purpose, and each sentence contributes distinct information (what, unit guarantee, safety protocol). 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?

Given the tool's complexity (9 params, nested objects) and low schema coverage, the description provides a good safety workflow and key constraints, but it omits crucial parameter semantics (selector format, axis meaning, mode differences, spacing value interpretation). An output schema exists, but the input-side gaps make it only partially complete.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning for dry_run and expected_sha256 (preview-then-commit workflow) and clarifies units for spacing. However, it does not explain selector, axis, mode, spacing, path, txid, or allow_locked, leaving significant gaps for a 9-parameter tool.

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

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

The description clearly states a specific verb ('Distribute') and resource ('PCB components') with a scope constraint ('at least three') and a distinctive trait ('transactionally'). This distinguishes it from sibling tools like move_components or align_components.

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

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

The description provides clear context for when to use this tool (distributing components) and includes a safety protocol (preview with dry_run, then commit with expected_sha256). It does not explicitly name alternatives or exclusion conditions, so it misses the top tier, but the usage context is distinctly 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?

With no annotations provided, the description must carry the full behavioral burden. It does disclose a meaningful behavioral trait: 'vendor-native requests fail explicitly'. However, it does not mention output format, file system side effects, required session state, or other potential behavioral implications, leaving significant gaps.

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

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

The description is a single, front-loaded sentence with no filler. Both clauses provide distinct information: the purpose and the failure behavior. It is concise and easy to scan.

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?

Despite having an output schema, the tool has three optional parameters and sits among many similar export/session tools. The description does not explain parameter semantics, differentiate from export_fabrication_outputs or export_bom, or provide usage context such as whether a session or transaction is required. This is too sparse for reliable tool selection.

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 should compensate for the three parameters. It only faintly hints at 'request_native_outputs' through 'vendor-native requests', but says nothing about 'path' or 'include_dnp'. The description adds almost no value beyond the raw schema.

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

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

The description uses the specific verb 'Export' and identifies the resource as 'generic BOM/placement artifacts', which clearly states what the tool does. It also distinguishes this tool from vendor-native or fabrication-specific export tools by noting that vendor-native requests fail explicitly, setting it apart from siblings like export_fabrication_outputs.

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

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

The description implies the tool is for generic outputs and that vendor-native requests should not be used, but it does not explicitly name alternatives or provide when-to-use/when-not-to-use criteria. The guidance is present only by implication, not as clear direction.

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

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only mentions a precondition ('when exact footprint geometry is available') and the artifact type, but does not state whether the operation is read-only, what happens if geometry is unavailable, or any side effects. The term 'bounded' is ambiguous and unexplained.

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

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

The description is a single, front-loaded sentence with no wasted words. It is concise and to the point, but the use of jargon like 'bounded Specctra DSN artifact' may require additional clarity. Nonetheless, it is appropriately sized for a short description, though not as minimal as a tautology.

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 has 2 optional parameters, no annotations, and only a brief description, context is insufficient. The description does not explain what 'bounded' means, what the parameters do, or how this relates to other autorouter tools. The presence of an output schema helps with return values, but not with usage context or parameter semantics.

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 lack of parameter documentation. It mentions neither 'path' nor 'design_name', leaving both optional parameters entirely unexplained. This is a complete failure to add semantic value beyond the bare schema.

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

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

The description clearly states a specific verb ('Export') and a specific resource ('bounded Specctra DSN artifact'). This distinguishes it from sibling export tools like export_bom or export_fabrication_outputs, and even from related autorouter tools. The condition 'when exact footprint geometry is available' adds further specificity.

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 'when exact footprint geometry is available' provides a clear context for when to use this tool. However, it does not explicitly mention alternatives or when not to use it, so it lacks exclusions. No sibling tool is referenced as an alternative.

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

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

With no annotations provided, the description must carry the full burden of behavioral disclosure. It mentions exporting to CSV and a manifest, but does not state side effects, whether files are written, output format details, or any access requirements. The term 'bounded resources' is unclear and under-explained.

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

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

The description is a single sentence with no wasted words, but it is under-specified. The vague 'bounded resources' phrase reduces clarity, making it less effective than a fully self-contained concise description.

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

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

Although an output schema exists and the tool has few parameters, the description lacks usage guidance and parameter semantics. Given the large sibling set, it should better locate this tool within the BOM export workflow, but it remains thin.

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

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

Schema description coverage is 0%, and the description does not mention either parameter ('path' or 'include_dnp'). The schema provides titles and defaults, but the description adds no semantic meaning over the structured fields, failing to compensate for the coverage gap.

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

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

The description clearly states the verb 'Export' and the resource ('generic UTF-8 CSV BOM and provenance manifest'), distinguishing it from sibling tools like get_bom and export_fabrication_outputs. The phrase 'bounded resources' is somewhat vague but does not obscure the main purpose.

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 guidance on when to use this tool versus alternatives like get_bom or export_fabrication_outputs. The description implies an export use case but provides no exclusions, prerequisites, or context for selection.

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

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

With no annotations, the description must disclose behaviors. It does state that native Gerber/drill requests fail explicitly, which is a useful behavioral trait. However, it omits other important details like file output, permissions, or side effects, leaving the agent under-informed.

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

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

The description is a single, tightly-written sentence that front-loads the primary purpose and adds a key caveat. Every word contributes value.

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

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

Given three parameters and no annotations, the description is too sparse. It does not explain what a 'release-review manifest' contains, what the parameters control, or what the output schema returns. The tool is not fully contextualized within the broader toolset.

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

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

Schema description coverage is 0%, and the description does not mention any of the three parameters (path, include_dnp, request_native_outputs). It fails to compensate for the lack of schema descriptions, leaving parameter semantics entirely unexplained.

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

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

The description specifies a clear action ('Export') and object ('a release-review manifest'), and explicitly notes that native Gerber/drill requests fail, distinguishing this from other export tools like export_assembly_outputs. The scope is well-defined.

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 for exporting release-review manifests and warns against native Gerber/drill requests, but it does not name alternative tools or provide explicit when-to-use guidance. Context is sufficient for basic selection but not comprehensive.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without revealing the return format, side effects, permissions, or whether any modifications occur. The verb 'find' implies a read-only operation, but this is not explicitly stated, and the description does not add value beyond what an agent might infer from the tool name.

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

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

The description is a single short sentence, which is economical and front-loaded. However, it omits critical information about parameters and usage, making it more under-specified than appropriately concise. It is not as degenerate as 'Process,' but it fails to earn its place by leaving the agent with unresolved questions.

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 has two parameters, an output schema (though not shown), and no annotations, the description is incomplete. It does not address how path filtering interacts with required_fields, what constitutes a 'missing' field, or the structure of the results. The agent is left with only a vague sense of the tool's full behavior and return contract.

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

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

The input schema defines two parameters (path and required_fields) but includes no per-parameter descriptions. The tool description does not explain the meaning of 'path' or the expected format/contents of 'required_fields,' resulting in 0% schema_description_coverage with no compensating detail. An agent cannot reliably construct the correct argument values from the given information.

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

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

The description uses the specific verb 'Find' and identifies the resource as 'components' with the scope 'missing explicit required BOM fields.' This clearly states what the tool does and distinguishes it from write or review tools. However, it does not explicitly mention sibling tools or alternative BOM review functions, so it lacks the explicit differentiation expected for a perfect score.

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

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

The description provides no guidance on when to use this tool versus related siblings such as run_bom_review, compare_bom_to_design, or validate_mpn_consistency. There is no mention of prerequisites, exclusions, or complementary tools, leaving the agent without context for correct tool selection.

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