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

With no annotations, the description fully discloses behaviors: it follows hierarchical sheets recursively, skips missing files with warnings, excludes power symbols and #-references, and returns specific BOM fields. This goes well beyond basic operation and covers edge cases.

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 well-structured and front-loaded: it opens with the core function and output fields, then explains behaviors. Each sentence provides distinct value, with no filler or 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?

Even without annotations or an output schema, the description explains inputs, output fields, hierarchical sheet recursion, exclusions, and a follow-up tool. It is sufficiently complete for an agent to select and invoke 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 already provides a 100% description of the single 'path' parameter, so the baseline is 3. The description adds a helpful version constraint ('KiCad 6-9') but otherwise repeats the schema's file type and path handling without substantial new meaning.

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

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

The description states a clear action ('Parse') and a specific resource ('a KiCad schematic or BOM CSV'), with detailed output fields. It explicitly distinguishes itself from the sibling tool by saying 'Run this first... then pass the same path to suggest_bom_parts.'

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 usage guidance: 'Run this first to understand a design, then pass the same path to suggest_bom_parts for part suggestions.' This names an alternative (suggest_bom_parts) and when to use this tool vs. that one.

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 takes on the full disclosure burden. It clearly explains the fee structure ($3 per unique extended-tier part; no fee for basic/preferred parts) and the quantity calculation (qty = board_qty × qty_per_board). It also states what is excluded (fabrication and assembly charges), providing solid behavioral context though not detailing the response format.

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, each earning its place: the first states the core function, the second excludes non-included costs, and the third gives usage timing. It is dense, front-loaded, and contains no redundant or irrelevant wording.

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 only 2 parameters and no output schema, the description covers the essential operational details: what it computes, how fees are calculated, what is excluded, and when to use it. It omits only optional details like response breakdown structure, which are not required because there is no 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 coverage is 100%, so the parameters are already documented. The description adds meaning by explaining how board_qty and qty_per_board interact to determine the quantity for price breaks, and clarifies that the fee applies per unique extended-tier part, going beyond the schema's simple property definitions.

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 starts with the specific verb 'Estimate' and names the exact resource: the parts side of a JLCPCB assembly order for LCSC parts. It also implies that the tool is distinct from sibling tools like suggest_bom_parts and find_alternatives by stating it is used after finalizing part picks.

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?

Explicitly says 'Use after finalizing part picks from suggest_bom_parts / find_alternatives,' giving clear timing relative to alternatives. It also clarifies exclusions ('Does not include PCB fabrication or per-joint assembly charges'), which sets expectations for when not to use this tool for a full cost estimate.

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 key behaviors: 'The original part is excluded from results' and details ranking criteria (tier, stock, price, reasons/warnings). This adds meaningful context about output and selection logic, though it does not explicitly state read-only behavior or error cases.

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: one sentence covers purpose, use cases, and behavior, followed by a second sentence with ranking details. 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 2-parameter tool with no output schema, the description explains purpose, use cases, ranking logic, and output characteristics (reasons/warnings). It does not explicitly state the return type (e.g., list of alternatives) but the implied structure is sufficient for most agents.

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% with clear descriptions for both 'lcsc' and 'limit'. The description adds general context about ranking but does not add parameter-specific meaning beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the tool's function: 'Given an LCSC part number, find ranked drop-in alternatives with matching specs and package.' This uses a specific verb and resource, and distinguishes it from siblings like search_parts and get_part by focusing on alternatives for an existing part.

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

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

It provides explicit use cases: 'useful when a part is out of stock, extended-tier (carries the $3 loading fee), or expensive.' This gives clear context for when to use, though it does not explicitly name alternative tools or state 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?

No annotations are provided, so the description carries the full burden. It discloses the return payload in detail (assembly tier with fee semantics, stock, price breaks, attributes, URL) and frames the operation as a lookup, implying read-only behavior without stating it explicitly. This is strong behavioral transparency, though it stops short of discussing failure modes.

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 the first sentence front-loading the action and listing the key return fields in a compact parenthetical. The second sentence provides a clear usage directive, and every word adds value. 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?

Despite having no output schema and no annotations, the description fully covers the tool's purpose, parameter format, return contents, fee semantics, and intended usage within a single BOM workflow. It is sufficiently complete for a single-parameter lookup tool.

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

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

Schema description coverage is 100% for the single 'lcsc' parameter, and the schema already states the format and example. The description reinforces the example and usage context but adds no new semantic details beyond the schema, so the baseline of 3 applies.

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 'Look up a single part by LCSC number' which is a specific verb+resource+identifier, and it distinguishes itself from sibling search tools by focusing on a single part by exact ID. The example 'C25804' and the BOM verification use case reinforce its unique role.

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 states 'Use to verify a candidate part before committing it to a BOM,' giving a clear when-to-use scenario. It does not enumerate alternative tools or exclusion criteria, so it earns a 4 rather than 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 full burden for behavioral disclosure. It clearly states side effects (writes files, registers in lib tables), prerequisites (python3, kicad-lcsc-manager), and project impact. It does not mention error handling or return behavior, but the core disruptive behavior is adequately disclosed.

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 the core action, followed by essential prerequisites and usage timing. Every sentence adds value without 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 (external engine, file writes, library registration) and no output schema, the description covers key context: what it does, prerequisites, and when to use it. It could mention failure modes (e.g., missing library tables) but the provided information is sufficient for correct invocation.

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

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

The input schema has 100% description coverage, so the baseline is 3. The description adds useful context beyond the schema, such as the 3D model format (STEP + WRL) and the explicit mention of sym/fp-lib-table registration, which complements the project_dir parameter. This enhancement justifies a 4.

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 specific verbs ('Fetch', 'add', 'registering') and clearly identifies the resource (LCSC part) and destination (KiCad project libraries). It distinguishes this tool from siblings by focusing on importing/registering parts, unlike search/get/analyze 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?

Explicitly states when to run it: 'after picking parts with suggest_bom_parts / find_alternatives to make them usable in the schematic.' It also gives prerequisites (python3, external engine). However, it does not explicitly mention when not to use it or name an alternative for this task, so it falls short of a 5.

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

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

No annotations are present, so the description carries the full burden. It goes beyond a basic search statement by explaining the financial implications of tier selections (loading fees, which tiers are fee-free). It doesn't mention result structure or pagination, but for a read-only search tool the tier behavior is the most critical nuance and it is thoroughly disclosed.

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

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

Three dense sentences, each serving a distinct purpose: (1) state what it does, (2) give usage examples and a sibling alternative, (3) explain the nuanced tier fees. There is zero filler or repetition—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 5 parameters, one enum, and no output schema. The description covers the query format, package filtering context, tier meaning with fee implications, and the distinction from a sibling. It doesn't describe result fields, but for a search tool the most important context—how to search and what the tier filter does—is fully addressed.

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%, so the baseline is 3. The description adds value with concrete example queries ('AMS1117-3.3', '10k 0603', 'USB-C 16pin') and clarifies the non-obvious 'admit-lower semantics' of the tier enum beyond the schema's own description. This raises it above the baseline.

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 ('search') and a clear resource ('JLCPCB/LCSC parts catalog'), then lists example use cases (ICs, connectors, LEDs) and concrete query formats. It explicitly distinguishes itself from the sibling tool search_passives, which is the strongest form of purpose clarity.

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

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

The description gives explicit direction on when to use this tool versus search_passives ('For resistors/capacitors by exact value prefer search_passives'), provides multiple usage examples, and explains the tier filter semantics in detail. This is exactly the 'when-to-use vs alternatives' guidance the rubric asks for.

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 full responsibility. It discloses that the tool parses value strings into ohms/farads, searches by exact spec, optionally filters by package, and that results are ordered with a preference for basic-tier parts. This goes well beyond a generic search description, though it does not detail return format or error handling.

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

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

Three sentences: purpose, usage guidance, and behavioral note. Every sentence adds value with no redundancy. The most important information (what and when) is front-loaded, and the text is concise and scannable.

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 this is a search tool with four parameters and no output schema, the description covers all necessary aspects: what it does, how to invoke it (value and optional package), when to use it instead of alternatives, and what to expect from results. No significant gaps remain.

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%, so the baseline is 3, but the description enriches the parameter meaning with parsing examples ('10k', '4k7', '100nF') and clarifies that values are interpreted as ohms/farads. This helps the agent construct valid inputs, especially for the 'value' parameter.

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

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

The description specifies a precise action ('Parametric JLCPCB search') and distinct resource ('chip resistors or capacitors by value'). It differentiates from siblings by explicitly noting it uses exact spec parsing rather than fuzzy text matching, making it clear when this tool is the right choice.

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

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

The description gives explicit when-to-use guidance: 'Prefer this over search_parts for R/C BOM lines — it avoids fuzzy text matches.' It also describes the optional package filter and how to request specific component values, providing clear context for 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 full burden. It discloses ranking preferences (basic tier, deep stock, lower price), the $3 loading fee for extended-tier parts, fee-free status for basic/preferred, and the statuses including needs_review with a warning about fuzzy text matching. This is rich behavioral detail.

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

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

The description is a single dense paragraph, but every sentence adds relevant information. It is front-loaded with the core purpose, then details input, output statuses, and cost logic. Slightly long but 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?

Given 5 parameters, no output schema, and no annotations, the description thoroughly covers expected outputs (statuses, candidates, reasons/warnings, cost breakdown) and ranking logic. Nothing critical is missing for an agent to invoke and understand the tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds value by clarifying the 'exactly one' input rule and explaining how inputs like board_qty and stock_multiple influence ranking and stock warnings, going beyond bare schema definitions.

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: 'Suggest concrete JLCPCB parts for a whole BOM with assembly-cost awareness.' This is specific and distinguishes it from sibling tools like search_parts or estimate_assembly_cost, which handle individual searches or cost estimation separately.

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

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

The description explains the intended context (whole BOM, assembly-cost awareness) and explicitly describes the input switch (path vs bom_lines, exactly one). It does not explicitly name alternatives or exclusions, but the scope is clear enough.

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