KiCad MCP Pro

Overview Schema Related Servers Score Discussions

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.3.2
Disambiguation2/5
With 241 tools, many have overlapping purposes, such as multiple quality gate tools (schematic_quality_gate, pcb_quality_gate, project_quality_gate) and several DRC-specific filters (run_drc, get_unconnected_nets, get_courtyard_violations). There are also aliases like export_step/export_3d_step and pcb_add_copper_zone/pcb_add_zone, which adds confusion. While domain prefixes help, the sheer number of similar operations makes selection error-prone.
Naming Consistency3/5
Most tools follow a domain-prefix + verb + noun pattern (sch_add_symbol, pcb_add_via, emc_check_via_stitching), but there are inconsistencies: some tools lack prefixes (validate_design, check_design_for_manufacture), some use noun-first (si_generate_stackup), and there are backward-compatible aliases that break uniqueness. Overall patterns are readable but not uniform.
Tool Count1/5
At 241 tools, this server is extremely large. Even for a comprehensive EDA MCP, this exceeds any reasonable expectation and would overwhelm an agent. The calibration suggests 25+ is already excessive; 241 is an extreme mismatch.
Completeness5/5
The tool set covers the entire PCB design workflow: schematic entry, PCB layout, routing, DRC/ERC, simulation, library management, BOM/variants, DFM, manufacturing exports, and even version control. There are no obvious dead ends; operations have both creation and editing capabilities. It is arguably over-complete.
Average 3.3/5 across 240 of 241 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description carries the full burden of behavioral disclosure. It only mentions it is an alias and provides no information about the operation's side effects, permissions, or any other behavioral traits. It does not disclose whether the tool modifies the design or what it returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, but it is under-specified rather than concise. It lacks essential information about the tool's functionality and parameters, making it far too minimal to be useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two required parameters, no annotations, and relies entirely on an alias reference, the description is completely inadequate. It does not tie the parameters to any operation, nor does it provide enough context for an agent to invoke it correctly. The output schema exists but the description does not leverage it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines net_name and target_length_mm, but the description adds no additional meaning. With 0% schema description coverage, the description must compensate, but it does not explain how the parameters are used, the expected format, or units.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says it is a backward-compatible alias for route_tune_length(), but does not state what the tool actually does. This relies on the reader knowing route_tune_length, making the purpose unclear. It is not a complete tautology, but it fails to provide any functional description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
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 like route_tune_length or tune_diff_pair_length. The alias reference alone does not indicate any context or conditions for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'Review' suggests a read-only operation, but there is no disclosure of what the tool does with the net class, what results are produced, or any side effects. This is insufficient for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is a single short sentence, it is under-specified rather than concise. It lacks critical information, so the brevity is a deficiency, not a strength.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a domain-specific and complex purpose, with an output schema noted but not described. The description does not explain what 'short-stub proxy' means, what the tool returns, or how it relates to sibling EMC checks, leaving the tool essentially unusable without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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, but it does not explain net_class or max_stub_length_mm. The phrase 'short-stub proxy' might hint at the max_stub_length_mm parameter, but it is too cryptic to count as meaningful parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Review' with a resource, but 'short-stub proxy' is ambiguous and fails to specify what the tool actually checks. It does not distinguish this tool from sibling EMC check tools, leaving the purpose vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many other emc_check_* tools, nor any prerequisites or exclusions. The description is entirely silent on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context beyond the annotations; it only discloses that it is an alias for pcb_add_zone(), but does not describe actual behavior, side effects, or requirements. The destructiveHint annotation covers the safety profile, but the description does not enrich it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise in length, but it is under-specified rather than efficiently informative. It does not earn its place because it adds little beyond what the tool name already suggests.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no schema descriptions) and sparse annotations, the description is grossly incomplete. It provides no explanation of the operation, parameters, or behavior, making it inadequate for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description contains no parameter information at all. With a schema coverage of 0% and 10 parameters, the description fails entirely to compensate for undocumented parameters, leaving all parameter semantics unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Backward-compatible alias for pcb_add_zone()', which indirectly identifies this tool as a zone-adding function, but it does not explicitly describe what the tool does. It relies heavily on the reader knowing pcb_add_zone(), making the purpose vague and not self-contained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'backward-compatible' hints that this tool exists for legacy use, but there is no explicit guidance on when to use this tool versus pcb_add_zone() or other alternatives. No exclusions or contextual criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral info. It only states the action and mentions inputs that are not actually parameters, failing to explain how the tool uses tier, quantity, or manufacturer, or what the output contains. The inconsistency between description and schema further reduces transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it contains irrelevant and misleading information. It does not earn its place because it misrepresents the tool's inputs, making it potentially harmful rather than helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters with 0% schema coverage and no useful description, the context is severely incomplete. The description mentions non-existent inputs and omits any useful details about the actual parameters or how cost estimation works, leaving the agent unable to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameters. Instead, it references nonexistent inputs (board area, layers, via count) and provides no meaning for the actual parameters (tier, quantity, manufacturer). This is misleading and fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool estimates fabrication cost, which is a specific verb and resource. However, it incorrectly lists 'board area, layers, and via count' as inputs when the schema actually takes tier, quantity, and manufacturer, making the purpose somewhat confusing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like dfm_run_manufacturer_check. It implies usage for cost estimation, but there is no explicit context, exclusions, or comparison to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint: true, but the description does not explain what makes this operation destructive (e.g., overwriting the output file). It also doesn't mention the 3D nature or any side effects, so it adds no behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but too sparse for a tool with multiple parameters and a destructive hint. It under-specifies rather than being efficiently detailed, making it more undersized than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the three parameters and the destructive annotation, the description is grossly incomplete. It doesn't explain side options, zoom behavior, output file handling, or the fact that this is a 3D render. The output schema exists but doesn't compensate for the lack of operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has three parameters (side, zoom, output_file) but the description provides no explanation of them. With 0% schema description coverage, the description was expected to compensate, but it simply says 'Render the board to a PNG image,' offering no insight into parameter meaning or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (render) and the output format (PNG image), which distinguishes it from other export tools like export_svg or export_dxf. However, it does not explicitly mention that this is a 3D render, relying on the tool name for that context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 other export or rendering tools. No alternatives, prerequisites, or typical scenarios are mentioned, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the annotations already indicate. It does not explain the implications of destructiveHint=true or openWorldHint=true, such as what files might be written or what side effects occur, so it fails to provide useful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence and is not bloated, so it is concise in length. However, it simply restates the tool name and lacks substantive content, making it more under-specified than effectively concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema and annotations, but the description is incomplete for an export tool. It does not clarify which BOM (base variant, active variant, etc.) is exported, what output formats are available, or how it differs from related export tools in the same domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'format' is not mentioned in the description, and schema description coverage is 0%. The description does not explain valid formats or how the format affects the export, leaving agents without essential parameter knowledge.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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 'bill of materials', which communicates the core function. However, it does not differentiate from sibling tools like 'variant_export_bom' or 'lib_get_bom_with_pricing' that also involve BOM outputs, so it lacks explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 over alternatives. The description does not mention any exclusions, prerequisites, or comparative usage scenarios, providing only a bare statement of the action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include openWorldHint and destructiveHint, which already signal side effects and potential destructiveness, but the description adds no context about what is created, overwritten, or how the output directory behaves. It contributes no additional behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence, but it is under-specified. It avoids verbosity at the cost of utility, providing no structured information beyond the basic action-resource statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and an output schema, the description is minimal. It does not explain the role of output_subdir, the destructive implications hinted by annotations, or how this tool fits into the broader export workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter output_subdir is not mentioned in the description, and schema coverage is 0%. The description fails to explain the parameter's purpose or default behavior, leaving the agent without semantic grounding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Export' and the resource 'drill files', which is a specific output type that distinguishes it from siblings like export_gerber. However, it lacks details about format or scope, so it is not fully comprehensive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 other export tools or any prerequisites. The description gives no context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations indicate destructiveHint=true, but the description does not explain what destructive effects might occur (e.g., overwriting files) or any other behavioral traits such as whether a file is saved to disk, which layers are included by default, or whether a dialog is opened. It adds no context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, but it is under-specified rather than appropriately concise. It omits essential context about parameters and usage, so the brevity comes at the cost of usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large number of sibling export tools and the presence of an optional 'layers' parameter, the description is too sparse. It does not disambiguate the PDF type (2D vs 3D) or clarify the behavior of the layers parameter, leaving significant gaps for an agent trying to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The 'layers' parameter is not explained in the description at all, and its meaning cannot be inferred from the description text. The description fails to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Export') and the resource ('PCB') and target format ('PDF'), making the core purpose clear. However, it does not distinguish from sibling export tools like export_sch_pdf or pcb_export_3d_pdf, so it earns a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternative export tools (e.g., export_3d_pdf, export_svg). The description is purely a statement of function, leaving the agent to infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint: true, but the description adds no behavioral context. It doesn't disclose what 'export' entails (e.g., file creation, overwriting), side effects, or consequences. The description is neutral but fails to elaborate on the destructive nature hinted by annotations. With no additional context, the description adds little beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise and free of fluff. However, it is under-specified, providing only the bare purpose without context. While appropriately front-loaded, the brevity borders on inadequate for a tool with behavioral annotations and an undocumented parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's one parameter, output schema, and annotation hints, the description is incomplete. It doesn't explain what 'assembly position data' contains, what the output format options mean, or any side effects (especially with destructiveHint). It also doesn't distinguish from sibling export tools, leaving the agent to guess when to use it. The description is minimally viable but lacks essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description doesn't mention the 'format' parameter at all. The schema only provides a default value without explaining allowed values or semantics. The description fails to compensate for the lack of schema documentation, leaving the parameter entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Export') and resource ('assembly position data'), making the tool's purpose clear. It distinguishes from many sibling export tools by naming the specific data type, though it doesn't explicitly differentiate from similar exports like export_bom or export_netlist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 any prerequisites, exclusions, or preferred contexts. For an export tool among dozens of siblings, this is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only restates the read-only nature implied by the readOnlyHint annotation. It adds no extra context such as what happens if an invalid category is given, whether the tool returns an empty list, or any rate limits. Since the annotations already declare safety, the description contributes no additional behavioral disclosure beyond a tautology.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence, which is concise and easy to parse. However, it is under-specified—important information like parameter meaning and usage is omitted, so the brevity is more a sign of incompleteness than deliberate conciseness. Still, it earns a middle score for not being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and an output schema, but the description does not explain what categories are valid or how to discover them. There is no mention of the companion tool kicad_list_tool_categories for obtaining category names. Given that the parameter is an unconstrained string, the description is insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must explain the category parameter, but it merely says 'specific category,' which is a rephrasing of the parameter name. No details are provided about valid values, format, or how to obtain them. The parameter remains ambiguous, forcing the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: getting tool names within a category. It uses a specific verb ('Get') and resource ('tool names'), which distinguishes it from the sibling tool kicad_list_tool_categories. However, it does not explicitly differentiate from other getter tools, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as kicad_list_tool_categories. It does not mention prerequisites like needing to know valid categories or suggest using a category listing tool first. Without such context, the agent is left to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It indicates 'live' pricing, implying a network call to an external source, but does not explain latency, cost fetching behavior, or whether it requires prior setup. It also does not disclose that it is a read-only operation or what 'live' means in terms of data freshness. This is insufficient for a tool that likely fetches external data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, which is good. However, it is under-specified, providing only a high-level summary without the behavioral or parameter details needed. It is not verbose but lacks substance, balancing at a 'minimum viable' level.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters) and the presence of an output schema, the description still leaves many gaps. It does not clarify what a 'BOM summary' includes (e.g., components, quantities, prices), how 'source' affects results, or how 'quantity' interacts with pricing. The output schema exists but the description should provide enough context for an agent to know when and why to call this tool. It does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 parameters. The two parameters 'source' and 'quantity' are not described at all. The mention of 'extended pricing' hints that quantity is used for cost multiplication, but this is not explicit, and 'source' remains completely unexplained. The description fails to compensate for the lack of schema doc.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: generating a BOM summary with unit and extended pricing. The verb 'Generate' and resource 'BOM summary' are specific, and it distinguishes itself from export_bom (which exports files) and variant_export_bom by focusing on a live summary with pricing. However, it does not explicitly differentiate from other BOM-related tools like lib_check_stock_availability, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention that it retrieves live pricing from a source (jlcsearch) or that it is appropriate for cost estimation rather than export. No exclusions or alternative recommendations are provided, leaving the agent without clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the annotation destructiveHint=true already implies. It does not explain potential overwrites, board modification effects, or any constraints on layer or placement. No additional transparency is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, making it concise and front-loaded. However, it is under-specified to the point of providing little value, so it is not an efficient balance of brevity and information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, 3 required, no schema descriptions, and a destructive hint), the description is severely incomplete. It lacks explanation of side effects, return values, or usage context, leaving most important details absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate by explaining parameters. It mentions none of the 8 parameters (text, coordinates, size, layer, etc.), leaving the agent to guess at their meanings and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add board text' clearly names the action (add) and resource (board text), distinguishing it from sibling add operations like tracks, vias, and zones. However, it does not specify which layer or type of text, relying on schema defaults for that detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like pcb_add_barcode or pcb_add_track. The description does not mention any prerequisites, exclusions, or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the destructiveHint annotation already indicates. It does not explain what board modifications occur, whether existing copper is affected, or how the via connects layers. Given the annotation already flags destructiveness, the description provides minimal additional value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Add a via.'), but it is under-specified for a tool with six parameters and multiple related via-adding tools. The brevity sacrifices necessary clarity, making it not appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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, destructive effect, sibling via tools), the one-sentence description is incomplete. It does not explain how this via addition differs from blind or microvia alternatives, nor the practical implications of the destructive operation. The presence of an output schema does not compensate for the missing operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must compensate by explaining parameter meanings, but it provides none. The parameter names (e.g., x_mm, drill_mm, via_type) are somewhat self-explanatory, but the description fails to clarify units, coordinate system, or the role of via_type, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a via' clearly states the verb and object, specifying that this tool creates a via on the PCB. However, it does not distinguish between via types (e.g., through, blind, micro), which is a gap given sibling tools like pcb_add_blind_via and pcb_add_microvia.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention preferences, prerequisites, or exclusions, leaving the agent to infer that adding a via is the only use case without clarifying differences between standard, blind, or micro vias.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare `readOnlyHint: true` and `idempotentHint: true`, so the description adds no extra behavioral context. It does not state what data is returned, whether it lists all footprints, or how `filter_layer` affects results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three words is extremely concise and front-loaded, but the brevity is under-specification rather than efficient structure. It lacks any additional context that would help the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 3 undocumented parameters and no parameter descriptions. The description leaves ambiguity about what 'board footprints' includes and how pagination or filtering works, making it barely adequate for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 3 parameters with 0% schema description coverage, and the description gives no parameter information. `page`, `page_size`, and `filter_layer` are left entirely to the reader's inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'list' and resource 'board footprints', clearly indicating a read operation. It distinguishes from sibling `lib_list_footprints` by specifying board rather than library, but it could be more explicit about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like `lib_list_footprints`, `pcb_get_pads`, or `pcb_get_footprint_layers`. The description does not mention filtering or pagination usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations include destructiveHint: true, which already signals a destructive behavior. The description adds no further detail about the side effects of setting the footprint copper side, such as whether it flips the footprint, changes connectivity, or only affects the layer assignment. Thus, the description provides no behavioral transparency beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specified rather than concise. It omits essential information about parameters and usage context, making it insufficiently sized to be helpful. The brevity comes at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two required, undocumented parameters and a destructive annotation, the description is not complete enough. The agent cannot infer valid layer values, the meaning of 'reference', or the impact of the operation. Even with an output schema present, the input semantics are entirely missing, leaving the tool unusable without external assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its two required parameters. The description only mentions the resource ('copper side') but does not explain that 'reference' refers to the footprint's reference designator or which values the 'layer' parameter accepts (e.g., top/bottom, front/back). With such low schema coverage, the description must compensate but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Set' and resource 'footprint copper side' to indicate the action performed by the tool. It clearly identifies the tool's primary function, though it does not distinguish it from related footprint tools like pcb_get_footprint_layers or pcb_move_footprint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 lacks any context about the typical scenario (e.g., flipping a footprint to the opposite copper layer) or any exclusions, prerequisites, or fallback tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description must carry behavioral disclosure. It only states the return action; it does not mention whether the tool runs checks, is read-only, requires prior setup, or how the 'gate' is computed. 'Structured form' hints at output shape but not behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence and front-loaded, but the phrase 'for capable MCP clients' adds no value and is unhelpful fluff. It is concise but not effectively informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, but the description still does not explain what constitutes the 'full project gate', how parameters influence the result, or how this relates to project_quality_gate. Given a project with many quality-gate siblings, the tool is under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description omits any mention of the 'tier' and 'manufacturer' parameters, leaving their purpose and allowed values entirely unclear. With two optional parameters, the description must compensate, and it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Return' and identifies the resource as 'the full project gate in structured form', which distinguishes this report tool from sibling like project_quality_gate. However, 'project gate' is unexplained jargon, so clarity is good but not excellent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as project_quality_gate or pcb_placement_quality_report. The 'for capable MCP clients' phrase is not a usage guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral details such as whether it writes a file to disk, overwrites existing files, or modifies project state. The only annotation, openWorldHint: true, hints at external side effects, but the description itself adds no context about those side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
It is concise at one sentence, but the brevity sacrifices clarity—'stage' is left undefined and no supporting context is provided. It's under-specified rather than efficiently complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a simple one-parameter tool with an output schema, it could be adequately described in a few sentences. However, the current description leaves the exact action ambiguous, the relation to routing flow unexplained, and the role of the output_path parameter unaddressed, making it incomplete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter output_path has no description in the schema (0% coverage) and the tool description does not mention it. The parameter name and default provide some self-explanatory meaning, but the description adds no additional semantics about path handling, format, or overwrite behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (Specctra DSN file for FreeRouting) and uses 'Stage' as the verb, but 'stage' is ambiguous and doesn't clearly explain what the tool accomplishes. It also doesn't distinguish itself from sibling tools like route_autoroute_freerouting, which may also involve DSN files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It doesn't mention that it's a precursor to running route_autoroute_freerouting or that it should be used before other routing steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure but provides none. It does not state whether the simulation modifies state, requires a netlist, or how results are returned. This is insufficient for a simulation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise as a single sentence with no wasted words, but it is under-specified. It lacks structure and necessary context, making it more akin to under-specification than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 lacks essential context for a simulation tool: prerequisites, input requirements, parameter roles, and differences from other simulation types. With 4 parameters and no parameter descriptions, the description is incomplete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter meaning. It does not explain step_time_s, stop_time_s, probe_nets, or netlist_path, leaving the agent to rely solely on parameter names, which is inadequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Run a transient time-domain simulation'), clearly indicating the simulation type. The phrase 'transient time-domain' implicitly distinguishes it from sibling tools like sim_run_ac_analysis or sim_run_dc_sweep, though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention prerequisites (e.g., netlist_path), conditions for use, or exclusions. The description only states what it does, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description must disclose behavioral traits. It only states the high-level purpose but does not mention whether the tool is read-only, requires a board context, relies on calculations, or returns a result. No side effects or assumptions are disclosed. The lack of any behavioral context beyond the basic function leaves the agent uninformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and contains no fluff. However, it is under-specified: it omits critical parameter and usage information that could have been included without adding much length. It is concise but not effectively structured to convey the necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (three parameters, one required) and empty annotations, the description is too minimal. It does not explain the calculation model, assume any board state, or clarify the meaning of inputs. While an output schema exists (helping with return values), the description lacks information about when this tool is relevant, how the calculation works, and what assumptions are made. This is insufficient for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 parameters. It does not explain power_w, via_diameter_mm, or thermal_resistance_target. The phrase 'target resistance' vaguely maps to thermal_resistance_target, but no units, defaults, or relationships are provided. The description adds essentially no semantic value beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Estimate how many stitched thermal vias are needed for the target resistance.' It uses a specific verb ('estimate') and identifies the resource (stitched thermal vias) and the goal (achieving target resistance). This distinguishes it from siblings like emc_check_via_stitching or thermal_check_copper_pour, though it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description implies its use for thermal via count estimation but does not mention any preconditions, exclusions, or relation to other thermal/EMC tools. A clear gap given the presence of nearby tools like emc_check_via_stitching.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects, prerequisites, and behavior on missing pours, but it only says 'check,' implying read-only without explicitly stating so. It also does not mention board state requirements or how results are presented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, which is concise, but it is under-sized for a tool with three parameters and no annotations. The brevity is not an asset because it omits essential context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides only the basic intent without explaining what constitutes 'support,' what the output looks like, or how expected_power_w relates to the check. Even though an output schema exists, the description does not connect the tool's purpose to its parameters or results, leaving it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has three parameters with zero description coverage, and the tool description only hints at 'the net' without explaining net_name. It does not clarify the meaning or purpose of preferred_layer or expected_power_w, leaving the agent without enough information to set them correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Check whether' and identifies the resource as 'copper pour support for the net,' making the core action clear. It distinguishes this as a status-check tool rather than a generation or calculation tool, but 'copper pour support' is not defined, 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.
Usage Guidelines2/5
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, no exclusions, and no mention of alternative tools. It does not say whether it should be used before generating a pour or for validating thermal design, leaving the agent without context for sibling selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotation Contradiction: The description says 'Add' (a creation/insertion operation) while annotations declare destructiveHint=true, implying potential data loss or irreversible changes. The description does not explain why this could be destructive, and the contradiction makes the safety profile confusing. Even without the contradiction, the description adds almost no behavioral context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
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 appropriately terse, though it omits essential details. Conciseness should reward brevity, but the lack of supporting information makes it borderline; a 4 feels right given the efficient structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters, a destructive annotation, and no output schema, this one-sentence description is wholly inadequate. It fails to explain layer defaults, coordinate interpretation, width meaning, or any side effects. The agent would have no idea how to use the tool correctly or what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description offers no explanation of parameters. The parameter names (x1_mm, y1_mm, etc.) are somewhat self-explanatory but the description neither clarifies coordinate meaning, layer semantics, width usage, nor any constraints. The burden falls entirely on the schema, which is insufficient for a tool with six parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add' and the specific resource 'board graphic rectangle', which distinguishes it from sibling tools like pcb_add_circle, pcb_add_track, and pcb_add_text. The primary action and target are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor does it mention layer context, design rules, or exclusions. It only states the basic action, leaving the agent without placement guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description must disclose behavior. It only says 'Create' with no mention of side effects, such as whether existing tracks are replaced, which layers are affected, or how width defaults are applied. This is a mutation tool with no transparency about its impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is easy to parse, but it is under-specified. It lacks important details without being overly verbose, so it is adequate but not exemplary in structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters (4 required) and no parameter descriptions, the one-sentence description is insufficient. It does not explain how to identify pads, what the output schema contains, or alternative routing behaviors, leaving too much implicit for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 any parameters. It mentions 'two pads' but does not map them to ref1/pad1/ref2/pad2, nor does it explain layer or width_mm semantics. The description provides no added meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Create' and names the exact resource: a simple orthogonal route between two pads. It clearly distinguishes from sibling tools like route_differential_pair and sch_route_wire_between_pins by specifying 'pads' and 'orthogonal'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The word 'simple' implies it is for basic orthogonal connections, but there are no explicit when-to-use or when-not-to-use instructions, nor any mention of route_single_track or other routing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, and the description provides no behavioral details. It does not disclose whether existing tracks are modified, how the new segment connects to the board, what defaults are used (e.g., layer F_Cu, width 0.25mm), or any side effects. This is insufficient for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words, making it concise. However, given the tool's seven parameters, it is arguably under-specified, though this is better addressed in other dimensions. The structure is clear and front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a routing tool with seven parameters, no annotations, and an output schema, this description is severely incomplete. It does not explain expected inputs, coordinate system, layer defaults, or how the routed segment is returned. The agent cannot reliably invoke this tool based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to explain any of the 7 parameters. It does not mention that x1/y1 and x2/y2 define start/end points in millimeters, or the meaning of layer, net_name, and width_mm. The description adds no semantic value beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (route) and the specific resource (a single straight track segment), distinguishing it from sibling tools like route_from_pad_to_pad or route_differential_pair. The qualifiers 'single straight' and 'segment' provide scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given regarding when to use this tool versus alternatives. The description simply states what it does without mentioning scenarios, prerequisites, or alternative tools, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true, but the description adds no context about what is modified, whether existing graphics are overwritten, or how the footprint block is affected. The verb 'inject' gives only a vague sense of addition without behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is front-loaded and free of fluff, but it is under-sized for the complexity of the tool. It is concise but not appropriately sized, omitting essential information that the schema cannot fully convey.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, a destructive annotation, and no parameter guidance, a one-line description is grossly insufficient. The output schema alone cannot compensate for missing context about shape types, layer conventions, or coordinate usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 any of the 9 parameters. Critical parameters like shape_type, layer, and the coordinate pair x1_mm/y1_mm remain completely undefined, leaving the agent unable to choose valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'inject' and identifies the resource as an 'inner-layer graphic primitive' within a 'footprint block', which clearly differentiates it from board-level graphics tools like pcb_add_circle or pcb_add_rectangle. It precisely states 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.
Usage Guidelines2/5
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 such as footprint editing or board-level graphics tools. It does not mention exclusions, prerequisites, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries the full burden. It says 'Review' which implies a read-only analysis, but it does not disclose what the check entails, what conditions trigger flags, or how results are reported. No side effects or limitations are mentioned. The description is too vague to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no fluff. It is appropriately front-loaded and every word contributes meaning. However, it may be too terse for a tool with this complexity, but conciseness itself is good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters and an output schema, but the description gives no context about when to use it, how results are returned, or what constitutes a violation. The output schema exists, so return format is covered, but the overall purpose and usage context are underdeveloped. A minimal viable description would at least mention the parameters or the checking context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to compensate. The description does not explain the parameters net_p, net_n, or max_skew_ps. While the parameter names are somewhat self-explanatory, the description does not clarify their roles or how they relate to 'width symmetry', and there is no mention of a width tolerance parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Review' and identifies the resource as 'diff-pair skew and width symmetry'. This distinguishes it from the sibling si_check_differential_pair_skew, which focuses only on skew. However, 'review' is somewhat generic and could be more forceful like 'check' or 'analyze'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The sibling si_check_differential_pair_skew exists, but the description does not mention it or explain when to prefer this tool for combined skew/width checks. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare 'destructiveHint' and 'openWorldHint', but the description adds no context about what these mean in practice (e.g., whether it writes a file, overwrites existing files, or has side effects). The description simply restates the tool's function without disclosing behavioral traits beyond what the annotations already hint at.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is appropriately sized for a simple tool, though it is very terse. It lacks any structured breakdown of parameters or behavior, but for pure conciseness it does not contain filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one optional parameter and an output schema present, the tool is relatively simple. However, the description omits crucial context about the 'format' parameter and the distinction from 'export_spice_netlist'. The annotations provide some safety context, but the absence of parameter guidance and usage alternatives makes the description incomplete for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the only parameter 'format' is not described in the tool description. The agent has no idea what valid formats are (beyond the default 'kicad') or what the parameter controls. The description provides no compensation for the missing schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Export') and resource ('KiCad schematic netlist'), so the core purpose is clear. However, it does not distinguish itself from the sibling tool 'export_spice_netlist', which also exports a netlist. Without this differentiation, an agent may not know which to choose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. There is no guidance on when to use this tool versus alternatives like 'export_spice_netlist', nor any prerequisites or expected inputs beyond the schema. The agent is left to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint: true indicates a destructive or state-changing operation, but the description adds no context about what exactly happens (e.g., overwriting paths, persisting changes, affecting the current session). It neither contradicts the annotation nor provides additional 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It is efficiently front-loaded but lacks essential semantic richness, which prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that changes the active project, it is critical to state that this establishes the working context for subsequent calls and that paths are optional overrides. The description omits this context, making it incomplete for an agent deciding when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must explain parameters but only says 'directory and file paths', which vaguely maps to project_dir and pcb_file/sch_file. It does not clarify each parameter's role, especially output_dir, or mention that only project_dir is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set the active KiCad project directory and file paths' clearly identifies a setter action on the active project scope. It distinguishes from creation tools by using 'set active' rather than 'create new', but it does not explicitly differentiate from other project context tools like kicad_get_project_info or project_set_design_intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when this tool should be used, such as before other KiCad operations or when switching projects. No alternatives or exclusions are mentioned, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects, but it only says 'assign' without noting overwrite behavior, persistence, library/reference resolution, or any side effects. This is minimal and insufficient 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted wording, but it is under-specified. For a tool with three required parameters, this brevity sacrifices necessary detail, though it remains easily parseable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is inadequate for a mutation tool with three required params and no annotations. It omits prerequisites, side effects, error conditions, and parameter meanings. The presence of an output schema does not compensate for these critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 clarify the three required parameters (library, footprint, reference). It doesn't explain how these parameters identify the symbol or what values are expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Assign') and resource ('a footprint property') with a clear target ('a schematic symbol'). It distinguishes from sibling tools like lib_assign_lcsc_to_symbol by naming the footprint property specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no exclusions, and no context about prerequisites. It only states what the tool does, not why or when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects and constraints. It only mentions the target directory and 'simple', omitting whether files are overwritten, how pins are interpreted, or any project/library side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, no filler, front-loads the verb and object. However, it is so terse that it omits behavioral and parameter detail, making it less useful than a slightly longer description would be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and only two parameters, the description provides insufficient context for a creation tool with nested object pins. It lacks usage prerequisites, pin structure, and behavior expectations, leaving important gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the tool description provides no meaning for 'name' or 'pins' beyond their raw names. The 'pins' array of objects is completely unexplained, so the agent cannot infer required structure or formatting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create'), the object ('custom symbol'), and the location ('active project directory'), making the tool's purpose understandable. It is somewhat differentiated by 'simple' but does not explicitly contrast with symbol-generation siblings like lib_generate_symbol_from_pintable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or alternative-based guidance is provided. The phrase 'in the active project directory' gives context but no exclusions or comparisons to similar library tools such as lib_generate_symbol_from_pintable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare destructiveHint=true, and the description indicates a mutating operation ('Add'), but it provides no additional behavioral context such as coordinate system, units, or what existing geometry might be affected. It does not contradict the annotation, but adds negligible transparency beyond what is already structured.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence without filler, which is efficient, but it is under-specified. It earns its place but does not carry enough information to be considered well-structured for a tool with multiple parameters and a destructive hint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, a destructive annotation, and an output schema, the description is too minimal. It omits guidance on coordinate format, layer semantics, and the effect on existing board content, making the tool incomplete for an agent to invoke correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description gives no parameter-level detail. Although parameter names like cx_mm, cy_mm, radius_mm, width_mm, and layer are suggestive, the description does not explain units, defaults, or how layer interacts with the graphic, so 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Add' and resource 'board graphic circle', which clearly distinguishes it from sibling tools like pcb_add_rectangle and pcb_add_text. However, it doesn't clarify what 'graphic' means in terms of layer or usage, so it stops short of full clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as pcb_add_rectangle, pcb_add_segment, or pcb_add_track. It does not state typical use cases for board graphic circles or any exclusions, leaving the agent to infer intent from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description merely says 'Add a single track segment' and adds no behavioral context beyond the destructiveHint annotation. It does not disclose how the segment interacts with existing copper, whether design rules are checked, or how net/width defaults are applied, so it provides no extra transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words, making it concise and easy to parse. However, it is arguably too sparse for a 7-parameter tool, though it does serve as an efficient purpose statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, 0% schema description coverage, and no parameter explanations, a one-sentence description is insufficient. It does not explain coordinate interpretation, units, layer defaults, net handling, or the effect of the operation, even though an output schema exists to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 parameters such as coordinates, layer, width, or net. It fails to compensate for the missing parameter documentation, leaving all semantic weight on the raw schema field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Add' and the resource 'single track segment,' communicating the core operation and distinguishing it from bulk operations like pcb_add_tracks_bulk. However, it does not explicitly differentiate from close siblings such as pcb_add_segment or route_single_track, so it is clear but not fully differentiating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 pcb_add_tracks_bulk, pcb_add_segment, or route_single_track. There are no exclusions, prerequisites, or context hints, so the agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a behavioral caveat—'when the runtime supports it'—which goes beyond the destructiveHint annotation. However, it does not disclose what happens when runtime lacks support, whether an existing net class is overwritten, or any side effects. The destructiveHint annotation already flags mutation, but description adds minimal context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only a single sentence, which seems concise but is actually under-specified. It omits essential context about runtime support and net class assignment behavior, making it not appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 2-parameter tool, the description provides almost no operational context. It does not explain the 'runtime' condition, failure modes, or relation to other net class tools. While an output schema exists (covering return values), the description remains incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 compensate for it. It never mentions net_name or class_name, nor how they relate to the assignment operation. The parameter names are self-explanatory from titles, but the description adds no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('Assign a net class') and implies the target is a net via the net_name parameter. It distinguishes itself from sibling tools like route_set_net_class_rules by focusing on assigning a class to a net rather than defining rules. However, the phrase 'when the runtime supports it' introduces ambiguity about conditions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor any prerequisites beyond the vague 'when the runtime supports it.' It lacks context about typical scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure, but it only states that the tool estimates two values. It does not disclose assumptions (e.g., copper resistivity, temperature, uniform trace cross-section), limitations (e.g., accuracy limits, DC vs AC), or return behavior. The word 'Estimate' conveys approximation but little else.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence is efficient but severely under-specifies the tool. It is more under-specification than concise, lacking essential context for a 4-parameter calculation tool. The sentence earns its place but fails to deliver enough substance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a calculation tool with 4 parameters and no annotations, the description is incomplete. It does not cover typical usage scenarios, input constraints, default behavior of copper_oz, or how results are presented. The presence of an output schema helps return-value clarity, but the description still misses calculation assumptions and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 compensate by explaining any parameters. Although parameter names like current_a and trace_width_mm are somewhat self-explanatory, the description adds no semantic value about how these inputs relate to the calculation or how copper_oz affects results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Estimate') and clearly identifies the resource ('DC voltage drop and trace resistance'). It distinguishes this tool from sibling pdn_* tools like pdn_recommend_decoupling_caps or pdn_check_copper_weight by focusing on a calculation rather than recommendations or checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention typical use cases (e.g., power distribution net verification) or contrast with other calculation tools like si_calculate_trace_impedance. Usage must be inferred from the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description must carry the full burden. It only states that the tool uses a 'simple PDN heuristic' to make recommendations, without disclosing side effects (e.g., whether it modifies the design), the nature of the recommendations, or limitations. It does not contradict annotations, but it provides minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action ('Recommend') and avoids redundant wording. It is concise, though it sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters with zero description coverage and no explanation of prerequisites or expected output. Even with an output schema present, the description fails to provide enough context for an agent to correctly invoke the tool, especially given overlapping sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 any of the four parameters (ic_refs, vcc_net, supply_voltage_v, target_ripple_mv). The description adds no meaning beyond the schema's field names, leaving the agent without guidance on required inputs or their formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Recommend'), identifies the resource ('local and bulk decoupling'), and method ('simple PDN heuristic'). It clearly states what the tool does, but does not distinguish it from sibling tools like si_calculate_decoupling_placement or emc_check_decoupling_placement, which may also provide decoupling recommendations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 si_calculate_decoupling_placement, emc_check_decoupling_placement, and pcb_place_decoupling_caps overlap in purpose, but the description lacks selection criteria, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations empty, the description must carry the burden of behavioral disclosure. It implies an update operation but does not state side effects, permissions, rate limits, or what happens to existing context. The mention of 'pushed by KiCad Studio' hints at a prior context but offers no additional transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, using a single clear sentence without redundant information. However, its brevity borders on under-specification, lacking any structural breakdown or additional details that could aid comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, an output schema, and no annotations, the description is notably incomplete. It does not explain the context being updated, parameter behaviors, or expected outcomes, leaving significant gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fails to compensate by explaining any parameters. The single sentence does not mention active_file, file_type, drc_errors, or any other parameters, leaving their semantics entirely to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('update') and resource ('active IDE context pushed by KiCad Studio'), clearly stating the tool's purpose. It distinguishes from siblings by being the only context-related tool, but the term 'IDE context' is not further explained, preventing 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.
Usage Guidelines2/5
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 or how it relates to alternatives. There is no mention of exclusions, prerequisites, or suitable scenarios. The absence of any usage context leaves the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries the full burden of behavioral disclosure. It only says 'review' and 'simple proxy,' without explaining actual analysis steps, thresholds, required layers, or limitations. There is no contradiction with annotations, but the disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff and the action verb is front-loaded. It is appropriately short, though it is so terse that some important context is omitted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists and return values need not be explained, the description lacks selection context, parameter meaning, and a clear definition of the 'void-risk proxy.' It functions as a label rather than a complete guide for an agent deciding whether or how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not mention max_void_area_mm2. The parameter name and default hint at a threshold, but the description adds no meaning and fails to explain how this value influences the check.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Review' and names the resource 'GND plane presence' plus a 'void-risk proxy,' which clearly indicates the tool's focus among EMC sibling checks. However, the phrase 'simple void-risk proxy' is vague and does not specify the exact criteria being evaluated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use guidance or alternative tools are mentioned. Sibling checks like emc_check_return_path_continuity and emc_check_split_plane_crossing are related, but the description does not differentiate this tool from them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description bears full responsibility. 'Return details' implies a side-effect-free read operation, but it does not describe error conditions, required permissions, or what constitutes 'details'. The minimal phrasing adds little beyond 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.
Conciseness4/5
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 appropriately concise for its simple scope, though it sacrifices informative content for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple and has an output schema, the description lacks situational context. It does not mention how this differs from searching symbols or retrieving component details, leaving the agent to infer when this specific lookup is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 parameters. Parameter names (library, symbol_name) are somewhat self-explanatory, but no additional semantics, format expectations, or relationships are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and resource ('details for a single symbol'), which clearly distinguishes it from search-oriented siblings like lib_search_symbols. However, 'details' is somewhat vague and does not differentiate from other detail-returning tools such as lib_get_component_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. With many sibling tools for symbols and components, the description offers no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations include destructiveHint=true, but the description does not explain what destructive side effects may occur, such as overwriting an existing marker or modifying the board file. It adds no behavioral context beyond the annotation, and the word 'Add' does not clarify the destructive aspect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no superfluous words, making it very concise. However, it is so brief that it omits necessary information, though conciseness itself is strong.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with a destructive hint, the description is severely under-specified. It omits barcode format choices, coordinate system, layer semantics, and any side effects. The presence of an output schema covers return values only, not the missing input and behavioral details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the description provides no parameter details. Property names like content, x_mm, y_mm, and barcode_type are self-evident, but the description does not explain value formats, units, coordinate system, or allowed barcode types, which is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and resource ('production barcode marker') with a target location ('board file'), clearly stating the operation. It distinguishes from related tools like pcb_add_text, though it does not explicitly mention alternatives or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternative marker-adding tools (e.g., pcb_add_text, pcb_add_fiducial_marks), and no prerequisites or exclusions are mentioned. Usage is only implied by the tool name and brief description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the pure action of adding a segment. While the destructiveHint annotation is present, the description does not clarify what destructive behavior may occur (e.g., whether it overwrites existing segments). It neither contradicts the annotation nor enriches it with additional details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or repetition. It is appropriately front-loaded and concise, though it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 schema descriptions, but the description provides only a minimal statement. It lacks usage context, parameter explanation, and clarification of the tool's role among many similar pcb_add_* tools. The output schema exists, but the description remains insufficient for an agent to confidently invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate by explaining parameter meanings, but it does not mention any parameters. The schema titles like 'X1 Mm' and 'Y1 Mm' offer some self-evidence, but the description adds no clarification about how coordinates, layer, or width relate to the segment.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add a board graphic segment' clearly identifies a specific action (add) and resource (board graphic segment). The term 'graphic' helps distinguish it from electrical tracks (e.g., pcb_add_track), though it does not explicitly name alternatives. It is specific enough to convey 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.
Usage Guidelines2/5
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 like pcb_add_track or pcb_set_board_outline. There is no mention of intended use cases, prerequisites, or exclusions. It simply states the action without contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare destructiveHint=true, so the agent knows the operation is potentially destructive. However, the description adds no behavioral context beyond that—it does not mention what might be destroyed, whether existing zones are overwritten, or any side effects. The 'arbitrary polygon outline' phrase gives minimal shape context but not meaningful behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and scope. No wasted words or irrelevant details, making it appropriately sized and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no schema descriptions, no visible output schema), the description is far too minimal. It does not explain the return value, clarify the confusion with pcb_add_copper_zone, or provide enough context for correct invocation. The tool is not simple enough for this level of brevity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 compensate. It only hints that corners define a polygon, but does not explain the required format, the meaning of net_name, layer, or any of the other 7 parameters. With 10 parameters and no descriptions, the agent has no semantic guidance, making this a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Add) and resource (copper zone) with a specific scope (arbitrary polygon outline on one copper layer). However, it does not distinguish from the sibling tool pcb_add_copper_zone, which appears to have the same purpose, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like pcb_add_copper_zone or pcb_set_keepout_zone. There is no context about prerequisites, exclusions, or preferred scenarios, so the agent is left without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description fully owns behavioral disclosure. It only states that footprints are 'arranged,' but does not disclose that the tool moves footprints, modifies the board, or what happens with missing refs or mixed-layer footprints. The side effects are not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is concise and front-loaded, but it is under-specified for a tool with four parameters and a destructive/mutating behavior. While there is no wasted text, the description is too terse to be appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool modifies footprints and has four parameters, the description is incomplete. It does not mention board-open requirements, how alignment is determined (e.g., based on current positions or refs), or the effect of spacing_mm and allow_open_board. The presence of an output schema does not relieve the need for usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for parameters, and the tool description does not mention any parameter by name or explain what axis, refs, spacing_mm, or allow_open_board control. The description provides no meaning beyond the schema's parameter titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: arranging selected footprints into a straight row or column. This explicitly distinguishes it from siblings like pcb_move_footprint that move individual footprints. The verb 'arrange' and the resource 'selected footprints' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as pcb_auto_place_by_schematic or pcb_group_by_function. There is no mention of prerequisites or when this should be preferred over other placement tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden. It does disclose a key behavioral trait ('heuristic'), implying the review is an estimate rather than a rigorous compliance check. However, it doesn't state whether the tool is read-only, generates a report, modifies the board, or how results are returned, leaving important 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that front-loads the verb and immediately conveys the purpose. It is appropriately sized for a tool with simple inputs, though it lacks enough detail to be fully informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the three parameters, missing annotations, and no parameter documentation, the description is incomplete. It gives a general sense of the tool's purpose but fails to explain which design aspects are checked, how parameters influence the review, or what the output schema contains, making it only partially useful for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 any of the three parameters. It fails to define voltage_v (units, range), material_group (what the values mean, e.g., IEC grouping), or pollution_degree (environment classification), all critical to using the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Run') and resource ('heuristic creepage clearance review'), which clearly identifies the tool's function. It is distinguishable from sibling tools like emc_check_via_stitching and run_drc, though it doesn't explicitly mention how it differs from those.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, when not to use it, or what prerequisites or context are needed. The description gives no indication of design stage, standards, or expected board state, offering no decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only says 'cluster existing footprints' without explaining side effects, whether it physically moves footprints, whether it modifies the board, or what the output represents. It doesn't disclose any behavioral traits beyond the basic action, leaving uncertainty about mutations or state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single well-formed sentence with no redundant words. However, the brevity leaves it under-specified for the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, no annotations, and an output schema not shown, the one-sentence description is insufficient. It does not cover placement semantics, spacing, board handling, or the meaning of the grouped output, making it inadequate for complex usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 any of the seven parameters. The phrase 'named functional groups' hints at the 'groups' parameter but provides no help for understanding 'grid_mm', 'origin_x_mm', 'origin_y_mm', 'item_spacing_mm', 'allow_open_board', or 'group_spacing_mm'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Cluster') and the resource ('existing footprints') and the outcome ('named functional groups'). It distinguishes this tool from other PCB placement and grouping tools by focusing on grouping by function, though it doesn't explicitly contrast with any sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of prerequisites, scenarios, or exclusions, so an agent has no basis for selecting it over other pcb_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries full responsibility for behavioral disclosure. It reveals that the operation is an 'attempt' and may not be supported, but it does not describe side effects, GUI requirements, or return behavior. This is minimal disclosure beyond the support caveat.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, directly front-loaded, with no filler. Every word is meaningful. It is appropriately sized for a simple operation, though it could have been slightly longer to cover key details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 omits context about when highlighting is supported, what the GUI state impact is, or how errors are surfaced. For a GUI-dependent tool, this is incomplete for an agent to decide when it is safe or appropriate to invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only 'type: string' and title 'Net Name' with no description, and schema description coverage is 0%. The tool description does not elaborate on net_name format, matching rules, case sensitivity, or prerequisites. With 0% coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'attempt to highlight a net in the GUI.' The verb 'highlight' and resource 'net' are specific, and the caveat 'when supported' adds useful context. It is distinguishable from siblings like pcb_get_nets or sch_trace_net, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The only condition is 'when supported,' which is an environment limitation rather than a usage guideline. No exclusions or alternative tool recommendations are given, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description carries the full burden of behavioral disclosure. It does indicate that the tool is mutating ('write') and that it reports a value ('report the current delta'), but it does not explain side effects, whether existing rules are overwritten, or what the delta precisely represents. Key behavioral details such as reversibility, error conditions, or whether the tool modifies the board are absent. This is minimal transparency 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence that immediately conveys the core purpose. Every word earns its place, with no filler or repetition. It is appropriately sized for a tool description and front-loads the essential action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 leaves significant gaps for a tool with four parameters and no annotation support. It does not explain what a 'length-tuning rule' entails, how tolerance and meander amplitude influence the operation, or what 'current delta' means in practice. Given the complexity and the lack of schema descriptions, the description is far from complete. It provides only a high-level summary without enough operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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. However, the description does not mention any of the four parameters (net_name, target_mm, tolerance_mm, meander_amplitude_mm) or how they relate to the described behavior. It only generically refers to 'a net,' providing no meaning for target tolerance or meander amplitude. This is a complete failure to enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: writing a length-tuning rule and reporting the current delta for a net. It uses a specific verb ('write') and resource ('length-tuning rule'), and the outcome ('report the current delta') is explicit. While it does not explicitly differentiate from similar sibling tools like tune_track_length or route_tune_time_domain, the phrasing conveys a distinct action (setting a rule rather than physically tuning a track).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention any prerequisites, context, or exclusionary conditions. It merely states what the tool does, leaving the agent to infer intended usage from the description alone. No alternatives are named, and there is no hint of when this tool is preferred over related tools such as tune_track_length or route_create_tuning_profile.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description bears full responsibility for disclosing behavior. It only states that the tool records intent, but gives no detail on side effects, whether anything is modified, validation performed, or how the recorded intent is used downstream. This is insufficient for an agent to understand operational impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste, but it is under-specified rather than appropriately concise. It lacks structural elements such as parameter details or usage context that would make the sentence more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a relatively simple tool with three parameters, but the description is not complete enough. It omits parameter semantics, usage guidance, and any behavioral consequences. The presence of an output schema does not compensate for the lack of input explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not explain any parameters. The names gate_a, gate_b, and component_ref are self-explanatory only to domain experts, but the description adds no elaboration on what constitutes a gate or how they are identified. The agent is left without essential parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's action ('Record') and resource ('gate-swap back-annotation intent for a multi-unit component'). It distinguishes itself from sibling tools like sch_swap_pins (which actually swaps pins) by emphasizing 'intent' recording rather than performing the swap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, prerequisites, or any conditions. It does not mention that this only records intent and does not physically change the schematic, nor does it direct users to actual swap tools like sch_swap_pins.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Record an intent' suggests a deferred or bookkeeping action rather than an immediate swap, but it does not disclose side effects, validation behavior, whether the schematic is modified, or what the output represents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
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 easily scannable, though its brevity contributes to missing information in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three required parameters, no annotations, and an output schema, but the description gives only the high-level intent. It omits when to use it, what happens after recording, how pins are specified, or any relation to pin-swap-related sibling tools. The output schema exists but does not replace behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 adds that the action is 'for a component' (component_ref), but gives no meaning for pin_a/pin_b, expected formats (e.g., reference designator, pin numbers), or how the pins are identified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Record') and a specific resource ('pin-swap back-annotation intent') for a component, making the core purpose clear. It is distinguishable from sibling sch_swap_gates, though it doesn't explicitly contrast with sch_list_swappable_pins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor any mention of prerequisites like checking swappable pins first. The description implies a use case but provides no explicit conditions, exclusions, or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries the full burden. 'Estimate ... quality' implies a non-mutating analysis, but it does not disclose whether the board is modified, what inputs are validated, what output format is returned, or what assumptions the estimation relies on. This is insufficient behavioral transparency for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler or redundant content. It front-loads the core purpose and is appropriately concise, even though the brevity comes at the expense of other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Though an output schema exists (not shown in this context), the tool remains underspecified: no mention of error conditions, prerequisites, interpretation of the quality estimate, or relationship to other SI/EMC tools. With three required parameters and no annotations, this one-line description is not contextually complete for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the tool description provides no parameter explanations. The agent only sees parameter names (ic_ref, power_pin, target_freq_mhz) and types, with no guidance on units, reference formats, or expected value ranges. The description adds no meaning beyond the schema, which is already bare.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Estimate') and resource ('decoupling placement quality around an IC power pin'), clearly positioning it as an analysis/estimation tool distinct from placement (pcb_place_decoupling_caps) or compliance checking (emc_check_decoupling_placement). However, it does not explicitly differentiate from sibling tools by name or scope, so it falls just short of full clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives like emc_check_decoupling_placement or pdn_recommend_decoupling_caps. It merely states the action without contextual cues, prerequisites, or exclusions, leaving the agent to infer from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the basic action with no mention of side effects, required inputs, defaults, output behavior, or whether it mutates any state. Given the tool's complexity (simulation parameters, probe nets, netlist path), this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, front-loaded with the verb and object. It is free of filler and easy to parse quickly. However, given the tool's 6 parameters and lack of context, the brevity borders on under-specification, though the structure itself is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, no annotations, and output schema exists but is not described. The single-sentence description is far too thin for a parametric simulation tool. It does not explain the sweep semantics, parameter defaults, required setup (e.g., netlist), or how results are returned. This is inadequate for an agent to invoke correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. The parameter names (start_v, stop_v, step_v, source_ref) are somewhat self-explanatory, but probe_nets and netlist_path are not clarified. No defaults, units, or relationships between parameters (e.g., step polarity, inclusive/exclusive bounds) are provided, leaving the agent to infer too much.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Run a DC sweep for an independent source' uses a specific verb ('Run') and resource ('DC sweep for an independent source'), clearly distinguishing it from sibling analysis tools like sim_run_ac_analysis or sim_run_transient. It is concise and unambiguous about the core action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention typical scenarios for DC sweep (e.g., transfer characteristics, operating point vs. sweep), nor does it state any exclusions or prerequisites. The sibling names imply other analyses, but the description itself gives no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries the full burden. It only states that an analysis is run, with no details about side effects, permissions, or requirements. The tool's behavior beyond the name is undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler or redundancy. It is appropriately sized for the minimal information it conveys, though the content is lacking.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simulation tool with two parameters and an output schema, the description leaves out essential context such as how inputs are used and what the analysis entails beyond the name. The output schema provides structure but not conceptual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 probe_nets or netlist_path. The agent receives no explanation of what these parameters mean or how they affect the analysis.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Run a DC operating-point analysis,' which is a specific verb and resource. It distinguishes from sibling simulation tools like sim_run_ac_analysis and sim_run_transient by naming the analysis type, though it does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as sim_run_dc_sweep or sim_run_transient. It does not mention prerequisites, typical use cases, or why one would choose this analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description must carry the burden of behavioral disclosure. It only says 'Validate,' implying a read-only check, but does not describe what the tool returns, how it signals pass/fail, whether it errors, or any side effects. This is minimal and insufficient for a validation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It is appropriately concise, though it omits useful details, making it more under-specified than truly comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters and an output schema, the description is too sparse to be complete. It does not define what 'matched' means, how net groups are evaluated, or what the output schema contains. With no annotations or schema descriptions, this leaves significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 mentions 'net group' and 'supplied tolerance,' providing some meaning for net_groups and tolerance_mm, but it does not explain the structure of net_groups (array of arrays of strings) or how the tolerance is applied (e.g., max-min difference). The parameters remain underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Validate that each net group is matched within the supplied tolerance,' which clearly indicates the tool checks length matching for net groups. It is specific about the resource (net groups) and the condition (tolerance), though it relies on the tool name for the 'length' context and does not explicitly differentiate from similar validation tools like si_check_differential_pair_skew.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention any prerequisites, exclusions, or relationship to sibling tools like si_check_differential_pair_skew or tune_diff_pair_length, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation 'destructiveHint: true' already indicates a mutating operation. The description adds no further behavioral details, such as what happens after setting the active variant, whether it can be undone, or what downstream operations are affected. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste, but it is under-specified. While brevity is good, the lack of detail means it does not serve as an effective standalone explanation. It is concise but sacrifices necessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a destructive annotation and an output schema, but the description does not cover parameter meaning or usage context. For a simple setter, the missing 'name' semantics and lack of guidance about the impact on the design make the description incomplete for proper invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'name' with 0% schema description coverage. The description does not explain what 'name' refers to (e.g., variant name from variant_list), its format, or that it must correspond to an existing variant. The description provides no compensating information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and resource ('active design variant') with scope ('current project'), clearly distinguishing this from sibling tools like variant_create, variant_list, and variant_set_component_override. It unambiguously states 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.
Usage Guidelines2/5
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. The description does not mention prerequisites, exclusions, or relationships to other variant tools. The agent has no context for appropriate selection beyond the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries the full burden of behavioral disclosure. It does not explain what 'minimal project structure' includes, what 'activate' entails, whether existing files are overwritten, or any side effects on the current working project. The description is too brief to inform the agent of important behavioral consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. It is appropriately short and front-loaded, but it sacrifices critical details in favor of brevity. Still, it earns its place as a clean statement of the tool's primary function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations and an output schema, the description is too sparse. It leaves open key questions: what files are created, does it require an empty directory, how does it affect the current project, and what does 'activate' mean exactly. The description does not provide enough context for an agent to understand the full scope of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no meaning to the parameters 'name' and 'path'. It does not clarify whether 'path' is a directory or a file path, what 'name' represents (project name, file name, etc.), or any format constraints. The description fails to compensate for the lack of schema parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 resource 'new minimal KiCad project structure' and includes 'activate it', which distinguishes it from sibling tools like kicad_set_project (which activates an existing project) and kicad_get_project_info (which retrieves info). The scope is clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or contrast with related tools such as kicad_set_project. The usage context is only implied by the name and the verb 'create', which is insufficient for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true already signals the destructive nature. The description adds no further behavioral context, such as stackup requirements, reversibility, or potential DRC impacts, so it provides no value beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. Every word contributes to stating the tool's core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter CAD mutation tool with no parameter explanations and no usage guidance, this one-sentence description is severely incomplete. The output schema and destructive annotation do not compensate for the missing operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only mentions 'requested copper layers' generically. It does not explain x_mm, y_mm, drill_mm, diameter_mm, net_name, or the layer parameters, so the agent gets no help understanding the 7 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and resource ('blind or buried via between the requested copper layers'), clearly distinguishing this from sibling tools like pcb_add_via or pcb_add_microvia by via type and layer span.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. It only restates the operation, leaving the agent to infer usage from the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation openWorldHint=true hints at side effects, but the description adds no behavioral context such as file creation, overwrite behavior, or default output location. It does not contradict annotations, but the low additional value warrants a below-average score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler. It is appropriately concise for a simple tool, though it sacrifices detail that other dimensions need.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 fails to cover essential context like the effect of board_only, the role of output_path, and any prerequisites for the active PCB. This makes the tool under-specified for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the two parameters (board_only, output_path). The agent cannot infer what board_only controls or what happens when output_path is empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (export), the target resource (active PCB), and the output format (KiCad 10 3D PDF). This is specific enough to distinguish from sibling export tools like export_pcb_pdf or export_3d_step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description does not mention use cases, prerequisites, or exclusions, leaving the agent without explicit decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It does not disclose side effects (e.g., updating existing position, whether rotation is preserved), coordinate origin, or any impact on the design.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, directly worded sentence with no filler or repetition. It is front-loaded with the verb and quickly conveys the essential action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simplicity of the operation, the description is under-specified for a PCB tool. It does not mention the coordinate system, units, or optional rotation. The output schema exists but is not described, and there are no annotations to fill the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no explanation of parameters beyond the schema names. It doesn't clarify that reference is the designator, x_mm/y_mm are coordinates, or what rotation_deg does. The schema itself has 0% description coverage, so the description must compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (move) and resource (footprint), and specifies absolute location, making the core purpose unambiguous. However, it does not distinguish from similar sibling tools like pcb_align_footprints or pcb_auto_place_by_schematic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention prerequisites, when not to use it, or how it compares to other placement tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true already signals the destructive nature, but the description adds no behavioral context, such as whether the existing outline is replaced or how the origin is interpreted. It provides little beyond what the annotation already states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. However, it is almost too terse, sacrificing necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with four parameters, the description is minimal. It does not cover coordinate system, default behavior, or parameter semantics. The description is too incomplete to fully support correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter descriptions (0% coverage), and the description does not explain any of the parameters. While width and height are somewhat inferable from the tool name, origin_x_mm and origin_y_mm are completely unexplained, leaving the agent without essential information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool draws a rectangular board outline on the Edge.Cuts layer. The verb 'Draw' and the specific resource 'rectangular board outline on Edge.Cuts' make the purpose unambiguous and distinguish it from other PCB shape tools like pcb_add_rectangle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as pcb_add_rectangle or other PCB drawing tools. It does not mention prerequisites, context, or 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true, and the description says 'Write', which is consistent but not contradictory. However, the description does not disclose the scope of the write (e.g., overwrites all existing rules), whether unspecified parameters are reset to defaults, or if the file is saved immediately. This adds minimal value beyond the destructive hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, grammatically complete sentence that is compact and front-loaded. Every word contributes to stating the tool's purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with an output schema and destructiveHint annotation, the description lacks essential context for a mutation tool. It does not explain what happens to existing design rules, how defaults are applied, or whether an active board is required. This is incomplete for a tool that modifies persistent state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not compensate by explaining any of the six parameters. While parameter names like 'min_clearance_mm' are self-explanatory, the description itself adds no meaning beyond saying 'manufacturing constraints'. This is insufficient for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Write') and the target resource ('board-level manufacturing constraints into the active .kicad_dru file'). This is specific enough to understand the tool's function. However, it does not explicitly differentiate from sibling tools like drc_rule_create or pcb_get_design_rules, though the name and context provide some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of prerequisites, whether it should be used before manufacturing, or any exclusions. The only implied context is that it writes to the active design rules file, but no explicit usage direction is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states 'create or update' but does not explain whether updating overwrites existing profiles, whether it is idempotent, or what side effects occur. This lack of detail is insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action ('Create or update') and specifies the resource. It avoids filler, making it efficient, though it could be expanded with useful detail without becoming overly long.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 required parameters, no parameter descriptions, and no annotations, yet the description offers minimal context. It does not explain what a tuning profile is, the role of this tool in the routing workflow, or what the output contains, despite having an output schema. The description is incomplete for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 undocumented parameters. It fails to explain what 'layer', 'trace_impedance_ohm', or 'propagation_speed_factor' mean, their units, or how they relate to a time-domain tuning profile. The description adds no meaning beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb phrase ('Create or update') and a clear resource ('KiCad 10-style time-domain tuning profile'). It distinguishes from sibling tools like route_list_tuning_profiles and route_apply_tuning_profile by focusing on creation/update rather than listing or applying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as route_apply_tuning_profile or route_tune_time_domain. It does not mention when creating vs updating is appropriate, nor any prerequisites or context for using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavioral note that the requested shape and rotation are preserved, which is useful beyond the annotation's destructiveHint. However, it doesn't clarify what destructive operations might occur or whether existing labels are overwritten. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 12-word sentence, extremely concise. However, it is under-specified for a tool with 6 parameters and minimal sibling differentiation, making it more terse than effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite an output schema, the description fails to explain what a global label is, when it should be used, or how it differs from other label types. The context of two sibling label tools demands more detail for correct tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate for the 6 parameters. It only mentions shape and rotation, leaving text, x_mm, y_mm, and snap_to_grid semantically unexplained. While coordinates are self-explanatory, the lack of any mention of text or snapping behavior is a gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (add) and the resource (a global label), and adds a specific detail about preserving shape and rotation. It distinguishes from siblings like sch_add_label and sch_add_hierarchical_label by the 'global' qualifier, though it doesn't explain what global means in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like sch_add_label or sch_add_hierarchical_label. The description does not mention prerequisites, typical scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true aligns with the 'Add' action, but the description adds no further behavioral context. It does not explain what a jumper symbol consist of, how pins or open_by_default affect the result, or any side effects beyond the annotation. The agent is left without insight into the tool's runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff or redundant phrasing. It is front-loaded and efficient. While it is under-specified, that issue is addressed under completeness rather than conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a 5-parameter schema with no parameter descriptions, a minimal annotation set, and moderate complexity (pins, open_by_default). The description only states the core action and omits placement, options, and behavior. Even with an output schema present, the input semantics and usage context are severely incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 5 parameters and 0% schema description coverage, the description must compensate for missing parameter explanations. It does not mention x_mm/y_mm, pins, snap_to_grid, or open_by_default at all. The agent cannot infer parameter meanings or required values from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'Add a jumper symbol to the schematic.' It uses a precise verb and noun, distinguishing it from sibling tools like sch_add_symbol or sch_add_wire. The resource and location are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when a jumper symbol is appropriate, or why one would choose this over sch_add_symbol or other sch_add_* tools. No exclusions or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description must carry the burden of behavioral disclosure. It only says 'Preview', implying non-destructive, but does not explicitly state read-only behavior, side effects, or operational requirements. The lack of detail about how a preview is generated or whether it modifies anything is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no waste. It front-loads the core purpose effectively. However, it is almost too concise, sacrificing valuable usage and parameter context for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters, empty annotations, and an output schema, the description is too sparse. It does not explain what inputs are expected, what the output represents, or any preconditions. This incompleteness undermines an agent's ability to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 7 parameters (nets, wires, labels, symbols, auto_layout, snap_to_grid, power_symbols). It adds no meaning beyond the parameter titles, leaving the agent to guess what each input represents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Preview') and resource ('netlist-aware schematic compilation' resolving endpoints and wires), which distinguishes it from other schematic analysis tools like sch_trace_net or sch_get_connectivity_graph. It unambiguously indicates a non-mutating analysis action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives, no prerequisites, and no exclusions. It simply states what the tool does without contextualizing its place among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true already signals mutation, but the description adds no extra behavioral context. It does not explain what happens to an existing property when updated (e.g., overwrite), nor does it mention side effects or validation. The description simply restates the action without enriching the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, front-loaded with the verb and object. Every word is meaningful; there is no redundancy or filler. This is ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with three required parameters and a destructive hint, the description is too sparse. It omits crucial information such as valid property names, whether the symbol must exist prior to update, and the scope of 'placed symbol' (e.g., on which sheet). The presence of an output schema reduces the need to explain return values, but the operational context is still incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate by explaining the parameters, but it does not. While 'field', 'value', and 'reference' are somewhat self-explanatory, the description fails to clarify that 'reference' identifies the placed symbol, 'field' is the property name, and 'value' is the replacement value. This leaves ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update a property on a placed symbol' clearly identifies the action (update) and the target (property on a placed symbol). It is specific enough to distinguish from most sibling tools, though it does not explicitly differentiate itself from other update-like schematic tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, prerequisites, or alternatives. It lacks any contextual hints such as 'to modify symbol position use sch_move_symbol' or required prior steps like placing a symbol.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. It only hints at approximation via 'Estimate' and 'quasi-static', but does not disclose what the tool returns, what trace_type options are supported, or any limitations of the formulas. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately conveys the tool's core function without any filler. It is front-loaded and every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters, no annotations, and no parameter descriptions, the description is severely incomplete. It fails to explain input semantics, supported trace types, or how results should be interpreted, even though an output schema exists it does not compensate for the missing parameter context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 six parameters. It adds no meaning beyond the raw schema, so an agent has no help understanding width_mm, height_mm, copper_oz, spacing_mm, or trace_type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool estimates PCB trace impedance, a specific calculation distinct from inverse or extraction tools like si_calculate_trace_width_for_impedance and pcb_get_impedance_for_trace. The verb 'Estimate' and resource 'PCB trace impedance' provide a precise, unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention that si_calculate_trace_width_for_impedance is the inverse operation or that pcb_get_impedance_for_trace retrieves impedance from an existing board, leaving all usage context to be inferred from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries the full burden of behavioral disclosure. While 'check' implies a read-only operation, the description does not explain criteria for 'obvious', any limitations, side effects, or how the result is presented. It does not contradict annotations but fails to add substantive behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no fluff or repetition. It is front-loaded and easy to parse, but it is slightly under-specified, which prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given empty annotations, a minimal schema, and an output schema that likely describes results, the description is still under-specified. It does not explain the reference_plane_layer parameter, the operational meaning of 'obvious', or how this check fits within the broader EMC workflow. The lack of detail makes it incomplete for reliable tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 explicitly explain the parameters signal_net and reference_plane_layer. It mentions 'signal' and 'GND return plane' but does not directly map them to the parameter names or explain how the reference_plane_layer is used. The agent must infer parameter meaning from names and the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: checking whether a signal has an obvious nearby GND return plane. It uses a specific verb ('check'), a resource ('signal'), and a distinct scope ('return path continuity') that differentiates it from sibling EMC tools like emc_check_ground_plane_voids or emc_check_split_plane_crossing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There are no prerequisites, exclusions, or references to related tools. An agent is left to infer the appropriate context from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description is the sole source of behavioral disclosure. It only states the estimation purpose and the input source (existing ground vias), but does not disclose whether the tool is read-only, what data it accesses, any side effects, or how the estimation is performed. This leaves significant ambiguity for a check tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence of eight words, with no filler or redundancy. It is front-loaded and easily parsed. However, its brevity borders on under-specification, though the sentence itself is well-formed and purposeful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists (reducing the need to describe return values), the description is incomplete for a tool with two parameters and no annotations. It lacks usage guidelines, parameter explanations, and behavioral context. Compared to sibling tools like emc_check_differential_pair_symmetry, this description is minimal and likely insufficient for an agent to select and use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not mention the parameters 'ground_net' or 'max_gap_mm' at all. The parameter names and defaults provide some intuitive meaning (e.g., ground net name and maximum gap in mm), but the description fails to explain their relationship to via-stitching density or how max_gap_mm is used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool estimates via-stitching density using existing ground vias, with a specific verb ('estimate') and resource ('via-stitching density'). This distinguishes it from sibling EMC check tools like emc_check_ground_plane_voids or emc_check_return_path_continuity, which address different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention any prerequisites, exclusions, or alternative tools. The only implied usage is from the name/description itself, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate openWorldHint and destructiveHint, so the agent knows this tool has side effects. However, the description adds no additional behavioral context—no mention of file overwriting, directory creation, or impact on current project state. It merely restates the tool's basic function without enriching beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and object with no filler. It is concise and easy to parse, making it efficient for an agent to quickly understand the basic operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two optional parameters and a destructive hint, the description is too sparse. It does not explain how the tool selects layers or where output goes, and it fails to clarify the default behavior. The existing annotations and output schema do not compensate for the missing param semantics and usage guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (layers, output_subdir) with 0% schema description coverage. The description does not explain what layers represents, what values are valid, or how output_subdir is used. The agent is left to infer parameter semantics from names alone, which is inadequate for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports Gerber manufacturing files, with a specific verb ('Export') and resource ('Gerber manufacturing files'). This distinguishes it from sibling export tools like export_drill, export_bom, or export_netlist. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as export_manufacturing_package or export_ipc2581. It does not mention prerequisites, typical workflows, or situations where a different export 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. While annotations declare destructiveHint=true and openWorldHint=true, the description doesn't explain what side effects (e.g., file overwriting) might occur, which is a notable gap for a destructive tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence—but it's arguably under-specified. It repeats the tool name's content without adding meaningful elaboration, which means it doesn't fully earn its place as an explanatory description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params) and the annotations, a minimal description might suffice. However, the description lacks context about the output format, the difference from export_netlist, or any destructive behavior, leaving the agent under-informed for a tool marked as destructive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to explain. The input schema is empty and the description correctly avoids adding unnecessary detail. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (export) and the resource (a SPICE netlist), using a specific verb+resource pattern. However, it doesn't explicitly differentiate from sibling export tools like export_netlist beyond the 'SPICE' qualifier, so it's not as strong as a fully distinguishing description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of prerequisites, typical scenarios, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description alone must disclose behavior. It does mention conditional availability ('when available'), but it does not explain what happens when no datasheet URL exists, whether it returns the first or all URLs, or if errors occur for invalid library/symbol names. The disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. Every word contributes to the core purpose, making it appropriately sized for a simple retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 covered elsewhere. The description plus schema gives a workable picture of the tool's core function, but it omits failure behavior and usage context. This is adequate but not rich for a tool with empty annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 adds 'from the symbol library' as a loose clue, but it does not explain the expected format or relationship between 'library' and 'symbol_name'. The parameter names are self-explanatory, but the description fails to fill the schema's descriptive gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Return') and the specific resource ('datasheet URL from the symbol library'). The qualifier 'when available' adds useful scope. While it doesn't explicitly name sibling alternatives, the function's unique focus on datasheet URLs distinguishes it from other library tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like lib_get_symbol_info or lib_search_symbols. There are no prerequisites, exclusions, or context for when it is appropriate, leaving the usage entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the openWorldHint annotation. It does not mention potential side effects like file creation or overwriting, whether it requires an existing KiCad project, or what happens on success/failure. This is a significant gap for an import tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core action without redundant words. However, it is too sparse to fully support agent decision-making, but for what it covers, it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an import tool with side effects, no parameter descriptions, and a rich set of sibling import tools, the description is extremely incomplete. It omits prerequisites, output handling, error scenarios, and interaction with the KiCad project, leaving the agent with insufficient information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters but only hints that geda_pcb_path is the input file and output_dir is the output directory. It does not clarify defaults, formats, or relationships, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool imports a gEDA PCB into a KiCad project directory. It uses a specific verb ('Import') and names the resource ('gEDA PCB') and destination, distinguishing it from sibling import tools like mfg_import_allegro and mfg_import_pads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no prerequisites, and no exclusions. It simply states the function without context on selection criteria or expected input/output.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and idempotentHint, covering the safety profile. However, the description adds no behavioral context beyond that—no mention of pagination, filtering behavior, or scope of results. It is a minimal statement that does not enrich the agent's understanding of tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded and easy to parse. This is an example of appropriate conciseness, even if more context could be added elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are 4 parameters with no descriptions and an output schema, the description is overly terse. It does not mention pagination, filtering options, or what 'tracks' includes. While the output schema exists and covers return values, the lack of usage context and parameter explanation leaves the agent under-informed for a tool with multiple optional arguments.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter semantics. The schema's property names (page, page_size, filter_net, filter_layer) give some hints, but the description does not explain their meaning, defaults, or how they affect results. The description completely fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List board tracks.' uses a specific verb (List) and resource (board tracks), clearly distinguishing it from sibling tools like pcb_get_nets or pcb_get_zones. It is immediately obvious what this tool does without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives. It does not mention scenarios, prerequisites, or exclusions. The description is purely functional and leaves the agent without direction on selecting this over other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries the full burden. It only states the action and does not disclose side effects, reversibility, how the placement is determined, or how parameters like side or allow_open_board affect the outcome.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently states the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 6 parameters, empty annotations, and no parameter descriptions, this one-sentence description is insufficient. It does not cover the placement algorithm, constraints, or behavior for optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 6 parameters with 0% description coverage, and the description fails to explain any of them. It only implies ic_ref and cap_refs, leaving side, grid_mm, max_distance_mm, and allow_open_board without meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Move') and identifies the resource ('capacitor footprints') and the target placement ('tight row near a target IC footprint'). This clearly distinguishes it from sibling tools that recommend or check decoupling placement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternative decoupling-related tools such as pdn_recommend_decoupling_caps or emc_check_decoupling_placement. It does not specify prerequisites (e.g., caps selected, board loaded) or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only states the basic action without mentioning side effects (e.g., whether it replaces existing copper, clearance behavior, DRC implications, or whether it is destructive).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no fluff. It is concise, but the brevity comes at the cost of completeness; however, conciseness itself is well-handled.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations and an output schema, the description should provide more context about the operation's impact and requirements (net, clearance). It currently omits these critical details, leaving an agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 'layer' parameter via 'requested copper layer' but does not explain 'net_name' or 'clearance_mm' at all. This is inadequate for a tool with required parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Generate') and a specific resource ('rectangular copper plane') with a scope ('on the requested copper layer'). It clearly distinguishes this from other tools by specifying the shape and purpose, even though it does not mention the word 'power' explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like pcb_add_copper_zone or other PDN tools. It does not state prerequisites, exclusions, or any recommended context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true signals potential destructive behavior, and the description does not contradict it. The statement that design intent is 'used by placement, routing, and release-quality gates' adds context about downstream impact, but the description does not disclose whether setting this replaces all existing intent or merges with it, nor any specific destructive effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: a concise purpose statement followed by two categorized parameter lists. The parameter enumeration is necessary given the schema's lack of descriptions, and the v1/v2 grouping aids scanning. No redundant filler is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (16 optional parameters, 0% schema coverage, and many related sibling tools), the description is insufficient. It lacks parameter definitions, behavioral details about overwriting/merging, and integration guidance with get/infer/validate sibling tools. The presence of an output schema and annotations mitigates only slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists parameter names grouped into v1 and v2, and for v2 provides type hints like 'list of PowerRailSpec dicts' and 'MechanicalConstraint dict.' With 0% schema description coverage, the description must compensate, but it fails to define what these params mean or what fields the dicts require, leaving significant ambiguity for a 16-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Store high-level design intent used by placement, routing, and release-quality gates,' which specifies a verb and resource. However, it does not explicitly distinguish itself from sibling tools like project_get_design_intent or project_infer_design_spec, relying on the tool name to convey the setter role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The v1/v2 parameter distinction explains which parameters apply to which project types, but there is no mention of when to prefer this over project_get_design_intent, project_infer_design_spec, or project_validate_design_spec.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare destructiveHint=true, and the description's 'Write' action aligns with that without contradiction. The description adds the context that it targets the 'active .kicad_dru file', which is useful. However, it does not disclose whether this overwrites the entire file, only the specified net class section, or whether existing rules are merged or replaced, leaving important behavioral details unclear 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and target. Every word provides meaning, and there is no redundant fluff. It is appropriately sized for the tool's apparent simplicity, though it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, five required parameters, and no parameter descriptions, the description is notably incomplete. It identifies the target file but does not explain the write semantics (overwrite vs. merge), prerequisites, or the impact on existing design rules. The sibling context includes many routing and design-rule tools, but with only this description an agent lacks enough context to safely invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter schema coverage is 0% and the description provides no parameter information whatsoever. The description does not mention the five required parameters (net_class, width_mm, clearance_mm, via_diameter_mm, via_drill_mm) or explain how they map to routing constraints, units, or validation rules. This is a complete failure 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Write net-class routing constraints into the active .kicad_dru file.' This clearly identifies the action and target file. However, it does not explicitly distinguish this from the sibling 'pcb_set_net_class', which could be confused as setting net-class properties rather than writing routing constraint rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'pcb_set_design_rules' or 'pcb_set_net_class'. There is no mention of prerequisites (e.g., needing an active project or design rule file) or when writing directly to the .kicad_dru file is appropriate versus using other rule-setting tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the only source of behavioral info. It states the rule is 'inspired by KiCad 10' and has a 'length fallback', but doesn't explain side effects, whether it modifies PCB design rules, or what the fallback entails. This is a creation tool with no disclosure of project impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no redundancy, front-loading the action and key modifiers. Every word earns its place without being over-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations, the description leaves out critical context: what file/project it affects, prerequisites, and behavior of the fallback. The presence of an output schema doesn't compensate for the missing operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds no parameter information. The parameters are self-explanatory by name but the 'length fallback' hints at a length parameter that isn't present, creating confusion. The description 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('time-domain tuning rule'), and distinguishes from sibling tools like route_tune_length by mentioning 'time-domain' and 'length fallback'. However, 'KiCad 10-inspired' is vague and could confuse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for time-domain tuning with a length fallback, but does not explicitly state when to prefer this over length tuning or other SI tools. No alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint: true is present, and the description adds the default snapping behavior to the 2.54 mm grid, which is useful context. There is no contradiction with the annotation, but no additional behavioral details such as side effects or prerequisites are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It is extremely concise and structurally efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters, outputschema, and several sibling label tools, the description is too terse. It lacks guidance on label type selection, coordinate system, or interactions with the destructiveHint annotation. An output schema exists, but contextual usage is still incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 hints at snap_to_grid via 'snapping its anchor to the 2.54 mm grid by default,' but fails to explain the required parameters (name, x_mm, y_mm) or rotation. This provides minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a schematic label, with a specific verb and resource. However, it does not differentiate from sibling tools like sch_add_hierarchical_label or sch_add_global_label, so it lacks explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, or when to set snap_to_grid to false. The description simply states what the tool does without providing contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Solve for...' without mentioning the return format, units, error handling, or any constraints on inputs. It does not reveal what happens for invalid inputs or whether it returns a single value or multiple solutions, so it is minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It is appropriately concise for conveying the core purpose, even if it sacrifices depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 too thin for a design calculation tool with six parameters. It does not explain how parameters interact, which defaults are relevant, or when to choose different trace types. The minimal context leaves significant gaps for an agent to execute correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no additional meaning for the six parameters. Domain-specific terms like 'er', 'copper_oz', and 'trace_type' are not explained, and the description does not compensate for the lack of schema-level descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: solving for a trace width given an impedance target. The verb 'Solve for' plus the resource 'trace width' makes it specific, and it naturally distinguishes itself from the sibling tool si_calculate_trace_impedance, which performs the inverse calculation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like si_calculate_trace_impedance. The description simply states what it does without context, prerequisites, or exclusions, leaving the agent to infer usage from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the function but does not disclose whether the tool modifies the design, how 'practical' is determined, or any input constraints or side effects. The one-liner adds minimal behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It is front-loaded and structurally clean, but its brevity sacrifices explanatory content. For what it is, it earns high marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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: when to use this tool versus related SI tools, how parameters influence the recommendation, and what 'practical' means. The agent is left without enough guidance for correct invocation in varied scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 any of the 5 parameters (er, copper_oz, layer_count, manufacturer, target_impedance_ohm). The only weak hint is 'target trace geometry', which loosely relates to target_impedance_ohm, but this is insufficient for an agent to understand parameter meaning or relationships.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Generate' and the resource ('practical board stackup recommendation and target trace geometry'). It distinguishes this tool from related siblings like si_calculate_trace_impedance (which computes impedance) and si_synthesize_stackup_for_interfaces (which targets interfaces specifically).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like si_calculate_trace_impedance or si_synthesize_stackup_for_interfaces. It doesn't mention contexts, prerequisites, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries full burden. It discloses that the tool performs a write operation on the active .kicad_dru file, but it does not explain whether it overwrites existing rules, how 'update' is determined, any validation behavior, permission requirements, or 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately states the action and target. It contains no unnecessary words and is appropriately concise for the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, 0% schema descriptions, no annotations, and only a one-sentence description, the tool is severely under-specified. The description does not explain required vs optional parameters, valid values for constraint_type, how create differs from update, or any preconditions beyond 'active .kicad_dru file'. This is inadequate for reliable tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for 6 parameters, and the description provides no parameter details whatsoever. It does not mention constraint_type, name, severity, condition, min_value, or max_value, leaving the agent without guidance on what each parameter means or how to set them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs 'Create or update' with a clear resource ('custom DRC rule') and location ('active .kicad_dru file'). This clearly distinguishes it from siblings like drc_rule_delete, drc_rule_enable, and drc_list_rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: use this tool when you need to create or update a custom DRC rule. However, it provides no explicit when-to-use/when-not-to-use guidance or mention of alternatives, so it falls short of clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries full responsibility for behavioral disclosure. It implies a review/check but never explicitly states that it is read-only, what threshold defines 'nearby,' or what the output represents beyond the existence of checks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler or redundant wording. It is front-loaded and appropriately sized for a simple check tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 an output schema exists to define return values. However, it omits the configurable distance threshold and any context about scope (all ICs vs. selected) or its relationship to sibling EMC and signal-integrity checks, making it minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions max_distance_mm or explains how 'nearby' is quantified. The parameter's meaning is left entirely to the schema title and default value, contrasting with the rule that low-coverage descriptions must compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Review') and clearly identifies the resource ('whether ICs have nearby decoupling capacitors'). It effectively distinguishes this check from sibling tools like pcb_place_decoupling_caps (placement) and pdn_recommend_decoupling_caps (recommendation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the many related EMC or decoupling tools. The description does not mention prerequisites, alternatives, or how this check fits into a broader compliance workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and idempotentHint, covering the safety profile. The description adds the word 'Estimate', which provides a small behavioral hint about result accuracy, but it does not disclose any additional behaviors such as dependency on stackup configuration, potential for errors, or whether the estimate is based on specific formulas. While not contradictory, it adds minimal value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no redundant words, making it highly concise and front-loaded. However, it is terse to the point of omitting valuable context captured in other dimensions, though that is a trade-off with conciseness rather than a flaw in structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple read-only operation with a 2-parameter schema and an output schema present, which reduces the need to describe return values. However, the description lacks usage guidance, parameter semantics, and differentiation from similar siblings, making it only minimally complete for an agent to use correctly in all situations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, so the description must compensate for explaining the parameters. It references 'supplied width' and 'named stackup layer', which map directly to width_mm and layer_name, but does not add meaningful semantics such as units, allowed values, or how the layer name relates to the stackup. This is insufficient to fully understand the parameters beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Estimate trace impedance') and the inputs ('supplied width on the named stackup layer'). It distinguishes the tool's scope by mentioning the stackup layer, but does not explicitly differentiate it from the sibling tool si_calculate_trace_impedance, which likely performs a similar calculation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as si_calculate_trace_impedance or si_calculate_trace_width_for_impedance. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer the use case solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint, so the safety profile is covered. However, the description adds no behavioral context, such as what happens when save_report is true, whether it changes the board, or how results are returned. It simply restates the tool's name without disclosing side effects or output behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that is entirely relevant and front-loaded. No filler or redundant phrasing exists, making it maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional boolean parameter) and the presence of annotations and an output schema, the description is minimally adequate. However, it lacks any indication of when to use the tool, how the save_report parameter behaves, or what the output represents, leaving gaps in context. It is complete enough for a straightforward invocation but not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 save_report parameter at all. The parameter name is somewhat self-explanatory, but the description adds no meaning beyond what the schema's name and default convey. With 0% coverage, the description fails to compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: running PCB design rule checks. This distinguishes it from sibling tools like drc_list_rules (which lists rules) and run_erc (which runs electrical rule checks), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like drc_list_rules or validate_design. It does not mention prerequisites, whether it runs all checks or only enabled ones, or when to prefer this over other DRC-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description carries the full burden of behavioral disclosure. It states the purpose but does not clarify whether the tool runs a simulation internally, requires an existing sweep, modifies anything, or produces side effects. This lack of detail is significant for a simulation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no redundancies or filler. It is front-loaded with the key action and target, making it easy to parse, though the extreme brevity leaves out important supporting details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with an output schema present, the description is inadequate for a 6-parameter simulation tool. It omits parameter semantics, usage prerequisites, and behavioral expectations, making it insufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 6 parameters with 0% schema description coverage, and the tool description mentions none of them. It does not explain the role of output_net, feedback_net, or the frequency settings, leaving the agent without any added meaning beyond field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Estimate') and clearly identifies the resource ('loop crossover and phase margin from an AC sweep'). It distinguishes this tool from sibling simulation tools like sim_run_ac_analysis or sim_run_transient, which focus on generating sweep data rather than deriving stability metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'from an AC sweep' implies that an AC sweep should exist or be performed, providing some contextual guidance. However, there is no explicit instruction on when to use this tool versus sim_run_ac_analysis, nor any prerequisites or exclusions stated, so the guidance remains largely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description provides minimal behavioral detail. It does not disclose side effects, whether state is modified, error handling, or what happens if the manufacturer is not supported. The word 'bundled' suggests a limited set of profiles, but no list or discovery mechanism is described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and free of fluff. It conveys the core action efficiently and earns its place without unnecessary detail, fitting within expectations for a simple loader tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two optional parameters and an output schema, the description gives the basic idea but misses important context: how to discover valid manufacturer names, what 'bundled' profiles exist, whether the profile is applied immediately or held for later, and what the output schema returns. It is adequate but leaves gaps for an agent to operate reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should compensate, but it does not mention the 'tier' or 'manufacturer' parameters at all. The parameter names are somewhat self-explanatory, but valid values, defaults, and their impact on the loaded profile are left undocumented, relying entirely on the agent's inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it loads a bundled manufacturer DFM profile for subsequent checks. It uses a specific verb ('load') and resource ('bundled manufacturer DFM profile'), and the phrase 'for subsequent checks' distinguishes it from sibling tools like dfm_run_manufacturer_check which actually execute checks. However, it could be more explicit about what the profile contains or what checks it applies to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage before running DFM checks ('for subsequent checks'), but it does not explicitly say when to use this tool versus alternatives like dfm_run_manufacturer_check or dfm_calculate_manufacturing_cost. No exclusions or prerequisites are mentioned, leaving the agent to infer the typical workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. While the annotations already indicate destructiveHint and openWorldHint, the description does not explain what 'standard set' means, whether existing files are overwritten, or what side effects occur. It is essentially a restatement of 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is easy to parse. It is appropriately concise for a zero-parameter tool, with no wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is vague about what constitutes the 'standard set' of manufacturing exports, which is critical given the many individual export tools. It does not mention output types, file destinations, or the scope of the package. Even with an output schema present, the description leaves the tool's behavior under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so there is no parameter meaning to clarify. The description does not need to compensate for schema gaps because none exist. A baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Generate') and a resource ('standard set of manufacturing exports'), making it clear the tool produces a package of export files. However, it does not explicitly distinguish itself from sibling export tools like export_gerber or export_bom, relying on the name 'package' to imply aggregation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the many individual export tools (e.g., export_gerber, export_drill, export_pick_and_place). It does not mention prerequisites, alternatives, or scenarios where this package export is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Check live stock availability' but does not disclose whether this queries an external service, what errors might occur, or how 'live' updates work. There is no mention of the source parameter or any potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 appears simple, the description lacks usage context and parameter semantics. It does not situate the tool among its many library-related siblings or explain prerequisites like which component references are expected. This leaves the agent under-informed for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 'refs' as 'schematic references', but it does not mention the 'source' parameter at all, leaving its meaning and default behavior unexplained. The description adds minimal value beyond the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Check') and resource ('live stock availability') for 'requested schematic references'. This clearly distinguishes it from sibling tools like lib_find_alternative_parts (finding alternatives) and lib_get_bom_with_pricing (BOM pricing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. Although the purpose is clear, the description does not mention that this is for checking stock before ordering, nor does it reference alternatives like lib_find_alternative_parts when stock is unavailable. No context 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations only provide openWorldHint, which does little to characterize behavior. The description lacks any disclosure about potential overwrites, required project state, format conversion limitations, or error conditions. It reads as a bare statement of intent with no side effects or edge cases noted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It is appropriately concise for a straightforward import operation, though brevity comes at the cost of detail evaluated elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 minimal and fails to convey prerequisites, default behavior for output_dir, or any nuances of Allegro import. For a tool with two parameters and no schema descriptions, this is insufficient to guide an agent on correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 compensate by explaining the parameters. It does not mention 'output_dir' or 'allegro_brd_path' at all, leaving their semantics entirely to the schema titles and names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Import') and resource ('Allegro board') with a clear destination ('KiCad project directory'). This unambiguously distinguishes it from sibling import tools like mfg_import_geda and mfg_import_pads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when importing an Allegro board) but gives no explicit context, prerequisites, or exclusions. It does not mention alternatives or when not to use it, such as checking support via mfg_check_import_support first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint: true already signals destructiveness, but the description adds no context about what specifically might be altered, whether existing fiducials are replaced, or if any prerequisites exist. For a mutation tool with minimal annotation context, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. However, it is perhaps too short for the level of complexity, but that is more a completeness issue than conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters (all with defaults) and a destructive annotation, but the description gives no information on parameter semantics or side effects. An agent cannot accurately invoke this tool without guessing at parameter meanings, making the description insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description needed to explain 'count', 'margin_mm', 'diameter_mm', and 'allow_open_board', but it does not mention any parameters. The description only says 'near the board corners', which implies margin but not the others.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Append' and clearly identifies the resource ('simple fiducial footprints') and location ('near the board corners'). This distinguishes it from sibling tools like pcb_add_mounting_holes and pcb_add_teardrops.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool vs alternatives, nor any exclusions. Usage is only implied by the tool name and action, which is insufficient for an agent choosing between similar PCB modification tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description carries the full burden of behavioral disclosure. It mentions 'deterministic heuristics' but does not state whether existing placement is overwritten, whether a board must be open, or how missing footprints are handled. This leaves significant side-effect uncertainty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler or redundancy. It efficiently communicates the core purpose and key differentiator in minimal words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, empty annotations, and significant side-effect potential, this one-line description is insufficient. It omits parameter meanings, preconditions, and behavioral consequences, even though an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 any of the 8 parameters such as grid_mm, strategy, sync_missing, or allow_open_board. The phrase 'deterministic heuristics' adds no parameter-level meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (place), the resource (PCB footprints), the source (current schematic), and the method (deterministic heuristics). It distinguishes this tool from sibling auto-placement approaches like pcb_auto_place_force_directed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a schematic is loaded and footprints need automatic placement, but it does not explicitly state when to prefer this over force-directed placement or manual placement. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and idempotentHint=true, and the description's 'List' action aligns with this. However, the description adds no behavioral context beyond the action, such as whether shapes across all layers are returned or if any filtering is possible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasteful words, providing exactly the core function without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple tool with an output schema, the description is too terse to fully disambiguate from related tools. It does not clarify what qualifies as a 'graphical board shape' or how this list relates to other board entity getters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the description does not need to explain any. The baseline for zero parameters is 4, and the description adds no irrelevant parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('graphical board shapes'). It is a specific verb+resource pairing, but it does not differentiate from sibling tools like pcb_get_zones or pcb_get_tracks, and the meaning of 'graphical board shapes' is somewhat ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of what distinguishes it from other pcb_get_* tools, nor any exclusions or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It hints at structured output for 'capable MCP clients' but does not explain whether the tool performs analysis, requires a loaded board, or has any side effects. The read-only nature is only implied by the word 'report'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler or redundancy. It is appropriately sized for a zero-parameter tool, and the key information (returning a report) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 lacks contextual completeness. It does not specify what the placement-quality report contains, how it relates to sibling quality-gate or scoring tools, or when it should be invoked. The qualifier 'for capable MCP clients' adds ambiguity rather than clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%. As per the baseline for zero-parameter tools, the description does not need to elaborate on parameters; the schema already exhaustively defines the input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Return a structured placement-quality report' clearly identifies a verb and resource, indicating the tool produces a report on placement quality. It does not explicitly differentiate from siblings like pcb_placement_quality_gate or pcb_score_placement, so it falls short of the highest rating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. No context, prerequisites, or exclusion criteria are mentioned, leaving the agent to infer use cases from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions running an external tool and staging an SES session, but it does not disclose side effects beyond the destructiveHint annotation. It does not say what files are overwritten, whether Docker is required, or what 'staging' involves. Given only destructiveHint=true, the description carries too much burden and fails to explain the actual runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action. Every word earns its place; there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no parameter descriptions, and only a destructiveHint annotation, the description is too sparse. It does not explain the workflow context, prerequisites, or potential impacts, leaving the agent with insufficient information to invoke the tool safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and there are 7 parameters. The description provides no information about dsn_path, ses_path, max_passes, use_docker, thread_count, freerouting_jar_path, or net_classes_to_ignore. The agent must rely entirely on parameter names/defaults, which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource: 'Run FreeRouting on a Specctra DSN file and stage the resulting SES session.' This distinguishes it from sibling route tools like route_single_track or route_export_dsn by naming the external autorouter and the DSN-to-SES workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description: it is for running FreeRouting on a DSN file. However, there is no explicit guidance on when to choose this tool over alternatives, nor any exclusions or prerequisites beyond the DSN/SES paths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description must carry the full burden. It only says 'Write', implying a mutating action, but does not disclose side effects, such as whether existing routing is removed, whether constraints are applied globally or locally, or if any validation occurs. This is minimal for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant phrasing. It is front-loaded with the key action ('Write') and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and no annotations, the description is too sparse. It does not explain how the constraints are used, what return value to expect (though output schema exists), or any relevant context like units or whether it affects the PCB layout. The tool appears to be a significant design action that merits more explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no parameter details. It only hints at 'a pair of nets' corresponding to net_p and net_n, but does not explain layer, gap, width, or tolerance parameters. The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Write' and the resource 'differential-pair routing constraints', with the target being 'a pair of nets'. This distinguishes it from sibling tools like route_single_track (single-ended) or check/tune tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention prerequisites, such as whether nets need to be selected or if existing constraints are overwritten. No exclusions or alternative tool references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations include destructiveHint=true, and the description adds that shape and rotation are preserved, providing some behavioral context beyond the annotation. However, it does not disclose other side effects like grid snapping or placement behavior, and the meaning of 'destructive' in this context is not elaborated. With the annotation present, the description adds modest value but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately names the action and object. It contains no redundant words or filler, making it an excellent example of concise writing that conveys the core purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, but the description lacks context about when to use it versus sibling label tools, what a hierarchical label specifically is, and how it relates to sheet hierarchy. While the basic function is clear, the missing guidance could lead to incorrect tool selection in ambiguous situations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so all parameters (text, x_mm, y_mm, shape, rotation, snap_to_grid) rely on the description for semantic context. The description only mentions 'shape and rotation' in a general way and does not explain formats, coordinate interpretation, or defaults. This leaves most parameters underspecified and does not compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and resource ('hierarchical label'), and the qualifier 'hierarchical' distinguishes it from sibling label tools like sch_add_label and sch_add_global_label. The added detail about preserving shape and rotation gives a specific behavioral clue, though what exactly constitutes a hierarchical label is not explained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as sch_add_label or sch_add_global_label. The term 'hierarchical' implies a use case in hierarchical schematics, but no conditions, exclusions, or comparisons are provided, leaving the choice to the user's domain knowledge.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the default snap-to-grid behavior (2.54 mm), which is useful and not visible in the schema. However, it does not explain the destructiveHint annotation or any side effects, and no error conditions or constraints are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, directly states the purpose and a key default behavior. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple placement tool with an output schema, the description is minimally sufficient. However, it lacks context about required project state, does not explain the destructiveHint, and gives no indication of what happens on success or failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds some meaning by implying that x_mm/y_mm form the anchor and that snap_to_grid controls the 2.54 mm snapping. But 'name' and 'rotation' remain undefined, and no allowed values or syntax are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Add') and resource ('power symbol'), and the mention of grid snapping distinguishes it from a generic symbol add. However, it does not explicitly contrast with the sibling tool 'sch_add_symbol'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like sch_add_symbol or sch_add_hierarchical_label. The intended use is implied by the name and 'power symbol' but not stated as a rule or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the useful behavioral detail that endpoints snap to a 2.54 mm grid by default, which goes beyond the destructiveHint annotation. However, it does not elaborate on what modifications occur or whether the operation can be undone, though the annotation already indicates destructive intent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the core function and a key default behavior. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a relatively simple wire-addition tool, the description gives the essential action and default snapping behavior. However, it lacks usage context, does not mention any limitations or interactions with existing wires, and only minimally connects to the schema parameters, leaving some gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description must compensate for the undefined parameters. It implicitly references endpoints and the snap_to_grid parameter via 'snapping... by default', but it does not explain the coordinate parameters (x1_mm, y1_mm, etc.) or their units beyond what the parameter names suggest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a schematic wire, with a specific verb and resource. It also notes the default grid snapping behavior, which helps distinguish it from related tools like sch_route_wire_between_pins, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as sch_route_wire_between_pins or sch_add_bus. There is no mention of prerequisites, preferred scenarios, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true already discloses the destructive nature. The description adds minimal context by indicating the action is about renumbering references, but it does not explain side effects (e.g., overwriting existing designators, impact on BOM/netlist) or any prerequisites. It does not contradict the annotation, so it earns a middle score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and free of filler. Every word contributes to the core purpose, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only two optional parameters and an output schema, the description is too sparse to be complete. It lacks parameter explanations, usage context, and any behavioral details beyond the basic action, leaving an agent inadequately informed to invoke the tool correctly in varied situations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 'order' or 'start_number' parameters. The parameter names and defaults appear in the schema, but without descriptions or any elaboration in the tool description, the agent cannot determine valid values (e.g., what 'alpha' means) or how they affect the renumbering.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Renumber schematic references sequentially' states a specific action (renumber) on a specific resource (schematic references) and clearly distinguishes this tool from sibling tools, none of which mention renumbering. It is concise yet unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 or how it relates to alternatives. It does not specify typical use cases (e.g., after adding/removing components) or any exclusions, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description is the sole source of behavioral context. It implies a read-only evaluation but does not disclose whether the gate returns a boolean, a report, a score, or any other output, nor does it explain thresholds, side effects, or dependencies on project state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, directly positioned sentence with no filler or repetition. It communicates the core purpose swiftly and efficiently, perfectly sized for scanning in a list of tools.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This gate tool has minimal annotations, no visible output schema, and a terse description. It does not clarify what 'electrically meaningful' means, how the evaluation is executed, what the return value represents, or what the agent should do after invocation. The description is inadequate for a tool that likely serves as a quality checkpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is trivially 100% covered and there is no parameter semantics to explain. The description's reference to 'schematic structure and hierarchy' provides implicit context for what is evaluated, meeting the baseline for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Evaluate') and resource ('schematic structure and hierarchy') with a defined assessment criterion ('electrically meaningful'). It distinguishes this gate from broader quality gates by emphasizing connectivity, though it does not explicitly reference sibling tools or alternative use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as schematic_quality_gate or sch_analyze_net_compilation. It lacks any mention of suitable scenarios, prerequisites, or exclusions, leaving the agent without decision criteria for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of disclosing behavior. 'Estimate' suggests a read-only analysis, but the description does not explicitly state that the tool does not modify the board, nor does it describe any prerequisites, side effects, or output format. This is a notable gap for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It front-loads the verb and the key object, making it easy to scan and quickly understand the tool's core function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters, no annotations, and a likely non-trivial analysis process, the description is too terse. It does not explain how the tool identifies differential pairs from the net names, how er and trace_type affect the calculation, or what the output represents. Even though an output schema exists, the description insufficiently frames the tool's overall behavior within the broader design context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 four parameters (net_p, net_n, er, trace_type). There is no explanation of what nets are, how the dielectric constant or trace type influences the estimation, or any other parameter semantics. The description fails to compensate for the lack of schema-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Estimate' and identifies a precise resource: 'differential-pair length skew and delay mismatch from board tracks.' This clearly distinguishes it from sibling tools like si_calculate_trace_impedance or emc_check_differential_pair_symmetry, which target different quantities or checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to estimate length skew and delay mismatch on differential pairs, but it does not provide explicit guidance on when to prefer this over alternatives, nor does it mention exclusionary conditions. No alternative tools are referenced, so the usage context is only implied, not fully clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries the full burden of behavioral disclosure. It does not mention side effects, required setup (e.g., netlist), or the nature of results. The statement only asserts the action 'run a sweep' without any operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant wording. It is front-loaded and every word earns its place, making it an exemplary concise statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and an output schema, the description is too sparse to be complete. It lacks usage context, parameter meaning, and any operational prerequisites, though the core purpose is at least clearly stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 any parameters. The word 'sweep' hints at frequency range, but probe_nets, netlist_path, and points_per_decade are ignored. This fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool runs a small-signal AC sweep, a specific and distinct analysis type. This distinguishes it from sibling simulation tools like sim_run_transient and sim_run_dc_sweep, even though it doesn't name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use AC analysis versus other simulation types, nor are any prerequisites or alternatives mentioned. The description simply states what the tool does without any contextual or selection advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must convey behavioral traits. It states the action but does not disclose whether the review modifies the design, requires prior setup, or what the output contains. The lack of any side-effect or prerequisite details leaves 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no redundant words. It is front-loaded with the action and includes the key qualifier about the profile.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and an output schema exists, so return values don't need explanation. However, the description does not mention that a profile must be loaded beforehand, or how this relates to other DFM workflow steps, leaving some contextual gaps for a complex tool domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, so the schema is complete. The description adds context about the 'active bundled profile' which is useful, but no parameter explanations are needed. Baseline for zero params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a manufacturer-aware DFM review, using a specific verb ('Run') and resource ('manufacturer-aware DFM review'). It distinguishes itself from generic design checks by referencing the active bundled profile, though it doesn't explicitly contrast with sibling tools like check_design_for_manufacture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It implies that a bundled profile must already be active, but does not state this as a prerequisite or mention related tools such as dfm_load_manufacturer_profile.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior itself. It reveals the tool reads from the active .kicad_dru file but does not mention whether it is a read-only operation, how it handles missing files, or the effect of the include_custom parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and resource. Every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple schema with one optional parameter and an output schema, so the description doesn't need to explain return values. However, it omits any mention of include_custom and potential default behavior, leaving some gaps for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions for its only parameter (include_custom), and the description does not mention it either. At 0% schema coverage, the description was expected to compensate but doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'list' and identifies the resource 'known DRC rules' alongside the source 'active .kicad_dru file', which clearly differentiates it from sibling tools like drc_rule_create or drc_export_rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inspecting current DRC rules but offers no explicit guidance on when to use it over siblings like drc_export_rules or drc_rule_create. It gives context (active file) but no exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. With destructiveHint=true, the agent is not informed about what may be overwritten, file paths, or side effects. The description only restates the tool's basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is properly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a zero-parameter tool, but the existence of sibling tools like 'export_step' and 'export_3d_render' creates ambiguity. Additionally, the destructiveHint annotation suggests potential side effects that are not addressed. More context on output location or distinction from siblings would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema coverage is 100% (empty schema). With no parameters, the baseline is 4; there is no parameter detail that the description could add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports a STEP model for the active board, using a specific verb and resource. However, it does not differentiate from the sibling tool 'export_step', which likely serves a similar or overlapping purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 'export_step' or 'export_3d_render'. The description simply states the action without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide openWorldHint and destructiveHint, but the description adds no further behavioral context. It does not mention side effects, file output locations, or what 'supported' entails, leaving the vague conditional as the only extra information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no unnecessary words. It is appropriately front-loaded and immediately communicates the core operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimally viable for a one-parameter export tool, and the presence of an output schema covers return values. However, it lacks details about supported layer types, output destination, and the conditions under which SVG export is available, leaving significant operational ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the sole 'layer' parameter, and the description does not explain it beyond implying a board layer. It fails to clarify possible values, layer naming conventions, or the meaning of the default 'F.Cu'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports a board layer to SVG. The verb 'export' plus the resource 'board layer to SVG' precisely defines the action, and it is readily distinguishable from sibling export tools by the SVG format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 the many other export tools, nor does it specify exclusions, prerequisites, or alternatives. The only qualifier is 'when supported,' which lacks concrete criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It only states the basic action, but doesn't disclose side effects such as overwriting existing properties, whether it creates the property if absent, or any validation behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundant information. It is concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple two-parameter setter, and the description is minimally adequate. However, it lacks crucial context about how to identify the target symbol, whether the property must already exist, and what the return value or output represents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 either parameter. The names 'reference' and 'lcsc_code' are somewhat self-explanatory, but the description adds no explicit meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Assign') with a clear resource ('LCSC part code') and target ('schematic symbol property'). It distinguishes itself from sibling tools like lib_assign_footprint, which assign footprints instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives, nor does it mention prerequisites or context. It does not explicitly differentiate from similar tools like lib_bind_part_to_symbol.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 adds the word 'live' to signal real-time data, but does not disclose potential side effects, failure modes, external dependencies, or permissions. For a simple read operation this is adequate, but it lacks deeper behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's minimal annotations and parameter descriptions, the description is too thin to fully enable correct selection and invocation. It does not distinguish this tool from the many library-related siblings (e.g., lib_get_footprint_info, lib_get_bom_with_pricing), nor does it explain the source parameter. The presence of an output schema covers return values, but other contextual gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies the lcsc_code_or_mpn parameter by noting it accepts either an LCSC code or MPN, but it does not explain the 'source' parameter, its valid values, or why the default is 'jlcsearch.' This leaves a key parameter ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and resource ('live component detail') and scopes it to 'a specific LCSC code or MPN.' This clearly conveys the tool's function, but it does not explicitly differentiate this from sibling tools like lib_search_components or lib_get_symbol_info, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when the agent has a specific LCSC code or MPN, but it does not provide explicit 'when not to use' guidance or mention alternatives such as lib_search_components for search-based lookup. The usage context is clear but limited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action without mentioning potential failure modes (e.g., empty path if no 3D model configured), read-only nature, or error handling. This lack of detail is a significant gap for a tool with zero annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that immediately conveys the tool's purpose. It is appropriately concise, with no unnecessary words or redundant information, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, but the description lacks usage guidelines and parameter context. The purpose is clear and the operation is straightforward, but the absence of behavioral and parameter details means the description is only minimally adequate rather than fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not elaborate on the meanings or format of the `library` and `footprint` parameters. Since schema descriptions are absent (0% coverage), the description should have compensated by clarifying what constitutes a valid library/footprint and how they relate to each other. The parameter names are somewhat self-explanatory, but no additional value is added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Return' and identifies the resource as 'configured 3D model path for a footprint', clearly distinguishing from sibling tools like lib_get_footprint_info or lib_search_footprints. It is unambiguous and immediately conveys the tool's exact function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 or any context such as prerequisites. It simply states the function without explaining its role in a broader workflow, leaving usage to be inferred from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description carries the burden of disclosing behavior. 'Return' implies a read-only operation, which is a key behavioral trait. However, it does not state what happens if the footprint is not found, whether authentication is needed, or any side effects. It is minimally transparent for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and object. It wastes no words and is easy to parse. However, it is slightly too brief, omitting usage context that could fit without bloating the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple and an output schema exists, the description lacks usage guidelines and behavioral disclaimers (e.g., read-only confirmation, error cases). The empty annotations leave significant context holes for an agent deciding whether to call this tool versus alternatives, making it incomplete for the full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 mentions 'footprint' (as the target entity) but does not explain the role of the 'library' parameter or any value formats. The parameter names are self-evident, but the description adds no extra semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Return details for a single footprint' uses a specific verb and resource, clearly distinguishing it from siblings like lib_list_footprints (list all) and lib_get_footprint_3d_model (specific 3D model data). It is unambiguous and action-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as lib_search_footprints or lib_list_footprints. There is no mention of prerequisites, filtering, or alternative tools for broader queries, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what the annotations already provide. Annotations include readOnlyHint=true and idempotentHint=true, which already indicate a safe read-only operation. The description merely restates the search action without disclosing details like return format, pagination, case sensitivity, or wildcard support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is front-loaded with the action and resource, making it easy to parse. Every word earns its place, and it avoids repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two parameters and an output schema, so the description need not explain return values. However, the lack of explanation for 'library_filter' and absence of usage guidance create a gap. The description is minimally adequate for a basic search but does not fully support correct invocation in all intended contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description only implicitly explains 'query' as the footprint name. It does not explain the 'library_filter' parameter at all, leaving its purpose and usage unclear. For a two-parameter tool with no schema descriptions, the description should compensate more by clarifying both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches footprint libraries by footprint name, which is a specific verb (search) with a specific resource (footprint libraries) and a specific filter (by name). This distinguishes it from sibling tools like lib_search_components, which searches components, and lib_list_footprints, which lists all footprints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention exclusions, such as when to prefer lib_search_components or lib_get_footprint_info. The phrase 'search footprint libraries' implies usage but offers no explicit context or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description carries full burden. It does not disclose side effects (e.g., whether the selection is consumed, whether a new block is added to the library, or whether it overwrites existing blocks), nor any prerequisites beyond 'selected footprint references'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, but it might be too sparse to be considered a well-structured explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with two required parameters and no annotations, the description lacks essential context such as how references are specified, whether it uses the current PCB selection, and what the tool returns. The output schema exists but is not available in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description barely explains the parameters. 'references' is hinted at as 'selected footprint references' but its format (e.g., reference designators) is undefined, and 'name' is completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Capture' with a specific object ('reusable PCB design block') and source ('selected footprint references'), clearly distinguishing it from sibling block tools like pcb_block_list and pcb_block_place.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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. The phrase 'from selected footprint references' implies it operates on currently selected footprints, but no exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only says 'check whether... appear to be flagged,' but does not state whether the operation is read-only, what 'flagged' means, or any potential side effects. This lack of detail leaves significant ambiguity about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary action. It contains no extraneous words and communicates the core purpose efficiently. This is an example of appropriately sized, well-structured text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple (0 params, output schema exists), the description omits context about what 'common power nets' refers to and what constitutes being 'flagged.' The output schema reduces the need to explain return values, but the lack of usage context and behavioral details leaves the description only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter meanings. The baseline for 0 params is 4, and the description adds no unnecessary parameter information. The schema trivially covers all (zero) parameters, so no gaps exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: checking whether common power nets appear to be flagged. It uses a specific verb ('check') and resource ('common power nets'), making the purpose understandable. However, it does not explicitly differentiate from sibling check tools, though the focused topic (power flags) provides some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternative checks, nor does it mention exclusions or prerequisites. There is no context suggesting specific scenarios where this check is appropriate, leaving the agent without direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint and idempotentHint, so the description need not repeat safety. However, it adds no behavioral detail beyond the purpose—no mention of what checks are performed, what output is returned, or what happens if the schematic is not clean. With annotations covering the safety profile, a 2 is appropriate for lack of added context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that states the tool's purpose without filler. It is well-structured and immediately comprehensible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is an output schema and no parameters, the main gap is explaining what 'clean enough' means and how the result should be interpreted. This is a simple tool, but the description leaves room for ambiguity about the criteria and outcome, making it minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description has no parameter semantics to convey. The schema coverage is 100% (empty), and the description is not expected to detail parameters. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Evaluate') and resource ('schematic') with the goal of determining whether it is 'clean enough to proceed.' It is distinguishable from simpler analysis tools but could be more specific about what 'clean' means compared to sibling gates like schematic_connectivity_gate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs. alternatives such as schematic_connectivity_gate or other quality gates. The phrase 'enough to proceed' implies a checkpoint use case, but no exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description accurately indicates that the tool changes the enabled state of a custom rule, which is a mutation. There are no annotations provided (annotations are empty), so the description's explicit statement of 'enable or disable' makes the behavioral intent clear. However, it does not disclose side effects such as whether disabling a rule affects DRC runs, whether the change is persistent, whether it validates the rule_name, or whether there are any ordering constraints. Minimal but acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence: 'Enable or disable a custom DRC rule.' It is front-loaded with the action verb, states the object, and includes both enable and disable variants. There is no unnecessary detail or repetition of the tool name. Every word contributes meaning; it is highly concise and well-formed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with 2 parameters and a straightforward purpose. The description, combined with schema, provides enough to understand the basic operation. However, the description does not address the broader context: it does not explain the relationship to DRC runs (e.g., whether changes take effect immediately), how to discover existing rule names (e.g., via drc_list_rules), or any caveats about disabling rules. Given the existence of sibling tools, a brief cross-reference would improve completeness. Also, the output schema exists but the description doesn't need to describe return values. Score 3 reflects adequate but not rich context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema itself provides only parameter names, types, and required status but no descriptions. The description mentions 'enable or disable', which helps clarify the 'enabled' parameter (boolean, default true), and the schema clearly shows rule_name is a required string. However, the description does not explain the formatting of rule_name (e.g., exact name or wildcard), nor does it add any semantics beyond what the parameter names imply. Baseline 3 is fair given the schema is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-action: 'Enable or disable a custom DRC rule.' It clearly identifies the resource (custom DRC rule) and the action (enable/disable). It is concise and easily distinguishable from sibling tools like drc_rule_create or drc_rule_delete, which have different purposes. However, it lacks an explicit scope qualifier (e.g., 'a specified rule' or 'one or more'), but the schema's required rule_name implies a single rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool instead of others like drc_rule_create or drc_rule_delete. It does not mention prerequisites (e.g., the rule must already exist) or contrast with related rule management tools. The context signals show there are multiple DRC rule tools (drc_list_rules, drc_rule_create, drc_rule_delete), but the description gives no comparison. Without any explicit usage context, score remains low.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides some behavioral context by stating the sweep is lightweight and heuristic, but it does not disclose side effects, read-only nature, or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words, clearly stating the action and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose but lacks context about the standard parameter, how this tool relates to the specific EMC check siblings, and what a user should expect from the output beyond the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'standard' parameter is not mentioned in the description, and with 0% schema description coverage, the description fails to add any meaning to this parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs a lightweight EMC sweep with at least ten heuristic checks, distinguishing it from the many specific emc_check_* sibling tools that focus on individual checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this broad sweep versus the specific EMC check tools, though it is implied by the name and the word 'sweep'. No alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a 'when supported' qualifier, which is a behavioral constraint, but it does not elaborate on the destructiveHint annotation or any side effects. It neither contradicts the annotations nor provides meaningful detail beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and format. It contains no filler words and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and annotations, the description is too sparse. It leaves critical questions unanswered: which layers support DXF, what the destructive hint implies, and what the output contains. The 'when supported' phrase is vague and requires elaboration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'layer' has no schema description, and the tool description does not explain valid values, the significance of the default 'Edge.Cuts', or which layers are supported. With 0% schema coverage, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports a board layer to DXF, using a specific verb ('export') and resource ('board layer') and format ('DXF'). This distinguishes it from sibling export tools like export_gerber or export_svg by the format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The phrase 'when supported' hints at a condition but does not explain under what circumstances DXF export is supported or why one would choose it over other export formats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint and openWorldHint, so the description does not need to repeat those. It adds minimal context by noting the optional explicit output path and alias nature, but does not describe what happens if the path is omitted, side effects, or the export format details beyond 'STEP'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one clear, front-loaded sentence with no wasted words. It successfully conveys the core purpose and key parameter in a concise manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 optional param, output schema present) and the annotations, the description is minimally sufficient but lacks important usage context. It does not explain how this alias differs from the similar 'export_3d_step' sibling, nor does it mention the destructive implication or file output behavior, leaving gaps that structured data only partially fill.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 mention 'optional explicit output path', which gives meaning to the single 'output_path' parameter. However, it does not explain path format, default behavior, or relationship to the schema's default empty string, leaving room for ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an alias for STEP export, with the specific addition of an optional explicit output path. It conveys the resource (STEP export) and a distinguishing feature (output path), though it does not differentiate it from the sibling tool export_3d_step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The term 'alias' implies a shortcut, but no exclusions or alternative tool mentions are provided, leaving the agent without clear decision-making criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries full burden. It only states a high-level action without disclosing how 'nearby' is determined, whether the tool queries an external service (like jlcsearch), or whether it is read-only. The behavior of tolerance and source parameters is left entirely unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, succinct sentence that is efficiently worded and front-loaded with the action. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters and no schema descriptions, yet the description covers only one parameter and provides no context about the 'source' or 'tolerance_percent' semantics. While an output schema exists (so return values are covered), the input side is underdescribed for a tool with options and defaults.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the lcsc_code parameter but omits 'source' and 'tolerance_percent', both of which are non-obvious (especially 'source' with default 'jlcsearch'). With 0% schema description coverage, the description should compensate by explaining all parameters, but it covers only one.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 ('alternative parts') and clearly identifies the key input ('supplied LCSC code'). It distinguishes this tool from siblings like lib_search_components or lib_check_stock_availability by focusing on finding alternatives rather than general search or availability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use case is implied: when you need alternative parts for an LCSC code. However, there is no explicit guidance on when to choose this over similar tools like lib_recommend_part, and no exclusions or alternative tool names are mentioned. It provides a clear context but lacks comparison with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, covering the safety profile. The description adds context with 'live' (implying real-time/online sources) and 'purchasable' (implying availability/commercial relevance), but does not disclose return format, filtering behavior, or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly worded sentence with no filler. It front-loads the core purpose efficiently and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and safe annotations, the description is too sparse to fully support tool selection and invocation. It lacks parameter details, usage context, and behavior beyond the most basic intent, making it incomplete for a 6-parameter search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only vaguely implies keyword-based searching. It does not explain source, package, sort_by, min_stock, or only_basic parameters, leaving significant gaps for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search') and a clear resource ('live component sources for purchasable parts'). It distinguishes itself from sibling tools like lib_search_symbols and lib_search_footprints by emphasizing 'purchasable parts' and live sources, which aligns with its component search purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives such as lib_check_stock_availability or lib_find_alternative_parts. The description implies a general search use case but does not state exclusions, prerequisites, or recommended scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds that evaluation is based on an 'active or requested DFM profile,' which is useful state context, but does not disclose output behavior or profile-loading requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence conveys the core purpose with no filler. It is appropriately concise, though the brevity contributes to missing details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and readOnly/idempotent annotations, the description need not explain return values or safety. However, it lacks context about the DFM profile lifecycle, how to request a profile via tier/manufacturer, and how it differs from sibling DFM/quality-gate tools, leaving it minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 0% of parameters with descriptions. The description never mentions 'tier' or 'manufacturer' or how they influence the requested DFM profile, so the agent gets no semantic guidance beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Evaluate manufacturing readiness') against a clear resource ('active or requested DFM profile'). It is clear and distinct from the generic quality-gate sibling names, though it does not explicitly differentiate from dfm_run_manufacturer_check or check_design_for_manufacture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies the tool is for readiness evaluation tied to a DFM profile but gives no explicit when-to-use or when-not-to-use guidance. There is no mention of alternatives or prerequisites, so the agent must 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true already flags mutation. The description adds that it creates copper helper zones at junctions but does not disclose details such as whether existing tracks are modified, whether zones are added as separate objects, or whether the operation is reversible. It adds minimal context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no redundancy or filler; it is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four optional parameters and no explanatory guidance on their effects, the one-sentence description is insufficient for correct invocation. The output schema may document return values, but the description does not cover parameter usage, selection criteria, or potential consequences of the destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 four parameters (max_count, net_classes, width_ratio, length_ratio). The parameter names are suggestive but not explained, forcing the agent to guess their meaning. The description 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'create' with a clear resource ('small copper helper zones') and a precise context ('at simple pad-to-track junctions'), clearly identifying the tool's function and distinguishing it from other pcb_add_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for simple pad-to-track junctions but does not explicitly state when to use this tool versus alternatives like pcb_add_copper_zone, nor does it mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations are empty, so the description is the sole source of behavioral disclosure. 'List' implies a read-only operation, but no details are provided about prerequisites, whether the list includes all blocks or only those from a specific selection, or what the output structure looks like. The phrase 'created from selected footprints' adds some context about the block origin but remains ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence of ten words. No waste, all words earn their place. The structure is front-loaded with the verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters) and the presence of an output schema, the description explains the core functionality. However, it could be more explicit about scope (whether it lists all stored blocks or only those tied to a selection) and how the blocks are 'created from selected footprints.' The description is adequate but leaves room for interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no schema to annotate. The description contributes by defining the object being listed, which is the only relevant semantic input. According to the rubric, zero parameters merits a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'List' and clearly identifies the resource as 'stored PCB design blocks' with an additional qualifier 'created from selected footprints.' This clearly states the tool's function, though it does not explicitly differentiate from sibling list tools such as pcb_get_footprints or pcb_block_place.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. No context signals such as 'use this when you need to see all blocks' or exclusionary statements are present. The description simply states the action without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true already signals destructive behavior. The description 'Delete items by UUID' is consistent but adds no additional behavioral context beyond the annotation, such as permanence, side effects, or undoing capabilities.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, 'Delete items by UUID.' Highly concise with no superfluous words or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete tool, the description is minimally adequate. It lacks explicit statement of what types of items are deletable and any prerequisites. However, an output schema exists, and the operation's simplicity reduces the need for extensive return-value descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that item_ids are UUIDs, which is valuable. However, it does not explain how to obtain these UUIDs or what happens if an invalid UUID is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and the resource 'items' (PCB items, implied by tool name) and specifies the identifier method 'by UUID'. It distinguishes from schematic delete tools via the 'pcb' prefix, but lacks explicit scope of which item types are affected.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention that this is for PCB items only, nor does it reference any related specific delete tools for schematic or other contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint: true already signals destructive behavior. The description adds the 'file-backed profile' mechanism, but it does not explain side effects, reversibility, or how the layers parameter interacts with the profile. This is minimal extra context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the core action efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive setter with one parameter, the description is too sparse. It does not clarify what 'file-backed profile' means, how the layers argument is used, or what the expected output is (even though an output schema exists). An agent would struggle to construct a valid call without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 not explain the 'layers' parameter structure or its relationship to the file-backed profile. The only hint is that layers relate to stackup, but no details on how to construct the array or what object properties are expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Set the active board stackup'. This distinguishes it from sibling tools like pcb_get_stackup (retrieval) and si_generate_stackup (generation). The qualifier 'using a file-backed profile' adds context without obscuring the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of when to use this over pcb_get_stackup (for reading) or si_generate_stackup (for generating), nor any prerequisites or exclusions. The context signals show many stackup-related siblings, making usage guidance critical but absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must explain behavioral traits, but it only says 'Validate'. It does not disclose whether this is a read-only check, what constitutes failure, whether it modifies the PCB or spec, or what the output schema contains. The agent is left without safety or side-effect information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the action and target. It is front-loaded and contains no filler or redundant wording, earning its place entirely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists (which presumably documents the validation results), the description covers the core purpose adequately. However, it lacks context about what 'resolved design spec' means or how this relates to other project lifecycle steps, preventing a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and a trivial empty schema, so the baseline for no parameters is 4. The description correctly implies that it relies on the active project context without needing additional inputs, adding no unnecessary parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Validate') and names the resources ('resolved design spec' against 'active project PCB'), clearly indicating a consistency check. It does not explicitly differentiate from sibling tools like validate_design or project_quality_gate, but the target resources are unique enough to suggest a distinct purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No information is provided about when to use this tool versus the many other validation and quality-gate tools listed as siblings. There are no prerequisites, exclusions, or references to related steps like project_infer_design_spec.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavioral detail of default 2.54 mm grid snapping, which is beyond the annotations. However, it does not address the destructiveHint annotation, nor explain any side effects or safety considerations. With annotations present, this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It earns a top score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple drawing tool with an output schema and straightforward parameters, the description is mostly sufficient. However, it lacks usage guidance and does not explain the destructiveHint context or what the result will look like. Complete enough for the task but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 only mentions grid snapping, which relates to snap_to_grid, but gives no detail on the coordinate parameters. The parameter names (x1_mm, y1_mm, etc.) are self-explanatory, but the description adds marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Add') and resource ('schematic bus'), and adds useful detail about grid snapping. However, it does not explicitly differentiate from sibling tools like sch_add_wire or sch_add_bus_wire_entry, so it earns a 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs. alternatives, no prerequisites, no exclusions, and no context about the bus vs. wire. It is purely a single-sentence definition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral information. It only states the creation action without disclosing side effects, reversibility, prerequisites (e.g., active sheet must exist), or error behavior. This is insufficient 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence, front-loaded with the verb and resource, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a creation tool with 5 parameters and no annotations. It omits parameter meaning, coordinate context, file behavior, and return/error info. The only useful context is that it targets the active top-level schematic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% property description coverage, and the tool description does not explain any parameter (e.g., what 'name' vs 'filename' means, what coordinates are relative to, or the effect of 'snap_to_grid'). The description provides no compensation for the missing schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'create' and identifies a distinct resource 'child schematic sheet' and its destination (active top-level schematic), clearly distinguishing it from sibling tools that add symbols, wires, or labels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a child sheet needs to be added to a schematic hierarchy, providing clear context of the action and target. However, it does not explicitly mention alternatives or exclusion conditions, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of disclosing behavior. It says 'Estimate,' which suggests a non-destructive analysis, but it does not clarify what happens when via_positions is null, whether the current selection is used, or whether the tool modifies the board. This ambiguity is significant given the default null value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant information. It states the verb, object, and context efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and zero schema description coverage, the one-line description is insufficient for a three-parameter tool. It omits prerequisites (e.g., active board, via model), behavior with defaults, and input format details. The output schema exists, but that does not compensate for missing input/behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 documentation. It mentions 'selected vias,' which loosely maps to via_positions, but it does not explain the coordinate format, the meaning of 'er', or the units/usage of frequency_ghz. The schema provides property names and defaults, but no descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Estimate') with a clear resource ('via-stub resonance and risk') and scope ('selected vias on the active board'). This clearly distinguishes it from sibling tools like si_check_differential_pair_skew or si_calculate_trace_impedance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for via-stub analysis on the active board, but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. It relies on the tool name and context to convey the intended use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only openWorldHint as an annotation, the description adds context by specifying the output goes to the project output directory, implying a file write. However, it does not disclose more about side effects, overwrites, or required project state, which are not covered by the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It states the action, object, and destination efficiently, making it easy to parse at a glance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 is too sparse for a tool with a required variant and a format parameter. It does not clarify the meaning of the variant or the allowed formats, nor does it mention any prerequisites or side effects. While the output schema covers return values, the description leaves significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 parameters. It does not explain the 'variant' parameter values, the 'format' parameter options, or any defaults beyond the schema. The vague phrase 'variant-specific' provides no practical guidance for using the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Export', the resource 'variant-specific BOM', and the destination 'project output directory'. This distinguishes it from generic export_bom and other variant tools, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for variant-specific BOMs, but does not explicitly mention when to use this over export_bom or other export tools. No exclusions or alternative tools are named, leaving the context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation declares destructiveHint=true, which already signals destructiveness. The description adds only the scope (project files from a checkpoint) but fails to disclose that current files will be overwritten, uncommitted changes may be lost, or whether the restore is a hard reset. This goes beyond the annotation's simple destructiveness flag in terms of operational risk awareness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant content. It states the action, target, and source in nine words, earning its place without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While an output schema exists, the description lacks crucial behavioral details for a destructive operation. It doesn't explain what happens to the current project state, whether the restore is selective or a full reset, or if there are safeguards such as requiring a clean working directory. For a potentially risky operation, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'commit_hash' parameter with 0% coverage beyond its title. The description mentions 'a previous checkpoint commit,' hinting at the parameter's origin, but does not explain how to obtain the hash, its format, or that it must reference a checkpoint created by vcs_commit_checkpoint. The parameter name is self-descriptive, but the description adds no explicit guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'restore' with 'project files' and identifies the source as 'a previous checkpoint commit,' clearly distinguishing this from sibling tools like vcs_commit_checkpoint (create), vcs_list_checkpoints (list), and vcs_diff_with_checkpoint (diff). It is concise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when reverting to a previous state but does not explicitly mention alternatives or prerequisites. For example, it doesn't advise using vcs_list_checkpoints to find a commit_hash or contrast with vcs_diff_with_checkpoint. The usage context is clear but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries the full burden. It does indicate the destructive nature via 'Delete' and scopes to the active rules file, but it does not disclose potential irreversibility, error handling for missing rules, or side effects on the design. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and resource. It is concise with no filler, perfectly sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema, so return values are likely covered. However, the description omits critical operational details such as whether deletion is permanent, how errors are handled, and whether the change is saved immediately. It is minimally viable but lacks deeper context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (rule_name) with no description (0% coverage). The tool description does not explain what constitutes a valid rule_name, how to obtain existing names, or any format constraints. It adds no semantic value over the schema's bare title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Delete'), the resource ('custom DRC rule'), and the scope ('from the active rules file'). It effectively distinguishes the tool from siblings like drc_rule_create and drc_rule_enable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a custom DRC rule is no longer needed, but provides no explicit guidance on when to use this versus other DRC rule management tools, nor any prerequisites like the rule existing. It lacks clear context on 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is known. The description adds the 'readable preview' behavior, but lacks additional context such as output format or any side effects, which is acceptable given the read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action and resource. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema present, the description is minimally adequate. However, it does not enumerate what board statistics are exported or provide comparison to similar tools, leaving some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers parameter semantics. The description does not need to add parameter details; baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Export' with resource 'board statistics', and clarifies it returns a readable preview. This distinguishes it from sibling tools like export_bom or pcb_get_board_summary by focusing on statistics and preview, though it doesn't define what statistics are included.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of exclusions, preferred contexts, or comparisons to similar tools, leaving the agent to infer from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks detail on side effects or preconditions. 'Rebuild' suggests a destructive/re-creation action, but it doesn't disclose if the index becomes temporarily unavailable, whether it's safe to call mid-session, or how long it takes. Annotations are empty, so the description carries the full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words. It is appropriately minimal for a tool with no parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the output schema covers return values, the description omits important context such as when this tool should be used, what conditions warrant rebuilding, and what the impact on the current session might be. This leaves the agent under-informed for decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter information to add. The schema already fully covers the input, and the description doesn't need to explain parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('rebuild') and a clear resource ('in-memory symbol search index'), making its function immediately obvious. It also differentiates from sibling tools by targeting an internal index rather than a typical search/query operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to invoke this tool, nor references to alternatives. It doesn't state whether to run after library changes, when the index is corrupted, or any conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With the annotations already indicating read-only and idempotent behavior, the description adds the search criteria (name, description, keywords) but does not disclose additional behavioral traits like case sensitivity, wildcard support, or the structure of the returned matches. Since the output schema exists, this is acceptable but not enhanced beyond the basics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently conveys the core purpose. It contains no redundant information and is well-structured, though it could be slightly more detailed without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters and one is undocumented, the description is incomplete. It fails to explain the 'library_filter' parameter, and while the output schema exists, the lack of parameter guidance for a required query and an optional filter leaves the agent without full context for successful invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 partially explains the 'query' parameter by indicating it searches across name, description, or keywords, but the 'library_filter' parameter is entirely unexplained. This leaves a significant gap in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Search') applied to a resource ('symbol libraries') with explicit search dimensions ('by name, description, or keywords'). This distinguishes it from sibling tools like lib_search_components and lib_search_footprints, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding symbol libraries based on text criteria, but it does not explicitly state when to use this tool versus alternatives such as lib_search_components or lib_get_symbol_info. No exclusions or alternative recommendations are provided, making the guidance only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks any detail about side effects, such as whether existing files are overwritten or if the project is modified in place. Annotations provide only openWorldHint, which doesn't disclose safety or destructive behavior, so the description carries the full burden and falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that is immediately understandable and free of unnecessary words. It prioritizes the core purpose effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose but omits details about import behavior, such as handling of existing data, optional output_dir behavior, and any required project state. Given the tool's simplicity, it is minimally adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should explain the parameters, but it only mentions 'PADS PCB' generically. The parameter names pads_pcb_path and output_dir are suggestive but the description does not clarify defaults, requiredness, or expected formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Import', the input 'PADS PCB', and the destination 'KiCad project directory', making it distinct from sibling import tools for Geda and Allegro.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a PADS PCB needs to be imported, but it does not explicitly mention alternatives or when not to use it. There is no comparison with mfg_import_geda or mfg_import_allegro.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is clear. The description adds that it lists every layer including inner layers, which is useful but not rich behavioral detail. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return values and annotations cover safety, but the description omits parameter semantics and usage context. Given the tool's simplicity, it is minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single required parameter 'reference' is not explained in the description. With 0% schema coverage, the description should clarify what a 'footprint block reference' is, but it only uses the term 'footprint block' without defining the reference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and the resource (layers referenced by a footprint block). The qualifier 'including inner layers' adds specificity and distinguishes this from generic layer-listing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 pcb_get_layers or pcb_get_footprints. The description only states what it does, not the intended context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description adds the notion of 'physically clean' but does not explain what criteria are evaluated, what the output represents, or any side effects (though read-only implies none). It adds minimal context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's core purpose without unnecessary words. It earns its place and is appropriately sized for a zero-parameter gate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present and no parameters, the description is reasonably complete, but the term 'physically clean' is vague and not elaborated. Among many similar quality gates, the agent may not fully understand what specific checks are performed or how to interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema and description are trivially consistent. The baseline for zero parameters is 4, and the description adds nothing that conflicts or undermines this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool evaluates whether the PCB is 'physically clean enough to proceed,' using a specific verb and resource. However, it does not distinguish itself from sibling quality gates like pcb_placement_quality_gate or manufacturing_quality_gate, so it lacks explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool as opposed to other quality gates or related checks. The description only states what it does, leaving the agent without context on when this check is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description carries full burden, but it only says 'Refill all copper zones.' It does not disclose that this is a mutating operation, may discard existing fills, requires a board to be open, or can affect DRC results. The behavioral implications of 'refill' are left implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It directly states the action and target, making it efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity and an output schema, the description lacks important context such as prerequisites, side effects, and when to invoke it. An agent would not know if this modifies the board permanently or if it should be run before manufacturing checks. This leaves the tool under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description need not explain any. Baseline 4 applies. The description adds nothing about parameters because there are none to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Refill all copper zones' uses a specific verb (refill) and resource (copper zones), clearly distinguishing it from siblings like pcb_add_zone or pcb_get_zones. It states the scope ('all') and the action, making it fully unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, when not to use it, or alternatives. The description only states what it does, leaving the agent to infer that it should be used after editing zones or before export. No explicit context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, covering the safety profile. The description adds that the action is derived from the current project gate, implying dependence on project state, but gives no further behavioral context such as error conditions or side effects. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of 10 words directly states the tool's action with no filler. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and leaves out context about when the tool should be invoked, what constitutes a 'project gate', and how it relates to other gate-related tools. While an output schema exists, the description could benefit from situational guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description does not need to explain parameters and does not add any parameter semantics, which is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the next high-priority action from the current project gate, using a specific verb and resource. It is unambiguous but does not explicitly differentiate from sibling tools like project_quality_gate or project_quality_gate_report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of prerequisites (e.g., after running a quality gate) or contrasts with related project tools, leaving the agent without selection cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds no additional behavioral detail (e.g., what specific checks are performed or side effects), but does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence, front-loaded with the verb and object. No wasted words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be described. However, the description lacks context about prerequisites (e.g., requiring an open schematic) and does not differentiate from sibling check tools. It is minimally sufficient for a simple tool but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 'save_report' parameter. While the schema property title is self-explanatory, the description fails to compensate for the low coverage by clarifying the parameter's effect (e.g., where the report is saved).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Run' with the resource 'schematic electrical rule checks,' clearly distinguishing it from PCB DRC (run_drc) and other EMC/SI checks. It is a clear, specific statement of function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention exclusions, prerequisites, or compare with sibling tools like run_drc or sch_check_power_flags.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the read-only behavior is covered. The description adds minimal context by specifying 'child sheet', but does not disclose error conditions, what metadata is returned, or any side effects. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and resource. Every word earns its place, and there is no irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema (which may document return values). However, the description lacks usage context and does not clarify what 'child sheet' means precisely or how sheet_name should be specified. It is adequate but has gaps in practical guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no additional meaning for the single required parameter 'sheet_name'. The name is relatively self-explanatory, but no format, path expectations, or default behavior is specified, so the description does not compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Return metadata for a specific child sheet' uses a specific verb ('Return') and identifies the resource ('metadata for a specific child sheet'). It clearly distinguishes from sibling tools like sch_list_sheets (which lists sheets) and other get_* tools by targeting a single child sheet's metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 sch_list_sheets or other sheet-related tools. The description does not mention prerequisites, context, or exclusions, leaving the agent without direction for selecting it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds useful behavioral context by specifying that tracing goes through child sheets, but it does not disclose whether the operation is read-only, what happens if the net is not found, or any error conditions. The action 'trace' implies non-destructive, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action verb and includes essential scope. Every word contributes value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (one parameter, output schema present), the description is minimally adequate. It covers the core behavior and hierarchy traversal, but lacks context about selection among similar tools, prerequisites, or behavior on missing nets. The output schema presumably covers return values, so no additional return explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 mentions 'a named net' without explaining net_name format, case sensitivity, or qualification. The property name and title are self-explanatory, but the description adds no additional meaning beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Trace') and resource ('a named net') with clear scope ('through the active schematic and matching child sheets'). This distinguishes it from sibling tools like sch_get_connectivity_graph or sch_analyze_net_compilation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. The description implies usage for trace operations but does not mention exclusions or alternative tools, which is a significant gap given many similar net-analysis siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full burden. It does not disclose whether the operation is read-only, what 'effective BOM' includes (e.g., supplier alternatives), or any side effects. 'Diff' implies a read operation but lacks explicit 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that conveys the core function with no wasted words. It is appropriately sized for a simple two-parameter diff tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, an output schema exists, and the operation is straightforward, the description is minimally viable. However, it omits contextual details like whether the variants must belong to the same design/project, which an agent might need to know.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only loosely maps the parameters to 'two design variants.' It does not clarify the required format for variant_a and variant_b (e.g., names, IDs) or how to reference them, leaving the agent to infer from parameter titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Diff'), the object ('effective BOM'), and the scope ('between two design variants'), which distinguishes it from sibling BOM export tools like variant_export_bom.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied—when comparing BOMs between two variants—but the description does not explicitly mention when to use this tool over alternatives or provide 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The openWorldHint annotation already signals that the tool may interact with the external world, and 'Export... file' implies file-system side effects. However, the description does not disclose important behavior such as what happens when output_path is omitted, whether files are overwritten, or whether the tool returns file content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the action, resource, and intended use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple and has an output schema, the description lacks essential contextual details about the optional output_path parameter and side-effect behavior. The presence of openWorldHint and an output schema does not make up for the missing parameter semantics and usage guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 output_path at all. With only one optional parameter, the agent is left to infer what the parameter means, what 'null' default does, and how the export destination is determined. The description fails to compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Export' with a clear resource 'the active custom DRC rules file' and purpose 'for sharing or CI.' This clearly distinguishes it from sibling tools like drc_list_rules, drc_rule_create, or run_drc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for sharing or CI' gives some context for when to use the tool, but there is no explicit guidance about when to choose this over related tools such as drc_list_rules or other export_* tools. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations. Despite destructiveHint=true indicating possible overwriting of files, the description does not mention this side effect. The openWorldHint suggests unknown behavior, but no additional clarity is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the action and target, containing no wasted words. It is ideal in size and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists and there are no parameters, but the description is minimal. It does not clarify whether the entire schematic (all sheets) is exported, where the PDF is saved, or any potential caveats. For a no-param tool, this is minimally viable but leaves some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema covers all query information. The description adds no parameter details, but none are needed given the tool takes no arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Export' and identifies the resource 'the schematic' with the format 'PDF', clearly distinguishing it from sibling tools like export_pcb_pdf. It is unambiguous and precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as export_pcb_pdf or export_svg. It simply states what it does without mentioning exclusions or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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. It fails to mention whether the scan is recursive, which file extensions count as KiCad project files, or whether the operation is read-only. This lack of detail could lead to incorrect assumptions about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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 purpose. There is no unnecessary verbosity or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema, so return values need not be explained. However, the description omits key behavioral details like recursion and file type filtering, which are relevant for a scan operation. This leaves the description minimally complete but with notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a 'path' parameter with no description (0% coverage). The description adds value by clarifying that the path should be a directory, not a file. However, it does not compensate for other missing details such as whether the path can be relative/absolute or whether it must exist, leaving the parameter semantics only partially clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Scan'), a resource ('a directory'), and the outcome ('report any KiCad project files it contains'). This distinguishes it from sibling tools like kicad_get_project_info or kicad_list_recent_projects, which focus on project metadata or recent projects rather than directory scanning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for discovering KiCad projects within a directory, which provides basic context. However, it does not explicitly state when to use this tool versus alternatives (e.g., kicad_list_recent_projects for known projects) or mention exclusions such as recursion behavior or supported file extensions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries the burden. 'List' implies a read-only operation, but no further behavioral details are provided such as whether it returns all footprints or requires the library to exist. It is not misleading, but offers minimal transparency beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, front-loading the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, output schema present), the description is functional but lacks usage context and details about return behavior. It does not reference related tools or edge cases, leaving room for ambiguity in selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only a 'library' string parameter with no description. The description clarifies that the parameter identifies the specific library, adding some meaning beyond the schema, though it does not specify formats or sources for the library name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list) and the resource (footprints in a specific library). It distinguishes itself from sibling tools like lib_search_footprints and lib_list_libraries by specifying 'in a specific library'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as lib_search_footprints. The description merely states what it does without explaining contexts, exclusions, or related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true already signals potential destructive behavior, and the description does not contradict this. The description adds context about the location and nature of the footprints but does not disclose side effects or what may be overwritten, leaving the full behavioral impact unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads the action ('Append') and specifies the object and location. Every word contributes to the meaning, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 configurable parameters and a destructive hint, the description is too sparse. It does not explain parameter effects, defaults, or potential board modifications, leaving the agent needing to infer behavior from parameter names alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters but 0% description coverage, and the description provides no additional meaning for any parameter. Terms like 'pattern', 'margin_mm', and 'allow_open_board' are only listed by name without explanation, so the description fails to compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Append') and clearly identifies the resource ('standard mounting-hole footprints') and location ('around the current board frame'). This distinguishes it from sibling tools like pcb_add_via or pcb_add_fiducial_marks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'around the current board frame' provides clear context for when to use this tool (adding mounting holes). However, it does not mention alternatives or situations where another tool would be preferred, only implicit exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description carries the full burden. It discloses that placement works by cloning saved footprint blocks (non-destructive), but it does not state side effects, prerequisites, error conditions, or whether it modifies the board irreversibly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence (13 words) with no filler, front-loading the action and resource. Every word contributes to the core meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters and no annotations, the description lacks critical context such as coordinate system origin, units, rotation behavior, and the requirement that the block already exists. The output schema covers return values, but usage context is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 any of the four parameters. It only indirectly references block_name through 'stored PCB design block', while x_mm, y_mm, and rotation_deg are entirely unaddressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Place') and resource ('stored PCB design block'), and the mechanism ('by cloning its saved footprint blocks'). It distinguishes itself from siblings like pcb_block_list and pcb_block_create_from_selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for placing a pre-existing block, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any preconditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=true and idempotentHint=true, and the description 'summarize' aligns with a read-only operation. The description adds minimal context beyond annotations, only specifying it targets the 'current board,' so it neither contradicts nor significantly enriches the behavioral profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It communicates the core function efficiently and is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-input tool with an output schema available, the description sufficiently indicates the action and target. It could be more explicit about what the summary includes, but the output schema likely fills that gap, making it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the empty schema is fully covered and there is nothing for the description to explain. This meets the baseline for no-parameter tools, and the description adds no unnecessary parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool summarizes the current board, which is a clear verb+resource combination. However, it does not distinguish this from similar tools such as get_board_stats or pcb_get_board_as_string, so it is clear but not sibling-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 that retrieve board information. It simply states the action without any context, exclusions, or mention of alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is known. The description adds the caveat 'when available', which indicates the file may not exist, but it does not specify behavior when unavailable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant information. It is appropriately front-loaded and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with an output schema, the description is adequate. It could mention what the file contains or what happens if unavailable, but the schema and annotations cover the remainder.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema fully covers the empty property set. The description adds nothing needed for parameter semantics, and the baseline of 4 for zero-parameter tools applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as reading the active board design rules file, using the specific verb 'read' and a concrete resource. It distinguishes itself from related tools like pcb_set_design_rules through its read-only focus, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The phrase 'when available' hints at conditional availability but does not explain prerequisites or compare with similar tools such as drc_list_rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. However, the description adds no behavioral context beyond that, such as whether it returns all pads or requires an open board, so it contributes little beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that immediately states the action and object with zero waste. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter with an output schema, the description is minimally adequate but lacks contextual details like whether it lists pads on the current board or what pad information is returned. The output schema covers return values, but the description could still provide more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain any parameter semantics. A baseline of 4 is appropriate since there are no params to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and resource 'board pads', making it clear what the tool does. It distinguishes itself from sibling tools like pcb_get_nets and pcb_get_shapes by naming the exact object (pads).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives, prerequisites, or typical scenarios, leaving the agent without direction on when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing side effects. It only states the action 'save' without explaining overwrite behavior, whether confirmation is needed, or if the board must have an existing file. This lack of detail is a meaningful gap for a state-changing operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: 'Save the active board.' It contains no filler and every word adds value. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's minimal complexity (no parameters, no annotations, but an output schema), the description is adequate but incomplete. It does not mention whether the save requires a pre-existing file, whether it is idempotent, or what the output indicates. For a standard operation, the core action is clear, but the lack of any behavioral caveats makes it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 schema, and the description does not need to add parameter semantics. The simplicity is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Save the active board' uses a specific verb and clearly identifies the resource (the active board). It is unambiguous and distinct from sibling tools, as there is no other save-like operation in the list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as after modifications or before export. It does not mention alternatives or exclusions, leaving the agent to infer its placement in a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint=true, and the description adds only 'to the active board' as extra context. It does not disclose what happens to existing keepouts or any side effects beyond the annotation. Since the destructive hint is provided, a score of 3 reflects that the description adds modest contextual value without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant details. Every word is purposeful and conveys the essential function without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with six parameters and a destructive hint, the one-sentence description is insufficient. It omits crucial context like coordinate reference, layer scope, the meaning of 'rules', and any return values. Although an output schema exists, the description alone leaves significant 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover 0% of parameters, and the tool description provides no parameter explanations. While names like x_mm, y_mm, w_mm, and h_mm are self-explanatory, the 'rules' parameter is ambiguous and could easily be misused without guidance. The description 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds a rectangular PCB keepout/rule area to the active board, distinguishing it from sibling tools like pcb_add_zone or pcb_add_rectangle. The verb 'add' and resource 'keepout / rule area' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clarifies that the operation applies to the active board, but it provides no explicit guidance on when to use this over alternatives such as pcb_add_zone or pcb_add_rectangle. The phrase 'keepout / rule area' implies a distinct use case, but no exclusions or comparisons are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries the full burden of behavioral disclosure. It only states that it assigns a profile, but does not mention side effects, such as whether existing tunings are overwritten, whether wildcards match zero or multiple nets, or whether it is reversible. For a mutation tool, this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and to the point. It contains no unnecessary information and is front-loaded with the verb and object. This is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with only two required parameters, but the description lacks important context such as what happens if the profile does not exist, if the net pattern matches nothing, or how wildcards work. While there is an output schema, its contents are unknown to the agent. The description covers the basic purpose but is incomplete for robust use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its two parameters. The description provides some mapping by mentioning 'named tuning profile' (profile_name) and 'net or wildcard net group' (net_pattern), but does not explain the exact format or semantics, such as wildcard syntax. It partially compensates for the schema gap but lacks detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Assign a named tuning profile to a net or wildcard net group.' It uses a specific verb ('assign'), identifies the resource ('tuning profile'), and specifies the target ('net or wildcard net group'). This distinguishes it from sibling tools like route_create_tuning_profile and route_list_tuning_profiles, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context: it is used to apply an existing tuning profile to a net. However, it does not explicitly mention when to use this tool versus alternatives like route_tune_length or tune_track_length, nor does it provide workflow context (e.g., 'after creating a profile'). The guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds a behavioral detail ('snapping its anchor to the 2.54 mm grid by default') beyond the destructiveHint annotation. It does not contradict the annotation, and the annotation already signals mutation, so this is sufficient for a simple add operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with the primary action up front, followed by a relevant default behavior. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While output schema and annotations exist, the description lacks usage context and parameter semantics. For a tool with four parameters and zero schema descriptions, a one-sentence description is insufficient for reliable tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all parameters. It only addresses snap_to_grid (via 'by default') and indirectly x_mm/y_mm (anchor), but completely omits direction semantics. This leaves a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the specific resource ('bus wire entry marker'), distinguishing it from siblings like sch_add_wire, sch_add_bus, and sch_add_label. It also provides a key behavioral detail about grid snapping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as sch_add_wire or sch_add_bus. The description only defines the operation, not the context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states the action, not side effects, behavior with snap_to_grid, whether connections are preserved, or error conditions. This is thin 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence with no redundant words. It efficiently conveys the core action and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple move operation with an output schema, the description is adequate but lacks detail on return values, failure modes, and behavior of the optional snap_to_grid parameter. Not fully complete for an agent to invoke with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning by clarifying that coordinates are absolute and the symbol must exist (reference). However, the optional snap_to_grid parameter is not mentioned, so coverage is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Move') with a clear resource ('existing symbol instance') and scope ('to a new absolute coordinate'). This distinguishes it from siblings like sch_add_symbol, sch_delete_symbol, and sch_auto_place_symbols.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for relocating an existing symbol to a precise coordinate, but it does not explicitly state when to use it versus alternatives such as sch_auto_place_symbols 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It does not explain the consequences of reloading, such as potential loss of unsaved changes or the need for an open/active schematic. This is a notable gap for a command that may have side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that is front-loaded and free of redundancy. It conveys the action clearly with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, output schema exists), a minimal description is acceptable, but it lacks important context about when reloading is necessary and what impact it has on the current session. This makes it adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is trivially 100%. Per the baseline for no parameters, a score of 4 is appropriate; the description adds no param-specific info but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('reload') with a clear resource ('the active schematic'), making its purpose immediately obvious. It distinguishes itself from sibling tools that also operate on schematics but perform different actions like creating, listing, or annotating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor are any exclusions or prerequisites mentioned. The description is purely functional and lacks contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint: true, which already signals the tool modifies state. The description adds that it affects population, value, and footprint, but does not disclose whether existing overrides are replaced/merged, whether changes are reversible, or the precise effect of the 'enabled' parameter. It provides some context beyond annotations but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the tool's purpose efficiently. It is front-loaded with the action verb and contains no fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description covers the basic purpose, it is missing important context for a tool with 5 parameters, 0% schema coverage, and only a destructiveHint annotation. It does not explain the meaning of 'enabled', the format of 'variant' and 'reference', or how the override interacts with existing variant data. An output schema exists, but the description still leaves key behavioral details ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 mentions 'population', 'value', and 'footprint', which correspond to the 'enabled', 'value', and 'footprint' parameters, but it does not explain required parameters like 'variant' or 'reference'. The meaning of 'enabled' (e.g., whether true means populated) is also left ambiguous. It offers minimal semantic help for a 5-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Override component population, value, or footprint in a variant.' It uses a specific verb ('Override') and identifies the exact resource (component attributes within a variant). This distinguishes it from sibling tools like variant_create or variant_set_active, which handle variant creation or activation rather than component-level overrides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: it should be used when you need to change component population, value, or footprint in an existing variant. However, it does not explicitly say when NOT to use it or mention alternatives such as variant_create for new variants. There is no comparison with sibling tools, so the guidance is limited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already provide destructiveHint=true, indicating this is a mutating operation. The description adds minimal behavioral context beyond the annotation, such as what a 'checkpoint' entails or any side effects (e.g., running auto_drc). It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the main action. Every word contributes to understanding the tool's purpose, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters, zero schema descriptions, and a destructiveHint annotation, the description is too sparse. It omits prerequisites (e.g., whether a Git repo must be initialized), the meaning/effect of auto_drc, and what happens to existing checkpoints. The existence of an output schema is noted but not enough to compensate for the lack of behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. The phrase 'named checkpoint' hints that 'message' is the name, but it says nothing about 'auto_drc' or how that affects the commit. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Commit' with a clear resource 'current project state as a named checkpoint'. It effectively distinguishes this tool from siblings like vcs_restore_checkpoint, vcs_list_checkpoints, and vcs_diff_with_checkpoint, which have different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to save a checkpoint but provides no explicit guidance on when to use it vs. alternatives like vcs_restore_checkpoint or vcs_list_checkpoints. It lacks any mention of prerequisites or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only says 'Initialize a Git repository' without disclosing side effects, prerequisites, behavior if already initialized, or any potential destructive actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the action, zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one parameter) and presence of an output schema, the description is minimally viable but lacks behavioral details such as idempotency or interaction with existing VCS state. It does not describe what happens on success or failure beyond the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description ties the parameter to the 'KiCad project directory', adding meaning to project_dir. However, it does not clarify path format, existence requirements, or whether the directory will be created.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Initialize' and the resource 'a Git repository for the KiCad project directory'. It is specific and distinct from sibling VCS tools like vcs_commit_checkpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need to set up version control for a KiCad project) but does not explicitly state when to use vs alternatives or provide exclusions. No alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the agent knows this is a safe, non-mutating operation. The description adds context about the data source ('available DRC data') and the lightweight nature, but does not disclose details like what happens if DRC data is unavailable or what the output structure contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is well front-loaded with the action. Every word 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional boolean parameter), and an output schema exists, so return values are covered elsewhere. However, the description omits any explanation of the 'jlcpcb' parameter and does not clarify the relationship to full DFM checks, leaving some gaps for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'jlcpcb' with no description, and the tool description does not explain it either. With 0% schema description coverage, the description should compensate, but it offers no insight into what the parameter controls or how it affects the check.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Run'), resource ('DFM check'), and key distinguishing characteristics ('lightweight', 'using available DRC data'). This differentiates it from heavier DFM tools like dfm_run_manufacturer_check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a quick, lightweight check using DRC data, but does not explicitly state when to prefer this over alternatives such as dfm_run_manufacturer_check or run_drc. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It mentions 'Requires the schematic backend' for auto_assign_footprint and says it 'attempts' the assignment, but does not disclose whether the operation overwrites existing assignments, requires specific permissions, or is reversible. This is a significant gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose sentence, usage context, and Args/Returns sections. It is longer than the bare minimum but each section adds value, especially given the absence of schema descriptions for parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Context signals indicate an output schema exists, so the description need not detail return value format. It covers the main parameters, usage context, and return confirmation, making it adequate for a 4-parameter tool, though it omits error conditions and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description's Args section is essential. It explains sym_ref with an example, defines lcsc_code_or_mpn, describes auto_assign_footprint behavior, and gives a brief role for source. However, 'source' is vague ('Parts source for detail lookup') with no possible values or semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool assigns a live part (LCSC/MPN) to a schematic symbol with optional footprint assignment. The verb 'Assign' and resource are specific. It does not explicitly differentiate from sibling tools like lib_assign_lcsc_to_symbol, but the workflow context helps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states it is the recommended tool after lib_recommend_part() or lib_search_components() returns a suitable part, providing clear when-to-use guidance. It does not mention alternatives or when not to use, so it stops short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true already signals that the operation modifies the design. The description adds the 'single operation' aspect, suggesting atomicity, but provides no further behavioral context such as validation behavior, defaults, or effect on existing tracks. This is minimal extra value beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no filler. It is front-loaded and every word adds value, though it is extremely terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the schema provides detailed field descriptions and an output schema exists, the description can rely on that, but it still misses explicit guidance on when to use bulk vs. single add, and does not mention default layer/width or coordinate limits. It is minimally viable but has noticeable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not discuss the 'tracks' parameter or the required fields (x1, y1, x2, y2) at all. With schema description coverage at 0%, the description fails to compensate or add meaning to the parameters, leaving the agent to rely solely on the schema's inline descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add') and the resource ('multiple tracks'), and the phrase 'in a single operation' distinguishes it from the singular sibling tool pcb_add_track, which adds one track at a time. The verb and scope are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for batch operations but does not explicitly state when to choose this tool over pcb_add_track or route_single_track. No exclusions or alternatives are mentioned, leaving this to inference from the tool name and sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds no further behavioral context such as what constitutes 'cleanly', how failures are reported, or any dependencies on project state. It does not contradict annotations but adds minimal value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and target. Every word is necessary, with no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, is read-only and idempotent per annotations, and has an output schema (not shown), the description provides a clear and sufficient overview. It could mention prerequisites like needing schematic and PCB data, but the simplicity of the tool keeps the description adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, so the schema fully covers them. The baseline for zero params is 4, and the description correctly makes no parameter claims.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Evaluate' and clearly identifies the resource: transfer of named schematic pad nets to PCB pads. This distinguishes it from other quality gates like pcb_quality_gate or schematic_quality_gate by focusing on a specific cross-domain check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus related quality gates or other PCB verification tools. It implies a post-transfer scenario but does not state it directly or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, covering the safety profile. The description adds the scope of checks (schematic, PCB, DFM, parity) but doesn't disclose operational details like return format or side effects. With annotations, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that effectively communicates the tool's purpose and scope without any wasted words. It is front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 details are covered. However, the lack of parameter semantics and any context about how to invoke it (e.g., what a 'tier' could be) makes it incomplete for an agent to call it optimally. It's adequate for a basic understanding but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two parameters (tier, manufacturer) with 0% description coverage. The description does not mention them at all, leaving the agent with no guidance on valid values or their purpose. This is a critical gap for a tool where manufacturer likely affects DFM checks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs the full project quality gate across schematic, PCB, DFM, and parity checks. This specific verb and resource scope distinguishes it from sibling tools like schematic_quality_gate and pcb_quality_gate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'full project quality gate' and the explicit list of domains indicate when to use this tool: when a comprehensive multi-domain check is needed. It doesn't explicitly mention alternatives or exclusions, but the scope is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the useful behavioral detail that the marker snaps to the 2.54 mm grid by default, which goes beyond the annotations. However, the destructiveHint is true and the description does not explain what destructive effect may occur, leaving the annotation's implications unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose and includes one key behavioral default. No filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so return values do not need explanation. However, parameter semantics are missing, and the destructiveHint annotation is not contextualized. The description gives a clear one-line purpose but leaves users to infer coordinate semantics and operational effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 compensate. The parameters x_mm, y_mm, and snap_to_grid are only named in the schema; their meaning, coordinate system, and relationship to grid snapping are not explained in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Add') and the specific resource ('no-connect marker'), which distinguishes it from sibling schematic-add tools like sch_add_symbol or sch_add_wire. The mention of default grid snapping adds a specific behavioral detail that further clarifies purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives. The context implies it is for adding no-connect markers in a schematic, but there is no mention of when not to use it or which alternative tools might be preferable in other situations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already provides destructiveHint: true, so the destructive nature is known. The description adds valuable context that directly attached wire segments are also removed, which goes beyond the annotation and clarifies the scope of side effects. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
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. There is no redundancy or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive tool, the description covers the main behavior and side effects. However, the missing explanation of the 'reference' parameter and the lack of usage guidance leave the description incomplete. An output schema exists, so return values need not be explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'reference' with no description (0% coverage). The tool description does not explain what 'reference' refers to (e.g., a reference designator). Since there is only one parameter and the description does not compensate, this is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Remove' with a specific resource 'placed symbol' and adds the side effect 'and any directly attached wire segments'. This clearly distinguishes it from sibling tools like sch_delete_wire, which only removes wires.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it, nor does it reference any related tools. The mention of 'directly attached wire segments' implies deletion of wires might be done separately, but this is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint: true already informs the agent about destructiveness. The description adds that the directive is persisted for future runs, but does not disclose whether it appends or replaces existing directives, or what file/state is modified. It does not contradict the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and free of extraneous detail. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 covered. However, the description does not explain the destructive side effects or how to integrate with simulation workflows. It is minimal but not entirely insufficient for a one-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the parameter name 'directive' with no description (0% coverage). The description merely repeats 'SPICE directive' without explaining valid syntax, constraints, or examples. It fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Persist' and resource 'SPICE directive', and specifies that it is used for future MCP simulation runs. This distinguishes it from sibling tools like sim_run_* which execute analyses rather than configure them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used before running simulations, but does not explicitly state when to use it versus alternatives, nor provide any exclusions. It is not misleading, but the guidance is vague and underdeveloped.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral effects. 'Write matched-length rules' implies a mutation, but it does not state whether existing rules are overwritten, how the rules are applied to the board, or any side effects on DRC. No prerequisites or reversibility information is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the verb and object. No unnecessary words or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (3 params, no nested objects) and has an output schema, so return values are covered. However, with no annotations and no such detail in the description, the tool lacks behavioral context: side effects, prerequisites, and relationship to other tuning/checking tools. The description is too terse for a mutation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 clarifies that both net names refer to the positive and negative nets of the differential pair, and that the target length is the matched length to be applied to both. However, it does not explain units (though the parameter name implies mm) or whether the target is exact, minimum, or maximum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool writes matched-length rules for both nets in a differential pair. It uses a specific verb ('write') and resource ('matched-length rules for both nets'), distinguishing it from sibling tools like tune_track_length or route_tune_length which target single-ended traces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for differential pair length matching by specifying 'both nets in a differential pair'. It provides clear context but does not explicitly mention when not to use it or name alternatives like si_validate_length_matching or route_differential_pair, so it falls just short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description is the sole source of behavioral info. 'Show' implies a read-only operation, which is helpful, but the description does not explicitly state that it's non-destructive or mention behaviors like handling of uncommitted changes or the requirement for an existing project/checkpoint. It adds minimal behavioral context beyond the function name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no filler. It front-loads the action and resource, every word earned its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the core function and parameter intent. But without annotations, it lacks explicit mention of being read-only and any prerequisites or error conditions. An output schema exists (not shown) to explain return values, but the description could still state what a diff includes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the parameter name and type (string) with no description (0% coverage). The description adds context that the commit_hash refers to a checkpoint commit, which clarifies the parameter's meaning. However, it doesn't explain how to obtain a valid hash or the exact format expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Show' and identifies the resource ('diff versus a checkpoint commit'), clearly distinguishing this from sibling VCS tools like vcs_restore_checkpoint (a write/restore operation) and vcs_list_checkpoints (a listing operation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It doesn't mention that vcs_list_checkpoints can be used to find valid commit hashes, nor does it state any prerequisites (e.g., initialized VCS). The agent is left to infer usage from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It states the tool emits warnings, implying a non-mutating check, but it does not disclose whether any board state is modified, what the warning output contains, or any prerequisites. The verb 'warn' gives basic but not rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise, front-loaded sentence with no wasted words. It immediately states the condition and action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter check tool with an output schema, the description is adequate but minimal. It lacks explicit usage guidance and does not clarify whether it acts on the current board or uses a provided net list. The existence of the output schema reduces the need to describe return values, but more context could improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description must compensate. It indirectly references the single parameter ('routed signals' for 'signal_nets') but does not explicitly explain the parameter format or semantics. The parameter is self-evident due to its name and type, but the description adds minimal added value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Warn when routed signals share layers with split non-ground planes' uses a specific verb ('warn') and clearly identifies the resource and condition. It distinguishes itself from sibling EMC tools by focusing on split non-ground plane crossing, not via stitching, ground plane voids, or return path continuity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is a diagnostic EMC check, but it does not explicitly state when to use it versus other EMC checks, nor does it provide exclusions or alternatives. The user must infer usage from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true, covering the mutation risk. The description adds the layer adjacency constraint, which is useful behavioral context, but does not disclose other traits like validation behavior or state effects. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single eight-word sentence that is front-loaded with the action and the core constraint. It contains no filler or redundant content, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with output schema and annotations providing some context, the tool has 7 undocumented parameters and no usage or error guidance. The one-sentence description is insufficient to fully guide an agent on valid layer names, coordinate conventions, or when to prefer this over adjacent sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 7 parameters with 0% schema description coverage, so the description must compensate but barely does. It only clarifies that from_layer and to_layer should be adjacent copper layers, leaving coordinates, defaults, net_name, and units undocumented except for implicit name hints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Add' with a specific resource 'microvia' and a key constraint 'between adjacent copper layers'. This clearly distinguishes it from sibling tools like pcb_add_via and pcb_add_blind_via by emphasizing the adjacency requirement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'between adjacent copper layers' provides clear context for when this tool is appropriate. However, it does not explicitly state alternatives or exclusions, such as using pcb_add_blind_via for non-adjacent layers, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral information beyond the readOnlyHint and idempotentHint annotations. It simply restates the tool's purpose without noting any caveats, scope limitations, or side effects, though no contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no superfluous words. It is ideally concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero-parameter, read-only nature, the description is complete. An output schema exists to define the return value, so further elaboration in the description is unnecessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the baseline score of 4 applies. The description correctly reflects a zero-argument tool, and the schema confirms 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all board nets' is a specific verb+resource statement that clearly identifies what the tool does. It distinguishes this from sibling tools like pcb_get_zones or pcb_get_tracks by focusing on nets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as get_unconnected_nets or sch_get_net_names. There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description's 'Report' aligns with read-only behavior. It adds context that results depend on the latest DRC view, but does not clarify if DRC is automatically invoked or how stale data is handled.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the core purpose and no redundancy. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a simple 0-parameter query with an output schema, the description suffices. Minor ambiguity about the scope of 'board items' and the exact dependency on DRC, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema fully covers this aspect. The baseline for zero-parameter tools is 4; the description adds no parameter semantics, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Report' with the resource 'currently unconnected board items' and qualifier 'using the latest DRC view', clearly indicating a read-only diagnostics tool. It is distinguishable from sibling tools like get_unconnected_nets, though it does not explicitly name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'using the latest DRC view' implies the tool is intended to be used after running DRC, but it does not explicitly state when to prefer this over alternatives like get_unconnected_nets. There is no exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation openWorldHint signals potential side effects, and the description adds that the tool stages a file and explains the import step. However, it does not disclose whether staging overwrites the file, what happens to existing files, or any preconditions, leaving the exact behavior partially opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core actions ('Stage... and explain...') with no filler or redundant repetition. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no required fields, the description provides minimal viable coverage of the tool's purpose. However, it omits workflow context, such as how this fits into the broader routing/import process, and leaves ambiguity about the parameter semantics, making it only partially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must clarify the 'ses_path' parameter. It indicates the path relates to a Specctra SES file, but it is ambiguous whether this is the source file to stage or the destination location. The description adds some meaning but does not fully compensate for the lack of schema detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs 'Stage' and 'explain' and a specific resource (Specctra SES file), explicitly mentioning the KiCad import step. This distinguishes it from sibling routing tools like route_export_dsn, which export DSN files, and route_autoroute_freerouting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a workflow placement ('explain the KiCad import step') but does not explicitly state when to use this tool or mention alternatives. It lacks guidance on prerequisites or exclusions, such as when a SES file is ready for import or if other import methods should be considered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool conveys safety. The description adds no behavioral details beyond the action itself, such as what constitutes a mismatch or how results are returned. It neither contradicts nor significantly enriches the annotation baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence with no filler. It is front-loaded with the action and the objects being compared.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the purpose is clear and output schema likely documents return values, the description omits any context about when to run this check, what 'references' means in practice, or how it differs from sibling validation tools. For a zero-parameter validation tool, this is adequate but minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there are no parameter semantics to explain. The baseline for no parameters is 4, and the description does not need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 the two resources: PCB footprint references and schematic symbol references. This clearly distinguishes it from broader validation tools like validate_design or run_drc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 run_drc, validate_design, or pcb_sync_from_schematic. The description only states what it does without contextual cues or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides no additional behavioral context beyond the annotations. It does not disclose file side effects, overwrite behavior, or prerequisites. Given openWorldHint and destructiveHint are already in annotations, the description adds no context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single five-word sentence, direct and without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and an output schema, the description is sufficient for basic understanding, though it lacks usage guidance or context about the IPC-2581 format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is trivial; baseline 4 applies as no parameter descriptions are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (Export) and the specific resource (IPC-2581 manufacturing data), distinguishing it from sibling export tools like export_gerber or export_bom.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool over alternatives like export_gerber or export_manufacturing_package is provided; usage is only implied by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description doesn't need to restate safety. It adds 'from DRC' as source context, but does not explain whether it runs DRC or uses existing results, nor behavior when no violations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of seven words, front-loaded with the verb 'Return'. Every word earns its place, conveying the purpose without any redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters, an output schema present, and clear annotations, the description is nearly complete for a simple read-only tool. It could mention that a DRC run must have occurred, but this is implied by 'from DRC' and the sibling tool run_drc.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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. The description doesn't need to explain parameters since there are none; the schema is trivially complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return' and the specific resource 'silkscreen overlap issues from DRC'. It distinguishes itself from sibling tools like run_drc (general DRC) and get_courtyard_violations (different violation type).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 run_drc or get_courtyard_violations. The description simply states what it returns without implying or excluding use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose that this is a file-based operation modifying the .kicad_pcb file and that it can replace mismatched footprints. However, it leaves several behavioral aspects unexplained, such as the meaning of allow_open_board, use_net_names, or the effect of grid/scale/origin parameters on placement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with a clear summary, and each sentence adds essential information. There is no redundancy or filler, making it appropriately concise while still covering key behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 lacks details about prerequisites (e.g., open project, schematic loaded) and does not explain the majority of input parameters. It provides a high-level workflow but leaves significant gaps for a tool with eight parameters and no annotation support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description only explains one parameter (replace_mismatched) and vaguely mentions data sources like schematic references and rotations. The remaining seven parameters (grid_mm, scale_x, scale_y, origin_x_mm, origin_y_mm, use_net_names, allow_open_board) are completely undocumented in both schema and description, so the description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool syncs missing PCB footprints from schematic footprint assignments, with a specific verb ('sync') and resource (PCB footprints). It distinguishes itself from siblings like pcb_auto_place_by_schematic by framing this as a file-based footprint-add operation for initial board bring-up.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'intended for initial board bring-up' provides clear context for when to use the tool. It also explains the effect of the replace_mismatched parameter, but it does not explicitly mention alternatives or exclusions, such as when to use pcb_auto_place_by_schematic instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description carries the full burden. 'Check whether' strongly implies a read-only analysis, but it does not explicitly state that no modifications occur, nor does it describe the basis for 'sufficient' (e.g., IPC standards) or return behavior. It adds some transparency about purpose but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no superfluous words. It efficiently states the tool's purpose and immediately communicates its function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values are documented elsewhere. The description provides enough context for a straightforward analysis tool: it identifies the target (routed copper for a net) and the criterion (load current). It does not mention prerequisites (e.g., net exists, copper routed) but these are implied by the domain. Overall, it is mostly complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 mentions 'load current' which maps to expected_current_a, but does not explain ambient_temp_c or max_temp_rise_c. However, these parameter names are self-explanatory (with clear units), and the defaults provide further context. The description adds marginal value beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource: 'Check whether the routed copper for a net looks sufficient for the load current.' It distinguishes itself from sibling tools like pdn_calculate_voltage_drop and thermal_check_copper_pour by focusing on current-carrying capacity of copper routing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need to verify copper adequacy for a given current) but provides no explicit guidance on when to use this tool versus alternatives. It does not name alternative tools or specify exclusions, so it only meets the 'implied usage' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful behavioral detail beyond the destructiveHint annotation: it reveals that coordinates are snapped to a grid by default and that snap_to_grid=False is needed for intentional off-grid placement. It also clarifies the coordinate system is absolute. This is valuable context not present in the annotations, though it could also mention that the schematic is modified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose first, and the second sentence adds a single important parameter behavior. There is no wasted text or repetition of schema fields. It is concise and well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters, a destructive hint, and an output schema, the description covers the tool's essence and grid-snapping quirk but does not explain the meaning of several required parameters (library, symbol_name, reference, value). The output schema exists but the description does not clarify how it is returned, though that is not required. It is mostly sufficient for a narrow placement task but lacks depth for complex usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter descriptions (0% coverage), so the description must compensate. It does explain x_mm, y_mm, and snap_to_grid behavior, but leaves the other 7 parameters (library, symbol_name, reference, value, unit, rotation, footprint) without any semantic guidance. For a tool with 6 required parameters, this is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Add') and an explicit resource ('schematic symbol') with a location ('at an absolute coordinate'). It clearly distinguishes this from sibling tools like sch_add_wire or sch_add_power_symbol, which add different object types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for grid snapping ('snap to the 2.54 mm schematic grid by default') and instructs when to override it ('only when an exact off-grid coordinate is intentional'). However, it does not explicitly mention when to use this tool over alternatives, such as sch_create_sheet or sch_add_label, nor does it state any exclusions or prerequisites like a loaded library.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, and description adds the identification method constraint. However, it doesn't disclose consequences like permanent deletion or need to save beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no filler; essential information only.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple (one param, output schema present), and description explains what and how. It lacks a note on irreversibility or effect on connectivity, but destructiveHint covers safety.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description compensates by explicitly explaining wire_id accepts a UUID or unique UUID prefix, adding functional meaning to an otherwise opaque parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Remove', precise resource 'wire segment', and identification method 'UUID or unique UUID prefix', clearly distinguishing from sibling delete tools like sch_delete_symbol.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides no guidance on when to use this tool versus alternatives such as sch_delete_symbol or sch_add_wire. It doesn't mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare readOnlyHint=true and idempotentHint=true, but the description adds no further behavioral details, such as whether wires are returned across all sheets or just the current sheet, or whether bus wires are included. It merely restates the basic function already evident from the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no extraneous words. It is front-loaded and immediately conveys the tool's purpose without any unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, the output schema exists, and the annotations cover safety. The description clearly states what the tool does, but it leaves minor ambiguity about the scope of 'schematic' (all sheets vs. current sheet). Overall, it is adequate for a no-parameter list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter meaning to explain. The schema coverage is trivially 100%, and the baseline for no-parameter tools is 4, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource as 'all wires in the schematic,' which distinguishes it from sibling tools like sch_get_symbols, sch_get_labels, and sch_get_net_names. It is unambiguous and accurately reflects 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, such as using sch_get_net_names for nets or sch_get_symbols for components. The usage is implied by the tool name and description, but no context is provided about prerequisites, exclusions, or alternative scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description must carry the behavioral disclosure burden. 'List' implies a read-only operation, and 'candidate pins and units' adds useful context, but it does not disclose prerequisites, side effects, or failure modes. It meets the minimum bar without being rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that front-loads the verb and object. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single required parameter and an output schema, the description covers the basic purpose but omits any guidance on the component_ref parameter or prerequisites. It is minimally adequate but leaves some ambiguity about invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, and the tool description never mentions component_ref or explains how it selects candidates. The only semantic hint is the parameter name and the schema title 'Component Ref,' which is insufficient for an agent to reliably know what value to provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('candidate pins and units'), and orients the action within a 'swap workflow.' This clearly distinguishes it from sibling tools like sch_swap_pins and sch_swap_gates, which perform the swap itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'can participate in a swap workflow' provides clear context for when this tool is useful—as a discovery step before swapping. It does not explicitly name alternatives or exclusions, so it falls short of a 5, but the intended usage is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses meaningful behavioral traits—'deterministic' and 'Manhattan'—and the prerequisite that pins are 'placed.' However, it does not mention side effects such as whether existing wires are deleted or modified, which is a notable gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the action verb and object, and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core action is clearly stated and an output schema exists, so return values may be covered elsewhere. Still, with no annotations and no parameter guidance, the description leaves side effects and exact routing behavior under-specified for a tool that writes to the schematic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 what 'ref1', 'pin1', 'ref2', 'pin2', or 'snap_to_grid' mean. It only hints at 'two placed symbol pins,' leaving the parameter semantics largely to their somewhat self-explanatory names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Route') and clearly identifies the resource and action: 'deterministic Manhattan wire segments between two placed symbol pins.' This distinguishes it from generic wire-adding tools and other routing tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use the tool: when you need to connect two placed schematic symbol pins with Manhattan wire segments. However, it does not explicitly mention alternatives or when not to use it, so it misses the 'exclusions' part of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It states the basic action but omits important details such as whether the created variant becomes active, what happens on name conflicts, or any side effects on existing variants. This is a significant transparency gap 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately conveys the core purpose and the optional cloning behavior. Every word contributes value, with no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool with an output schema available, the description covers the essential behavior and parameter semantics. However, the absence of any annotations means operational context (e.g., prerequisites like an active project, or whether the new variant is auto-activated) is not addressed. The output schema helps with return values, but a bit more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 0%, the description must compensate. It adds meaningful semantics by indicating that 'name' is the new variant's name and that 'base_variant' is an existing variant to optionally clone. This clarifies both parameters' roles, though it does not specify exact format or constraints (which the schema partially covers via types and default).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Create a new design variant') and scope ('optionally cloning an existing variant'). It effectively distinguishes this tool from siblings like variant_list, variant_set_active, and variant_export_bom by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (for creating variants) but does not explicitly state when to use this tool over alternatives, nor does it mention any prerequisites or exclusions. The optional cloning behavior hints at a use case, but no when/when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries full responsibility for behavioral disclosure. It does not explicitly state that the tool is read-only or side-effect-free, nor any limitations (e.g., lists only active variant, requires a loaded project). The description only states what it lists, not what it does beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary action and adds one useful detail ('basic component counts'). There is no redundancy or wasted words, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 and the simplicity of the tool, the description covers the core functionality well. However, it lacks explicit context about the scope (e.g., current design) and the meaning of 'available' (active variant vs all defined variants), which could be ambiguous for an agent. This prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the baseline is 4. The description adds no parameter information, but none is needed. 'Basic component counts' hints at output rather than parameters, so the score matches the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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 'available design variants', also adding 'basic component counts' as a differentiator. Sibling tools like variant_create or variant_set_active are clearly distinct, so the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as variant_diff_bom or variant_export_bom. There is no mention of when to inspect variants or how this relates to other variant tools. Usage is only implied by the tool name and the general action of listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, establishing a safe read operation. The description adds the 'enabled' filter but does not explain further behavioral details like whether it returns layer names or includes copper/non-copper layers; the output schema presumably covers the return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the verb and object with no unnecessary words. It is appropriately sized for a zero-parameter operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with good annotations and an output schema, the description sufficiently conveys its function. The term 'enabled' is slightly ambiguous but understandable in a PCB context, and the simplicity of the tool means no additional context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. No additional parameter details are needed, and the baseline for 0-param tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'enabled board layers', clearly indicating a read-only enumeration. The qualifier 'enabled' differentiates it from related tools like pcb_get_stackup or pcb_get_footprint_layers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives. With many sibling layer-related tools (e.g., pcb_get_stackup, pcb_get_footprint_layers), explicit disambiguation would be valuable, though the zero-parameter nature makes it easy to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe, side-effect-free read. The description adds 'currently selected items', which clarifies the resource but does not describe return format, behavior when selection is empty, or any other context beyond what the annotations imply. This is adequate but not rich, consistent with a baseline of 3 when annotations cover the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action ('List') and immediately specifies the resource. Every word earns its place; there is no waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter read-only getter with good annotations and an output schema, the description is sufficiently complete. It names the resource and action; no further context is needed. It compares well to the HIGH calibration example where a filtered-list tool with annotations received a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is an empty object. Per calibration, 0 params gives a baseline of 4; there is nothing for the description to explain. The description does not need to add parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List currently selected items in the PCB editor' clearly states a specific verb ('List') and resource ('currently selected items in the PCB editor'), which distinguishes it from sibling tools that target specific object types (e.g., pcb_get_nets, pcb_get_vias). The purpose is immediately apparent and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 does not mention scenarios such as retrieving the current selection before operations like pcb_block_create_from_selection, nor does it contrast with other getters. The single sentence only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds the scope 'all' but does not disclose return format, layer handling, or other behavioral details. It aligns with the annotations, providing some additional context beyond them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded with the action and resource, and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, an output schema exists for return values, and annotations cover read-only/idempotent behavior, the description is sufficient. It fully explains what the tool does without needing additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides full coverage. Baseline for 0 params is 4, and the description does not need to explain parameters. The lack of param details is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all board copper zones' uses a specific verb ('List') and clearly identifies the resource ('board copper zones'), making the tool's function unambiguous. It is distinct from sibling tools like pcb_get_nets or pcb_get_shapes, so no confusion with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like pcb_add_zone or pcb_refill_zones. There is no mention of prerequisites, exclusions, or alternative tools, leaving usage context entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description carries the burden and adds valuable behavioral details: it reads existing symbols first, avoids overlapping new symbols, and treats non-listed fixed symbols as immovable obstacles. It stops short of disclosing side effects like whether existing symbol positions are overwritten, but for a placement tool the mutation is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the primary purpose, and the second adds critical behavioral context. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and key safety behavior, and with an output schema present, return-value details are not necessary. However, it leaves a significant gap regarding the default placement scope (what happens when symbol_list is null) and does not explicitly distinguish itself from the similar sch_auto_place_functional tool in the sibling list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does add meaning: 'strategy' is clarified as choosing from cluster/linear/star layouts, and 'symbol_list' is implied to be the list of references to place, with non-members as obstacles. However, it fails to explain the default behavior when symbol_list is null, leaving ambiguity about whether it uses the current selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Auto-place') and the resource ('selected references'), and specifies distinct layout methods ('deterministic cluster, linear, or star layouts'). It also differentiates from legacy behavior, giving a precise scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use cases through its behavior description (e.g., avoiding overlapping placements, treating fixed symbols as obstacles) but does not explicitly state when to use this tool over siblings like sch_auto_place_functional, nor does it mention exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds value by specifying that positions are 'absolute', clarifying the output coordinate system beyond simple read-only behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence with no filler. It avoids repeating schema information and directly communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 is too sparse for a 6-parameter tool with no parameter documentation. It does not specify prerequisites (e.g., symbol exists in library), coordinate reference, or rotation handling, leaving the agent to guess critical invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 only mentions 'symbol placement' without explaining x_mm/y_mm as origin coordinates, rotation units, or the role of `unit`. Parameter names are suggestive but not sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Calculate') and resource ('absolute pin positions') for a given symbol placement. It is distinct from sibling tools like sch_get_symbols or sch_get_bounding_boxes, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 the tool (after symbol placement) but does not explicitly mention alternatives or when not to use it. The context is unambiguous, but lacks exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not contradict the annotations (readOnlyHint=true, idempotentHint=true). It adds no additional behavioral context beyond what annotations already convey, but for a simple list operation, the annotations suffice.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that is front-loaded with the action and resource. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only tool with an output schema, the description is complete. The scope is unambiguous and sufficient 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no meaning. The description's 'all' clarifies the lack of filtering, adding a small but relevant semantic nuance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource as 'schematic symbols'. The word 'all' explicitly scopes the operation, distinguishing it from potential sibling tools like lib_search_symbols.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With many sibling tools, including lib_search_symbols, the description offers no contextual placement or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries the full burden for behavioral disclosure. It states 'Show' which implies read-only behavior, but does not explicitly confirm no side effects, permissions needed, or other traits. For a simple help tool, this is minimally adequate but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of nine words, front-loaded and free of filler. Every word adds value, making it an excellent example of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple help tool with zero parameters and an output schema, the description covers the essential point: it shows a startup guide and tool categories. It could slightly expand on the guide's content, but overall it is complete enough for an agent to understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% (vacuously), so there is no parameter ambiguity. Baseline of 4 is appropriate as there is nothing missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with the specific verb 'Show' and identifies the resources: 'concise startup guide and all tool categories.' This distinguishes it from sibling tool kicad_list_tool_categories, which only lists categories, by including the startup guide.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like kicad_list_tool_categories, nor any exclusions mentioned. The usage is implied as a general overview/help tool, but explicit context would improve the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the openWorldHint annotation by clarifying that the tool queries the detected KiCad CLI's advertised formats. The word 'Report' suggests a read-only operation, which is a useful behavioral signal not explicitly present in the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that is front-loaded with the purpose. Every word contributes to understanding what the tool does, with no unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter check tool with an output schema, the description is largely complete. It clearly states the tool's behavior and non-mutating intent, though it could benefit from explicit usage guidance and more concrete format values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The 'format' parameter has no schema description or enum, so the description's qualifier 'board-import format' adds some meaning. However, it does not list valid values or provide examples, leaving the agent to infer format strings from sibling tool names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb phrase 'Report whether' and clearly identifies the resource ('detected KiCad CLI') and the subject ('a given board-import format'). It distinguishes this from sibling mfg_import_* tools, which actually perform imports rather than checking support.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is a pre-import check by focusing on whether the CLI supports a format, but it does not explicitly state 'use before importing' or mention alternatives like mfg_import_geda. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description carries the full burden. It discloses that the tool produces a markdown checklist and that providing output_path saves the plan to a file, otherwise it returns text. However, it does not mention prerequisites such as needing a valid project design intent, nor does it describe error handling, file overwrite behavior, or any side effects beyond file saving. It provides some useful context but lacks deeper 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear one-sentence purpose, a bulleted list of coverage items, and concise Args/Returns sections. Every sentence adds value, and the organization makes it easy to scan. It is appropriately sized for the tool's complexity, not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description covers the essential aspects: what it does, what it produces, and the input/output behavior. It mentions the source ('project design intent') and the output format (markdown). However, it lacks information about failure conditions (e.g., missing design intent) and potential impacts. Overall, it is mostly complete for a generation tool of this scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, output_path, is fully explained in the description: it is an optional relative path for saving the plan, with an example ('test_plan.md'), and behavior when omitted (returns as text). Since the input schema has 0% description coverage, the description effectively compensates by clarifying the parameter's purpose and default behavior. It could add more constraints (e.g., allowed extensions, directory requirements) but is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Generate a bring-up test plan from the project design intent.' It specifies the output as a structured markdown checklist and lists the specific content areas (power-on sequence, protocol checks, continuity probes, visual inspection). This distinguishes it from sibling tools like mfg_generate_release_manifest by focusing on bring-up testing rather than release manifests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the tool generates a test plan from design intent, but it does not explicitly say when to use it versus alternatives or when not to use it. There are no exclusions or comparisons to other tools. Since the purpose is clear, usage is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, indicating safe, side-effect-free operation. The description adds the output format ('bounded S-expression string') and the notion of 'current board' state, but does not disclose additional behavioral traits such as output size limits or potential errors. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb and resource, containing no filler or redundant information. It is appropriately sized for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, safe annotations, and an output schema present, the description is largely complete. However, 'bounded' is ambiguous and could benefit from clarification (e.g., what bounds the S-expression), and there is no guidance on when this representation is preferable to other board accessors. Still, for a simple getter, the essential information is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is 100% by default. The description needs no parameter documentation. Baseline for 0 params is 4, and the description provides sufficient context about the return value, though it does not elaborate on the 'bounded' qualifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool returns the current board as a bounded S-expression string, with a specific verb ('Return') and resource ('current board'). This clearly distinguishes it from sibling tools like pcb_get_nets or pcb_get_board_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (when you need the board as a serialized string) but does not provide explicit comparison to alternatives or mention when not to use it. There is no exclusion guidance, but for a simple getter, the intended usage is reasonably inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the tool analyzes and explains placement issues, which is useful behavioral context. However, with no annotations to indicate read-only status or side effects, the description does not explicitly state whether the tool modifies the board or only reads it. The mention of explaining failures and warnings is a positive but limited disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise, front-loaded with the main action, and contains no redundant or irrelevant information. It is appropriately sized for a parameterless tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with an output schema, the description sufficiently conveys the tool's purpose and the nature of its output. It lacks explicit guidance on how it differs from the similar placement quality gate/report siblings, which keeps it from being a perfect 5, but it is otherwise complete for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter usage. The baseline of 4 applies because no parameter information is necessary and the schema already confirms there are no inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Score') with a clear resource ('PCB placement quality') and adds the distinctive detail of explaining both hard failures and softer warnings. This differentiates it from siblings like pcb_placement_quality_gate and pcb_placement_quality_report, which likely focus on pass/fail or reporting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a scored assessment of placement quality with explanations is needed, but it does not explicitly state when to use this tool over sibling tools such as pcb_placement_quality_gate or pcb_placement_quality_report. No alternative tools or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. The verb 'List' implies a read-only operation, but no additional behavioral details are disclosed (e.g., whether profiles are global, per-project, or mutable). This is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence conveys the tool's purpose without unnecessary words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and an output schema, the description is largely sufficient. However, it lacks any contextual hints about related tools or the nature of 'time-domain tuning profiles', which could help an agent understand when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema coverage is 100% by default. Baseline for zero params is 4, and the description adds no parameter-specific information since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('List') and the specific resource ('configured time-domain tuning profiles'), distinguishing it from sibling tools like route_create_tuning_profile and route_apply_tuning_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the verb 'List', but no explicit guidance is given on when to use this tool versus creating or applying profiles. There is no mention of prerequisites or alternative tool recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds that it operates on the 'active schematic' and produces a 'textual' graph, providing modest extra context beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence with no filler. Effectively communicates the tool's essence in one line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple signature (no params) and presence of an output schema, the description gives enough to understand the tool's basic function. However, it could benefit from clarifying what 'connectivity graph' includes or any prerequisites beyond an active schematic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so schema coverage is trivial. The baseline of 4 applies; description doesn't need to explain parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Summarize' with a resource ('active schematic') and output ('textual net connectivity graph'), clearly distinguishing it from related tools like sch_trace_net or sch_get_net_names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs alternatives like sch_trace_net or sch_get_wires. The context is implied (reading connectivity), but 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries the burden. It does add the behavioral detail that only checkpoints created by the MCP tool are listed, filtering out other commits. However, it does not disclose whether the operation is read-only, if it requires an initialized git repo, or what the output structure looks like, though the output schema covers the latter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and object. No unnecessary words or repetition, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters), presence of an output schema, and the clear sibling context, the description is largely complete. It could arguably mention that its purpose is to enumerate available checkpoints for potential restore/diff operations, but that is not strictly necessary 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%. Per the rubric, a baseline of 4 is appropriate since no parameter description is needed, and the description adds nothing more.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('checkpoint commits created by the MCP tool'). It distinguishes itself from sibling tools like vcs_commit_checkpoint, vcs_restore_checkpoint, and vcs_diff_with_checkpoint by focusing solely on listing checkpoints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a way to view available checkpoints, but it does not explicitly state when to use it versus alternatives (e.g., before restoring or diffing). No exclusions or alternative tool names are mentioned, so the guidance is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds that results come from DRC, but does not clarify whether DRC runs on demand or reads cached results, nor does it mention any dependencies. This is minimal additional context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action and resource without any filler or redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only, zero-parameter tool with an output schema, the one-sentence description is complete. The 'from DRC' qualifier provides necessary context about where issues come from, and no additional information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, which is the baseline for a 4. The description correctly avoids inventing parameter details where none exist, and the empty schema provides full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb and resource: 'Return only unconnected net issues from DRC.' It distinguishes itself from sibling DRC tools like run_drc or get_courtyard_violations by focusing narrowly on unconnected nets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when unconnected net issues are needed, but provides no explicit guidance on when to use this tool versus alternatives such as run_drc or other DRC-specific checks. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds a slight nuance with 'currently configured' indicating it reflects the current session state, but no other behavioral details are provided. This aligns with the calibration example: with annotations, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It immediately states the tool's purpose and is perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, annotations cover safety, and an output schema exists (context indicates 'Has output schema: true'), the description is sufficiently complete. It does not need to explain return values or additional context beyond what is already provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the baseline is 4. There are no parameter semantics to elaborate on, and the description does not need to compensate for any undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Show the currently configured KiCad project paths' uses a specific verb ('Show') and a clear resource (project paths), distinguishing it from sibling tools like kicad_set_project or kicad_list_recent_projects. The scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the current KiCad project paths are needed, but it does not explicitly state when to use this tool over alternatives or provide any exclusions. Given the simple getter nature, the context is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and idempotentHint, which already inform the agent of safe read behavior. The description adds that it also reports current connection status, providing useful context beyond the annotations. It does not conflict with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence, front-loaded with the action. Every word is informative, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter tool with readOnly and idempotent annotations and an output schema, the description adequately covers the tool's purpose. It mentions both aspects (version info and connection status), so the agent knows what to expect. No output schema explanation needed since it exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, so there are no parameters to describe. With 0 parameters, the baseline is 4, and the description does not need to explain parameter semantics. The description doesn't add parameter information because none exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and clearly identifies the resource (KiCad version information and current connection status). This distinguishes it from sibling tools like kicad_get_project_info, which deal with project data. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 or how it relates to other tools. No mention of alternatives or context. It is a self-contained query, but the description doesn't explain that it should be used to verify the connection before other operations. Thus, no guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, but 'List all' clearly indicates a non-destructive, read-only operation. It adds the notion of 'capabilities' beyond just categories, which enhances transparency, though it doesn't detail return structure (output schema covers that).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states exactly what the tool does with no filler. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, has an output schema, and is a simple discovery tool, the description is complete. No further context is needed for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is effectively 100% with no properties. Per the baseline rule for 0 params, the description is not required to explain parameters; the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('tool categories'), and adds 'capabilities' which enriches meaning. It clearly distinguishes from sibling tool 'kicad_get_tools_in_category' (which lists tools within a category) by implying a high-level overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'kicad_get_tools_in_category'. While the simple verb suggests it, there is no explicit context or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the read-only nature ('List') and adds the qualifier 'configured', implying only loaded libraries are returned. However, it does not detail whether symbol and footprint libraries are returned together or separately, nor any other behavioral nuances. The description is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is front-loaded with the verb and object. It contains no fluff or redundant information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and an output schema present, the description sufficiently explains its purpose. It conveys the scope (configured libraries) and the object type (symbol and footprint), which is complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema has no properties. According to the rubric, a baseline of 4 applies for 0-param tools. The description correctly says 'configured' libraries, which adds slight context, but there are no parameter details to add since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and the resource ('configured symbol and footprint libraries'), making it distinct from sibling tools like lib_list_footprints which likely lists individual footprints within a library. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its name and one-liner, but does not explicitly state when to choose this over alternatives such as lib_list_footprints or lib_search_footprints. No exclusions or alternative guidance is provided, so it falls short of a clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include destructiveHint=true, so the agent already knows this is destructive. The description adds useful context (kikit installation, output path defaults) but does not clarify what exactly gets destroyed (e.g., whether the active PCB is modified or a new file is created). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with purpose, args, and return sections. Every sentence earns its place, covering installation, parameters, and return value concisely given the need to document 6 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all parameters, return value, and installation requirement. However, it leaves some ambiguity about destructive side effects and the meaning of 'output_dir', which could matter for a destructive open-world tool. Overall it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description's Args section thoroughly documents all 6 parameters, including layout types (grid, mousebites, vcut), numeric meanings, and the default output path. This fully compensates for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool panelizes the active PCB using KiKit, creating a panel for efficient PCB fabrication. This distinguishes it from sibling mfg_* tools that handle imports, test plans, or release manifests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for PCB fabrication ('Creates a panel of multiple boards for efficient PCB fabrication') but does not explicitly state when to use it vs alternatives or provide exclusions. It mentions the kikit install prerequisite but lacks direct 'when-to-use/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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond what annotations already provide. Annotations include readOnlyHint=true and idempotentHint=true, and the description simply says 'Show', which is consistent. However, it does not disclose anything extra such as dependencies on a loaded board or units of measurement, though the output schema likely covers return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundancies. It is appropriately sized for a zero-parameter getter, earning high marks for structure and efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and an output schema present, the description is fully sufficient. It conveys the essential purpose without needing to explain return values, as the output schema covers those details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to compensate for undocumented params. According to the rubric, 0 params earns a baseline of 4. The description adequately supports the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Show the current stackup' clearly identifies the tool as a getter for the PCB stackup. The verb 'Show' and resource 'current stackup' are specific, and the name pcb_get_stackup directly distinguishes it from siblings like pcb_set_stackup and si_generate_stackup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
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. The intended use is implied by the name and the presence of pcb_set_stackup as a sibling, but the description does not state when to prefer this over si_generate_stackup or si_synthesize_stackup_for_interfaces.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds value by specifying the exact criteria evaluated (overlap-free and inside board frame), which is not disclosed in annotations. It does not describe the return format, but the output schema likely covers that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly states the tool's purpose. It is front-loaded with the verb and resource, and every word contributes to meaning. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless quality gate, the description fully explains what the tool checks. Combined with the output schema, the agent has complete information to select and invoke the tool correctly. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, there is no schema coverage issue. The description naturally adds no parameter details, but this is appropriate as no parameters exist. The baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Evaluate whether footprint placement is overlap-free and inside the board frame' uses a specific verb ('Evaluate') and resource ('footprint placement') with clear success criteria. It distinguishes itself from sibling tools like pcb_placement_quality_report or pcb_score_placement by focusing on a binary pass/fail quality gate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not state when to use this tool versus alternatives. It implies usage as a placement quality check, but there is no explicit guidance about when to invoke it (e.g., before export) or when to prefer sibling tools like pcb_placement_quality_report for detailed diagnostics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It explicitly discloses a key behavioral trait: the tool does not write to disk, implying a non-destructive, in-memory operation. While it does not explicitly state read-only status, the description plus the presence of an output schema sufficiently conveys what the tool returns and that it does not persist changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action, target, and key constraint with no filler. Every word contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter inference tool with an output schema, the description covers the essential purpose and the most important behavioral boundary (no disk write). There are no hidden parameters or complex side effects, so the description is sufficiently complete for an agent to select and invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not add parameter-level detail. Schema description coverage is trivially 100%, and the absence of parameters makes parameter semantics a non-issue; the baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool infers a design spec from the active PCB, using the specific verb 'infer' and identifying the resource. The qualifier 'without writing it to disk' helps distinguish it from sibling tools like project_get_design_spec that likely retrieve a persisted spec.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as project_get_design_spec or project_validate_design_spec. The 'without writing it to disk' hint implies a non-persistent inference use case, but no clear context or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds only the high-level behavior ('List all labels'), without extra detail like return format or handling of sub-sheets. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It conveys the essential information without any waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple, zero-parameter list operation. The output schema exists, so return values are documented elsewhere. Annotations cover safety, and the description sufficiently states what the tool does, making it complete for its low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. The baseline for 0 params is 4; the description correctly implies no arguments are needed. There is no additional parameter information to add.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('labels') and scope ('in the schematic'). It distinguishes this tool from siblings like sch_add_label or sch_get_net_names by focusing on listing all labels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied for a simple getter (when you need all labels, use this), but there is no explicit guidance on alternatives or when not to use it. The description does not mention related tools like sch_get_net_names or sch_get_symbols, so the differentiation is indirect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds useful behavioral context: it clarifies that net names are unique and are specifically derived from labels, not from other net sources. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence conveys exactly what the tool does with no wasted words. It is appropriately concise for a zero-parameter read-only tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params), strong annotations (read-only, idempotent), and presence of an output schema, the description is complete. It clearly states the tool's scope and output concept without needing to explain return structures or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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. The empty schema needs no further explanation, and the description correctly focuses on behavior rather than parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('unique net names') and a source ('derived from labels'). It distinguishes this tool from siblings like sch_get_labels (which lists labels themselves) and sch_get_nets (which might list all nets).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs alternatives. It does not mention any exclusions or conditions, leaving the agent to infer usage solely from the short phrase.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses output behavior (confirmation with saved file path, or error) and default output location, but it does not state overwrite semantics, file-system permissions, or side effects beyond saving. This is a meaningful gap for a file-writing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description opens with a crisp one-sentence summary, then uses a structured Args section and lists. It is longer than minimal, but the additional details are all functional and directly support correct invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers input contract, per-pin schema, all parameters, and return behavior. Since an output schema exists, explaining return structure is unnecessary. Minor gap: no explicit guidance about when not to use this tool, but overall the description is complete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
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 documents all seven arguments, the required pin dict structure with required/optional keys, acceptable values for pin_type and side, unit constraints, and default output_path pattern. This fully compensates for the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific action: 'Generate a KiCad symbol (.kicad_sym) from a pin table and save it.' This clearly identifies the tool's function and distinguishes it from sibling tools like footprint generation or stock checking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you have a pin table and want to create a KiCad symbol. It does not explicitly exclude alternatives or name competing tools like lib_create_custom_symbol, but the context is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only the openWorldHint annotation, the description carries the transparency burden. It clearly discloses that the tool collects files, computes SHA256 hashes, writes both manifest.json and MANIFEST.txt, and returns a confirmation. This goes beyond the annotation by specifying the side effects and the exact files produced. It does not mention overwrite behavior or failure modes, but for a generation tool this is solid disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-sentence purpose, a concise behavior summary, and clearly labeled Args and Returns sections. Every sentence adds value, and the formatting makes it easy to scan. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter, output schema present, openWorldHint annotation), and the description covers purpose, behavior, parameters, and return value. It does not explain where this fits in the manufacturing workflow relative to siblings, but that is not essential for usage. The description is sufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a property name and an empty default string for output_path, with zero description coverage. The description compensates by stating the parameter is a subdirectory inside the project and defaults to output/, which clarifies the meaning and usage. It lacks format examples, but for a single optional parameter this is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific, unambiguous action: 'Generate a SHA256-signed release manifest for the manufacturing package.' It clearly identifies the resource (release manifest) and the domain (manufacturing), and the follow-up details about hashing and recording distinguish it from sibling tools like mfg_generate_test_plan or export_manufacturing_package.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used when a release manifest is needed for the manufacturing package, and that it operates on an output directory. However, it does not explicitly say when to use it versus alternatives, nor mention any exclusions or prerequisites. The guidance is present but implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so safety is known. The description adds context by specifying the actual operations performed (DRC and ERC) and the output (readiness summary), which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence front-loaded with the action (Run DRC and ERC) and result (summarize readiness). No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and an output schema, the description covers the essential behavior and outcome. It could have explicitly mentioned its relationship to the separate run_drc and run_erc tools for better contextual clarity, but it is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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 no parameter schema to elaborate on.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs DRC and ERC and summarizes readiness. This specific verb+resource+outcome distinguishes it from sibling tools like run_drc and run_erc, which only perform individual checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a combined DRC/ERC validation with a readiness summary, but does not explicitly state when to use this tool instead of running run_drc and run_erc separately or other quality gate tools. This is a clear but implied usage without exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe read operation. The description adds no further behavioral details, such as whether it runs a new DRC or queries existing results, but this is acceptable given the strong annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short, direct sentence that states the tool's purpose without waste. It is immediately understandable and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter read-only tool with a defined output schema and strong annotations, the description is complete. It clearly states what the tool returns, and the output schema covers return value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (empty properties). The description does not need to explain parameters. Baseline for 0 params is 4, and the description adds no confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Return only courtyard issues from DRC' uses a specific verb ('return') and resource ('courtyard issues from DRC'), clearly distinguishing it from broader DRC tools like run_drc and other violation-specific siblings such as get_silk_to_pad_violations. It precisely states its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'only courtyard issues' implies this tool is for filtering DRC results to courtyard-specific problems, giving some contextual guidance. However, it does not explicitly name alternatives or state when not to use it, though the 'only' phrasing effectively excludes general DRC checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds the behavioral detail that data comes from KiCad's config files, which implies read-only access. However, it does not disclose potential edge cases (e.g., empty list, missing config) or explicitly confirm non-destructiveness, relying on the verb 'list'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action ('List') and resource ('recently opened KiCad projects'), with no unnecessary words or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and a provided output schema, the description fully suffices. It identifies what is listed and the data source, and since an output schema exists, return-value details are not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema is empty, so the baseline is 4. The description does not need to explain parameters, and it adds no parameter-related info beyond the tool's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists recently opened KiCad projects and even specifies the source (KiCad's config files). This is a specific verb+resource combination that distinguishes it from sibling tools like kicad_scan_directory or kicad_get_project_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by indicating it reads from config files, which is appropriate for a simple list tool. It does not explicitly state when to use vs alternatives, but the tool's unique function is clear from the name and description, and no close sibling exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It clearly implies a non-destructive planning operation ('Returns per-ball via coordinates... so the agent can call pcb_add_via and pcb_add_track'), but it never explicitly states that the tool does not modify the board. It also does not mention potential error conditions or constraints (e.g., support for specific BGA shapes), which leaves some behavioral aspects under-disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently organized: a one-sentence purpose, a workflow sentence, and a structured Args list. Every sentence adds value, and the parameter details are essential given the sparse schema. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, workflow, parameters, return type, and prerequisite/follow-up tools. It is missing explicit edge-case or limitation statements (e.g., valid ball grid types, error scenarios), but for a planning tool with this level of disclosure it is quite complete. The return description is minimal but an output schema exists to supplement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for all six parameters. The Arg list provides detailed semantics for every parameter, including ball dict keys, defaults, units, and strategy meanings. This goes well beyond the bare property names and types in the JSON schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Generate a BGA fanout via-placement plan', specifying the verb, resource, and strategy variants. It also explicitly distinguishes itself from the physical placement tools by stating it returns a plan for use with pcb_add_via and pcb_add_track.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear workflow context: it returns a plan for the agent to use with pcb_add_via and pcb_add_track, and explicitly directs the agent to pcb_get_pads for actual pad coordinates. It stops short of enumerating when-not-to-use or alternative planning tools, but the guidance is strong for a tool with no close siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the readOnlyHint and idempotentHint annotations and adds no contradictory information. However, it provides no additional behavioral context beyond these annotations, such as scope (e.g., all vias on all layers) or return format details. The annotations carry the transparency burden, so a baseline score is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that states exactly what the tool does without any filler. It is optimally concise and well-structured for its simple purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only listing tool with an output schema and strong annotations, the description is complete. It provides enough context for an agent to understand the tool's purpose and invoke it correctly. No additional behavioral details are necessary given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, so the schema fully covers parameter semantics (vacuously). The description adds no parameter-specific details, but with zero parameters, the baseline score of 4 is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List board vias' uses a specific verb ('List') and a distinct resource ('board vias'), clearly differentiating it from sibling tools like pcb_get_tracks or pcb_get_pads. The purpose is unambiguous and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage for retrieving vias from the board, but it does not explicitly mention alternatives or exclusions. The context is clear for a simple list operation, though it lacks an explicit 'when not to use' or reference to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, and the description's 'Return' aligns with those. The description adds useful context by specifying that the spec includes explicit and inferred fields, and 'resolved' implies it reflects the post-inference state, adding value beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the verb 'Return' and conveys the essential information without redundancy. Every word earns its place; no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only getter with an output schema present, the description is fully sufficient. It clearly states what is returned (resolved design spec with explicit and inferred fields). The existence of an output schema means return value details need not be spelled out, and annotations cover safety traits.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the input schema is empty, so the description carries no parameter burden. Per the rubric, zero params warrant a baseline of 4. The description is not required to explain any parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and a well-defined resource ('resolved project design spec'), and clarifies that it includes both explicit and inferred fields. This distinguishes it from sibling tools like project_get_design_intent (raw intent) and project_infer_design_spec (inference step).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool returns the final combined design spec, but it does not explicitly state when to use it over alternatives (e.g., 'use this after inference' or 'instead of project_get_design_intent'). Usage context is inferred from the wording 'resolved' and sibling names, but no direct guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 clearly states the output content (Er, loss tangent, frequency range) but does not mention that this is a read-only listing or any limitations (e.g., no filtering, no custom materials). For a simple list tool, this is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first clearly states the tool's function with key output attributes, the second gives a practical usage tip. No wasted words, front-loaded, and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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, the description doesn't need to enumerate return fields. It covers the core purpose and provides a critical integration hint with a sibling tool. For a simple list operation, this is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is trivial. Per the rubric, a zero-parameter tool receives a baseline of 4, and the description doesn't need to explain any parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'List all built-in dielectric materials' with the exact attributes returned (Er, loss tangent, frequency range). This clearly distinguishes it from sibling SI tools that calculate or synthesize, and it names a specific sibling for downstream use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context: 'Use the returned material keys with si_synthesize_stackup_for_interfaces() to select the appropriate laminate for your design.' This tells the agent when and with what to pair this tool, though it doesn't provide explicit 'when not to use' or alternative comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states the side effect of saving a file, the default output path, and the return behavior (confirmation with file path or error). However, it does not mention whether the tool overwrites existing files, creates directories, or depends on a project context, which would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured into clear sections: purpose, supported packages, Args, and Returns. While longer than a minimal two-sentence description, each element adds necessary value and there is no redundant or fluff content. The package list is extensive but informative for selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 10 parameters, empty annotations, and lack of schema descriptions, the description covers the essential aspects: purpose, supported package types, all parameter semantics, output location, and return value. It does not enumerate every possible failure mode or prerequisite (e.g., existence of output_dir), but it is sufficient for correct tool invocation in most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description's Args section explains every parameter in detail, including units, defaults, and special cases (e.g., body_w_mm defaulting to body_l_mm for QFP). This fully compensates for the missing schema documentation and makes parameter usage clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Generate an IPC-7351B compliant KiCad footprint (.kicad_mod) and save it', which clearly states the specific verb (generate), resource (footprint), and output format. It also lists supported package families, making it easy to distinguish from sibling tools like lib_search_footprints or lib_create_custom_symbol.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool by listing supported packages and providing parameter explanations, giving a clear context for generating footprints per IPC-7351B. It does not explicitly mention alternatives or exclusions, but the package list establishes a clear applicability boundary and the default behavior is well described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 the dry_run default, explains that setting dry_run=False modifies the project by calling pcb_set_net_class(), and states the return value. It could add more about side effects or failure modes, but the main mutating behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a short summary, a behavior paragraph, and clearly labeled Args/Returns sections. Every sentence adds useful information without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the workflow, the dry-run mechanism, and the return value, and an output schema exists. It could mention error cases or what happens when interfaces lack impedance targets, but it is sufficiently complete for the tool's moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description's Args section compensates by explaining both parameters: interfaces are InterfaceSpec dicts from project_get_design_spec(), and dry_run controls execution vs. planning. The InterfaceSpec structure isn't fully elaborated, but the reference to the design spec function gives enough semantic grounding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Map interface specs') and clearly identifies the resource (KiCad net classes) and action (generating pcb_set_net_class calls). It distinguishes itself from lower-level tools like pcb_set_net_class by operating on design intent interfaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it processes interfaces with impedance targets and can run as a dry-run or execute changes. It references project_get_design_spec() as the input source, which implies when it should be used, though it doesn't explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It explains post-search filtering, ranking, source options, and the return format, adding real behavioral context. It does not disclose potential network/external API dependencies or error behavior when no parts match, which prevents 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The docstring is concise and well-structured: a one-line purpose followed by Args and Returns sections. Every line adds useful detail, including examples and type hints, with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description thoroughly covers all input parameters, the nested requirements object, and expected outputs, especially given the existence of an output schema. It lacks explicit error semantics or ranking criteria, but the overall workflow is well-specified and sufficient 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description's 'Args' section fully compensates. It explains all six parameters with practical examples, allowed values, and meaning—especially the nested 'requirements' dict with min/max formats and common keys—far exceeding raw schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Recommend a purchasable part given electrical requirements,' which is a specific verb+resource+context statement. It also details the return value ('Ranked list of part recommendations') and parameter scope, clearly distinguishing it from sibling search tools like lib_search_components or lib_find_alternative_parts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is clear: recommend a part based on electrical specs, with examples of category keywords and requirement keys. However, it does not explicitly state when to use this vs alternatives or provide exclusionary guidance, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms it generates a report (implying non-destructive), but with no annotations provided, it carries the burden of explicitly stating its safety. It doesn't explicitly say 'read-only' or note any side effects, though the report nature strongly implies it. It does disclose what the report contains, which adds some 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, all informative. It front-loads the action, lists the content areas, and gives usage context without any fluff or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no params and an output schema exists (so return values are already specified), the description covers the purpose, the contents, and when to use it. It is sufficient for an agent to select and invoke this tool correctly in the context of many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivially 100%. Per the rubric, a 0-param tool gets a baseline of 4. The description adds meaningful context about what the report integrates, though it doesn't need to explain parameters since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Generate a comprehensive design-status report' and lists exactly what it combines (intent summary, v2 spec richness, gate evaluation, next steps). This distinguishes it from sibling tools like project_quality_gate_report by emphasizing it as a comprehensive overview rather than a focused gate check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends this as 'the recommended first call after opening a project to understand its current state.' This gives clear when-to-use guidance and implicitly differentiates it from more specialized tools that are used later or for specific checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring readOnlyHint and idempotentHint, the description adds value by emphasizing that the intent is 'persisted' and explaining its role in placement/release gates. This is useful context beyond what annotations provide, with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence conveys the core purpose and context without redundancy or filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, read-only, output schema provided), the description fully covers what the tool does and its role relative to project gates. No further information is necessary for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the input schema fully defines the calling contract. The description does not need to add parameter details; the baseline for zero-parameter tools is a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Show') and clearly identifies the resource: the persisted project design intent used by placement and release gates. It is immediately distinguishable from sibling tools like project_set_design_intent or project_get_design_spec.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by noting that this design intent is 'used by placement and release gates', which implies when the tool is relevant. However, it does not explicitly name alternatives or state when not to use it, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description carries the burden and does well: it discloses that the tool reads bounding boxes, picks the smallest A4-A1 size with a configured margin, only grows (not shrinks), and reports when no change is needed. It doesn't discuss side effects or configuration details, but the core behavior 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with the main action, followed by concise operational details and return values. Three short paragraphs with no redundant phrasing; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description fully explains behavior, conditions, algorithm, and return. It's complete and self-contained, even without needing an output schema explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so per rubric the baseline is 4. The description mentions a 'configured margin' but doesn't explain where it's set, which is a minor gap. However, no parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states a specific verb+resource: automatically grow the sheet to fit all placed symbols. It explains the algorithm (bounding box, standard paper size selection) and distinguishes it from manual sheet resizing (sch_set_sheet_size) and other schematic tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after placing symbols and describes the decision logic (no change if fits). While it doesn't explicitly name alternatives or exclusions, the auto-fit behavior is unambiguous and sufficient for an agent to select this tool over the manual sch_set_sheet_size.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the action (list), the object (child sheets), and the scope (active top-level schematic), which implies a read-only operation and immediate children. This adds valuable context beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded and contains no unnecessary words. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return values, and the tool has no parameters. The description sufficiently specifies the exact scope ('child sheets from the active top-level schematic'), making it complete for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the input schema is empty. The description correctly avoids adding parameter info. A score of 4 is the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' with a clear resource 'child sheets' and a defined scope 'from the active top-level schematic.' This effectively distinguishes it from sibling tools like sch_create_sheet and sch_get_sheet_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying it operates on the active top-level schematic. It does not explicitly mention alternatives or exclusions, but the scope is well-defined and implies when to use this tool versus other sheet-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It clearly discloses that the tool reads a CSV, applies rotation offsets from a bundled table, and writes a corrected file. It also explicitly states that dry_run returns a preview without writing, which is a key behavioral side effect. It does not detail error conditions or overwrite behavior, but the core side effects are transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with clear paragraphs and an Args section. Each sentence contributes essential information—input format, transformation logic, output destination, and return values. It is appropriately sized for the tool's complexity and avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides everything an agent needs to select and invoke the tool correctly: purpose, workflow context, expected input columns, parameter meanings, and return behavior. The presence of an output schema reduces the need to describe return structures in detail, and the description still summarizes the return type. It is complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining each parameter: cpl_csv_path (required input), output_path (with default behavior), and dry_run (with effect). This adds meaning well beyond the bare schema property definitions and ensures correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Apply JLCPCB CPL rotation corrections to a KiCad-exported pick-and-place CSV.' It clearly distinguishes itself from sibling export tools by focusing on correcting existing CPL files for JLCPCB, not merely exporting. The mention of 'direct upload to JLCPCB' further clarifies the exact purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clearly implied: use this after a KiCad CPL export and before JLCPCB upload. It states what the tool does and its role in the workflow. However, it does not explicitly name alternative tools or state when not to use it, leaving some ambiguity about selection among similar manufacturing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clarifies the tool is non-mutating ('computes optimised X/Y positions', 'Returns: JSON string') and does not apply changes directly, contrasting with tools that modify the board. It also notes it doesn't require KiCad to be open, but does not describe side effects or edge cases (e.g., handling of fixed components).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a front-loaded purpose sentence, a usage note, and a clear Args section. Every sentence adds value: the intro explains the algorithm and non-KiCad benefit, the usage note directs next steps, and the Args block documents all parameters. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, algorithm coefficients), the description is fully complete: it explains the input structure, the algorithm behavior, the return format, and how to apply the result. The output schema presence is supplemented by the 'Returns' line, and the lack of annotations is offset by the explicit non-mutating nature. It provides all necessary context for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero descriptions for its 7 parameters, but the description's 'Args' section comprehensively documents each key, including types, units, defaults, and optionality (e.g., 'w (float, mm, optional default 2)', 'fixed (bool, optional default false)'). This fully compensates for the schema gap and adds meaning beyond the raw JSON schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Run a force-directed spring-embedder placement algorithm on a set of components.' It clarifies this tool only computes positions ('computes optimised X/Y positions') and does not apply them directly, explicitly pointing to pcb_move_footprint for applying results. This distinguishes it from placement tools that actually move components, such as pcb_auto_place_by_schematic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: 'Use it to get a placement suggestion, then apply the result with pcb_move_footprint for each component.' This states when to use the tool and how to proceed, and it notes the tool works 'without requiring KiCad to be open' as a benefit. However, it does not explicitly state when not to use it or mention alternative placement algorithms.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, and the description adds meaningful context: server-side fixes are applied, re-evaluation happens each iteration, and the loop can stop early. It also discloses the agent handoff behavior. This goes beyond the vague annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-sentence summary, a numbered list of iteration steps, a clear stop condition, and a compact Args section. Every sentence is informative and no filler exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description covers the full execution flow: evaluation, auto-fix application, agent-action branching, iteration limits, and early termination. It leaves no significant behavioral gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly explains max_iterations with its purpose, range (1–20), and default behavior. Since the schema provides no per-parameter description (0% coverage), this explanation fully compensates and adds real value for selecting an appropriate value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Run the project quality gate and automatically apply server-side fixes.' It distinguishes itself from sibling tools like project_quality_gate and project_quality_gate_report by focusing on the auto-fix and re-evaluation loop rather than just checking/reporting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly explains the iterative process and when the loop stops, including when agent action is needed. It implies usage context (fixing failed quality gates) but does not explicitly contrast with alternative tools or state when not to use it. Still, the behavioral flow provides strong contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explains the algorithm (reads schematic, builds occupancy grid) and the return format (a list of coordinate pairs). It discloses that it is a read-only operation by nature, though it doesn't explicitly state side-effect-free or performance limits beyond max count. This is solid behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear summary line, then a short algorithm note, a usage directive, an Args section, and a Returns section. Every sentence earns its place; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a relatively simple query tool with 3 parameters and no required params. The description explains the return format, the defaults, and the inteded usage context. It lacks explicit notes on failure modes (e.g., what if no free slots exist?), but given that an output schema exists and the tool is straightforward, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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: it explains count as 'Number of free coordinate slots to return (default 1, max 64)' and gives physical meaning for cell_width_mm and cell_height_mm with defaults. It could add more about how cell dimensions affect results, but it adds substantial meaning beyond bare schema names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb+resource: 'Find N collision-free placement coordinates for new symbols.' It clearly states what the tool does, distinguishes it from siblings like sch_add_symbol and sch_auto_place_symbols, and includes details about building an occupancy grid and returning coordinate pairs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this before sch_add_symbol to get safe (x, y) values,' which provides a clear when-to-use directive and names the alternative/next step. It also implies not to use this when placing symbols manually or when you already have coordinates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description is consistent with that by stating it returns details. It adds value by outlining what the returned structured template includes (parameters, symbols, nets, placement hints) and by tying template_name to sch_list_templates output. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the primary purpose. It uses a clear Args/Returns structure, every sentence adds value, and there is no redundant filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only tool with an output schema, the description sufficiently covers what the tool does, the input semantics, and the nature of the return value. The annotations handle safety, and the output schema handles detailed return structure, so no additional information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates with an Args section that explains template_name comes from sch_list_templates() and provides a concrete example ('buck_converter_generic'). This fully compensates for the missing schema description and adds practical usage guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return full details for a subcircuit template' with a specific verb and resource. It distinguishes itself from sibling tools like sch_list_templates (which lists templates) and sch_instantiate_template (which instantiates), and it enumerates the contents of the returned details (parameters, symbols, nets, placement hints).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates a prerequisite: template_name must be 'as returned by sch_list_templates()', which gives clear context on the expected input source. However, it does not explicitly state when to prefer this tool over alternatives or provide exclusionary instructions, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given destructiveHint=true, the description adds useful context beyond the annotation: it notes the operation changes paper dimensions, lists supported sizes, and prescribes that sch_auto_place_functional should be called again afterward. It also discloses that a confirmation with old and new dimensions is returned, which is not in the schema. No contradictions found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with purpose, usage context, supported sizes, and follow-up instruction in separate paragraphs. It is verbose but every sentence adds value—no filler, and it is front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with a destructive annotation and an output schema, the description covers when to use, what it does, parameter semantics, post-condition, and return value. The only minor gap is not naming the sibling alternative sch_auto_resize_sheet, but the description is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% because the schema property lacks a description, but the description fully compensates by defining 'paper' as a target paper size keyword, listing all supported values (A4, A3, A2, A1, A0, A, B, C, D, E, USLetter, USLegal), and stating the default 'A3'. This exceeds what the bare schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Change the schematic sheet (paper) size', providing a specific verb and resource. It also lists supported sizes and clearly distinguishes itself from siblings like sch_auto_resize_sheet by implying manual size selection, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states 'Use this when the current sheet is too small to fit all symbols' and references a concrete trigger from sch_auto_place_functional warnings, plus a follow-up action to re-place symbols. However, it does not mention alternative tools (e.g., sch_auto_resize_sheet) or exclusion cases, so it falls short of the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It clearly states the tool 'recommends' a stackup rather than modifying anything, and notes that cost_tier 'Overrides material selection' — a behavioral nuance. It also defines the returns as 'human-readable markdown, ready to pass to pcb_set_stackup()', implying it is a read-only analysis. It does not explicitly say 'does not modify the design', but the language is indicative enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-sentence summary, a bulleted list of outputs, a compact Args section, and a Returns section. Every line adds informative value with no fluff or redundancy. The front-loaded purpose sentence makes intent immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex synthesis tool, the description covers all necessary aspects: inputs (with parameter semantics), outputs (recommended stackup and net class table), and integration context (feed to pcb_set_stackup and pcb_set_net_class). Even though an output schema exists, the description still outlines the return format sufficiently. No critical information appears missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must fully explain parameters. It does: 'interfaces' format is detailed (must have at least 'kind', optional impedance_target_ohm, differential, diff_skew_max_ps), cost_tier values are mapped to materials ('standard' = FR4, 'midloss' = FR4 mid/low-loss, 'highspeed' = Rogers/Megtron), and board_thickness_mm lists valid values (1.0, 1.6, 2.0, 3.2). This goes well beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific verb and resource: 'Synthesise a PCB stackup that meets the impedance requirements of the given interfaces.' It lists concrete outputs (layer count, dielectric material, copper weight, etc.), making its purpose unmistakable and differentiating it from sibling tools like si_calculate_trace_impedance or si_generate_stackup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 the tool: when you have InterfaceSpec dicts with impedance requirements and need a stackup recommendation. It also indicates the output is 'ready to pass to pcb_set_stackup() and pcb_set_net_class()', linking to downstream usage. However, it does not explicitly name alternatives or say when not to use it, so it lacks for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of conveying behavior. It clearly implies a read-only listing operation through the verb 'List' and by contrasting with the later 'add' step. It also explains what a template is (pre-wired subcircuit blueprint) and gives examples, which helps set expectations. It does not explicitly state 'this does not modify the schematic,' but the wording makes that clear enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: one sentence states the action, one defines the resource, and one provides the follow-up workflow. Every sentence adds value, and the most important information is front-loaded. No filler or redundancy is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter list tool with an output schema, the description is complete. It explains what templates are, provides examples, and gives the next steps. The output schema handles return-value details, so the description does not need to enumerate them. It fully covers the tool's role in the larger template instantiation workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter burden on the description. The schema is empty and coverage is effectively 100%. The description does not need to explain parameters, and its focus on the tool's purpose is appropriate. The baseline for zero-parameter tools is 4, and this description meets that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'List all available reference subcircuit templates.' This clearly distinguishes it from sibling tools like sch_get_template_info (which retrieves details for one template) and sch_instantiate_template (which adds a template). It also gives concrete examples of template types, reinforcing the resource scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names the intended workflow: call sch_get_template_info() for details, then sch_instantiate_template() to add. This tells the agent exactly when to use this tool—as the initial discovery step—and which alternatives follow. It also implicitly says when not to use it: when you already know the specific template and need details or instantiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description carries the full burden of behavioral disclosure. It clearly states that the tool 'replaces the entire schematic content' and that 'any symbols already placed in the schematic will be lost.' It also discloses grid snapping, auto_layout behavior, connection-aware routing, and error handling for unroutable nets. This is comprehensive 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: statement of purpose, a prominent IMPORTANT warning, detailed behavioral notes, and a numbered workflow. Every sentence adds value; there is no padding, and the formatting improves scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature and the empty annotations, the description covers all critical aspects: what it does, what it overwrites, how to avoid data loss, how to use it correctly, its grid snapping, auto_layout behavior, error reporting, and alternatives. The output schema exists, so omitting return-value details is acceptable. This description is fully sufficient 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.
Parameters4/5
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 symbols, wires, labels, nets, coordinates, auto_layout, and grid snapping in context (e.g., 'If nets are also provided the layout is connection-aware...'). However, it does not explicitly mention the power_symbols parameter, which is a minor gap given the other parameters are well contextualized.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
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: 'Build (overwrite) the active schematic from structured symbol, wire, and label inputs.' It immediately clarifies that this is a full replacement operation, not a partial edit, and explicitly names sibling tools (sch_add_symbol, sch_add_wire, sch_add_label) as the alternatives for incremental additions, preventing any confusion with related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use and when-not-to-use guidance: it warns against using this tool for incremental edits and directs users to sch_add_symbol/sch_add_wire/sch_add_label instead. It also offers a recommended workflow with sch_find_free_placement and explains when to set auto_layout=True, giving clear contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description adds valuable behavioral context: the bounding boxes are heuristic estimates because KiCad does not expose exact extents via the file API, and they are conservative enough to avoid overlap in practice. This informs the user about reliability and accuracy, which is critical for correct interpretation of results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured. The first sentence immediately states the core functionality. The second sentence provides usage guidance and a caveat. The final sentence summarizes the returned data. Every sentence serves a purpose without unnecessary verbosity, earning it a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with an output schema, the description is complete: it explains what the tool returns, when to use it, the heuristic nature of the results, and the specific data fields included. No important information is missing, and the given context is sufficient for an agent to decide when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty object). The description does not need to explain parameter semantics, so the baseline of 4 is appropriate. It still adds value by describing the return values (centre position, corner coordinates, occupied-area summary), which complements the output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns the estimated bounding box of every symbol in the active schematic. The verb 'Return' with the specific resource ('bounding box of every symbol') and scope ('active schematic') precisely defines the tool's function. It also distinguishes itself from sibling tools by explicitly mentioning its use case for placement planning before adding symbols.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use this before calling sch_add_symbol or sch_build_circuit' to understand occupied sheet areas. This provides clear contextual guidance and references specific sibling tools, making the usage conditions unmistakable. No exclusion criteria are needed due to the tool's specific niche.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description carries full burden and succeeds: it explains functional categorization, zone layout, sheet-size reading, overflow warnings, treatment of pre-placed symbols as fixed obstacles, and the compact row-major arrangement within zones. No contradictions with annotations (none present).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose. The ASCII zone diagram and parameter/return sections earn their place, supporting the reader efficiently without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no annotations and minimal schema, the description covers purpose, usage context, zone layout, overflow handling, obstacle behavior, parameter meaning, and returns summary. It is complete for a placement tool of this complexity, even with an output schema present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines symbol_list as an optional array/null with 0% parameter coverage. The description adds crucial semantics: it's a list of reference designators, and omitting it places all symbols. This fully compensates for the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource+method: 'Place schematic symbols into semantically meaningful zones on the sheet.' It also explicitly contrasts with the basic sch_auto_place_symbols, making the tool's unique purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description directly names the alternative tool (sch_auto_place_symbols) and when to use this one for readable, professionally structured schematics. It also recommends sch_auto_resize_sheet when overflow occurs, giving clear guidance on next steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the tool's non-destructive behavior: 'It does NOT directly edit the schematic' and 'returns a structured action plan.' It goes beyond basic read/write hints by detailing what the plan includes (symbols, connections, part-search steps) and the output format (markdown).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise opening sentence, a clear non-editing clarification, and neatly labeled Args/Returns sections. Every sentence contributes meaning, and the most important behavioral detail (non-editing) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no annotations and low schema coverage, the description fully covers the tool's purpose, relationship to sibling tools, parameter semantics, and return format. It also mentions prerequisites and gives concrete usage guidance, making it complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully. Each parameter is explained with meaning and examples: template_name is sourced from sch_list_templates(), prefix is illustrated with 'PWR_' producing 'PWR_U1', and params is shown as a dict override example '{"vout_v": 5.0}'. This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Instantiate a subcircuit template — returns a structured action plan,' which clearly identifies the tool's purpose and scope. It further distinguishes itself from direct-editing tools by explicitly stating 'It does NOT directly edit the schematic,' making it specific and differentiated from siblings like sch_add_symbol.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('use the plan as a guide for calling sch_add_symbol, sch_add_wire, lib_recommend_part, etc.') and what not to expect ('does NOT directly edit the schematic'). It also references a prerequisite, 'template_name (from sch_list_templates()),' providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![kicad-mcp-pro MCP server](https://glama.ai/mcp/servers/Valxyria/kicad-mcp-pro/badges/card.svg)](https://glama.ai/mcp/servers/Valxyria/kicad-mcp-pro)

Score Badge

Copy to your README.md:

[![kicad-mcp-pro MCP server](https://glama.ai/mcp/servers/Valxyria/kicad-mcp-pro/badges/score.svg)](https://glama.ai/mcp/servers/Valxyria/kicad-mcp-pro)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Valxyria/kicad-mcp-pro'

If you have feedback or need assistance with the MCP directory API, please join our Discord server