jlceda-mcp-server
Server Quality Checklist
Latest release: v1.4.0
- Disambiguation3/5
Many tools are clearly distinct, but several clusters overlap: four move-component tools (auto_place, move, relocate, batch_move), three routing tools, and multiple health/status checks (ping, bridge_status, feature_support) create selection ambiguity. Generic delete_selected also overlaps with type-specific delete tools.
Naming Consistency3/5Most tool names follow a pcb_/sch_/calc_ prefix with snake_case, but verbs are inconsistent (get vs list vs query) and several names are noun-first or report-like (pcb_bom_export, pcb_netlist_report, pcb_design_health_report, pcb_net_connectivity_check). The mixed conventions are still readable and the prefix system provides some structure.
Tool Count2/559 tools is well beyond the 25+ threshold and feels heavy even for a PCB/schematic design server. The count is inflated by many one-off checks/report tools and overlapping variants that could be consolidated.
Completeness4/5The toolset covers the main PCB lifecycle: components, tracks, vias, pours, keepouts, silkscreen, differential pairs, equal lengths, DRC, net connectivity, BOM, calculations, and schematic import/export. Minor gaps remain (e.g., direct component/footprint editing or net editing), but agents can work around them with delete/recreate or pcb_execute_code.
Average 3.2/5 across 57 of 59 tools scored. Lowest: 1.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 5 community issues answered or closed in the last 6 months
- 5 commits in the last 12 weeks
- Last stable release on
- 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.jsonto 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?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It only states the action without explaining side effects, requirements (e.g., selected nets), or what happens to existing groups. There is zero indication of operational behavior beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, but it does not earn its place because it merely restates the tool name. It is under-specified rather than concise, providing no value beyond the structured fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has two parameters, no output schema, and no annotations, the description is drastically incomplete. It lacks context on what an equal-length group is, how the operation affects the design, return results, or any operational constraints. This is inadequate for an agent to use the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides; both 'name' and 'nets' have descriptive labels in the schema, and the description does not clarify format, constraints, or usage nuances.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '创建等长组' is a direct Chinese translation of the tool name 'pcb_create_equal_length', essentially restating the name. It identifies the action and resource but adds no distinction from sibling tools like pcb_list_equal_lengths or pcb_delete_equal_length beyond the obvious 'create' 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/5Does 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. While it is implied for creating an equal-length group, there is no mention of prerequisites, exclusions, or related tools that might be more appropriate in certain contexts.
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?
With no annotations provided, the description carries the full burden. It only states 'Export netlist' with no mention of side effects, expected output, permissions, or whether it writes a file or returns data. Completely silent on behavior beyond the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short phrase, which is concise, but it is under-specified. It does not front-load any useful information beyond the tool name's meaning; it is more of a tautology than a helpful summary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is still inadequate. It omits critical details like supported formats, how the netlist is delivered, and integration with other schematic tools. The tool could be better specified with a sentence about output behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for the single 'type' parameter, so the baseline is 3. The description adds no additional parameter context, but the schema already explains '网表格式' (netlist format).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '导出网表' (Export netlist) provides a verb and resource, but lacks specificity about what kind of netlist, format, or context. It is distinguishable from siblings like sch_generate_from_netlist but not clearly differentiated in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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_netlist_report or sch_generate_from_netlist. No context or prerequisites are mentioned.
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?
没有提供任何注解，描述“创建过孔”仅重复了工具名，未披露任何行为细节，例如是否会将过孔连接到指定网络、是否要求现有网络存在、是否破坏性操作、是否有撤销机制等。描述未承担在无注解时应有的行为透明义务。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
描述仅一句话（实为一个短语），没有传达任何超越工具名的信息，属于过度简化而非简洁。对于包含5个必填参数的创建工具，缺少参数关系、前提条件或返回信息等必要内容，结构上不完整。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
工具具有5个必填参数、无输出schema、无注解，复杂度较高；仅凭“创建过孔”无法帮助代理正确完成调用。缺少关于参数单位、坐标参考系、电气连接行为、错误条件等关键上下文，不足以支撑可靠使用。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
输入schema覆盖了全部5个参数，且每个参数都有名称和单位说明，因此基线为3。描述本身没有额外解释参数之间的约束关系（如drill必须小于diameter、net是否必须存在），但schema已提供足够的参数语义基础。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
描述“创建过孔”明确指出了动作（创建）和对象（过孔），在PCB上下文中是清晰的。但未与同类创建工具（如pcb_create_component、pcb_create_copper_pour）做任何区分，故扣1分。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
描述完全没有说明何时使用此工具、是否需要先选择网络或板层，也没有提供与其他工具（如pcb_delete_via、pcb_route_track）的替代关系。仅靠工具名和参数隐式推断使用场景。
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?
With no annotations provided, the description carries the full behavioral disclosure burden, but it only says 'draw routing.' It does not explain whether this creates a new track, modifies the board, requires an existing net, performs design-rule checks, or what side effects occur. This is effectively a behaviorally opaque description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
'画走线' is extremely short, but this is under-specification rather than appropriate conciseness. For a tool with four required parameters and no annotations, the description lacks even the minimal structure needed to orient an agent, resembling the low-scoring 'Process' example.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, and the description is only a three-character phrase. It does not cover return values, behavior, preconditions, or usage context, making it severely incomplete for correct invocation in an agentic workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool description adds no parameter-level explanation, but the input schema provides descriptions for all four parameters (net, layer, width, points). Since schema description coverage is 100%, the baseline of 3 is appropriate and the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '画走线' translates to 'draw routing/track,' which conveys a specific action on a specific resource. However, it does not explicitly distinguish itself from sibling tools like pcb_auto_route_nets or pcb_route_differential_pairs, so it lacks clear sibling 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/5Does 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_auto_route_nets or pcb_create_via. The description does not mention any preconditions, exclusions, or preferred scenarios, leaving the agent to infer usage entirely from the name and schema.
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 merely states the creation action without describing side effects, potential constraints (like whether nets must exist), error conditions, or reversibility. 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it is under-specified—it does not convey usage context or behavioral details. While not overly verbose, it lacks substance, similar to a title rather than a functional description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the PCB domain and the many related tools (e.g., pcb_list_diff_pairs, pcb_delete_diff_pair, pcb_route_differential_pairs), the description fails to explain how creating a differential pair integrates with existing nets or routing workflows. No output schema is present, and the description does not hint at return values or outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions (e.g., 'name', 'posNet', 'negNet'). The description adds no extra meaning beyond the schema, so the baseline score of 3 applies since the schema already documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '创建差分对' (Create differential pair) clearly states the action and resource but lacks differentiation from sibling tools like pcb_route_differential_pairs or pcb_delete_diff_pair. It is not a tautology, but it provides no additional scope or distinguishing 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/5Does 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 description does not mention prerequisites (e.g., existing nets) or differentiate from pcb_route_differential_pairs, which likely handles routing after pair creation.
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 of behavioral disclosure. It only states a read-like query action with no mention of output format, filtering semantics, or any behavioral traits. The optional filters (net, layer) are implied but not behaviorally explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only six Chinese characters with zero waste, but this brevity is closer to under-specification than deliberate conciseness. For a tool with only two optional parameters, the minimal length is defensible, yet it provides insufficient value to the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must compensate. A query tool with optional net/layer filters should explain what tracks are returned (e.g., all tracks if no filter, list format, endpoints). The one-line description is inadequate for a tool operating in a complex PCB context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% - both 'net' and 'layer' parameters have descriptions in the schema. Per the baseline for high coverage, the description need not add parameter detail, and it adds nothing beyond the schema. The schema already documents the optional filters adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '查询走线段' (query track segments) states a clear verb (query) and resource (track segments). However, it is extremely terse and does not distinguish this from sibling get-type tools like pcb_get_pads, pcb_get_net_primitives, or pcb_get_silkscreens, all of which are similar query operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 query tools (get_pads, get_net_primitives, get_netlist, get_silkscreens), the absence of any differentiation or contextual usage hints leaves the agent guessing.
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 'delete' but does not explain side effects (e.g., whether the differential pair's components or tracks are affected), reversibility, or any confirmation steps. This is a significant gap 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.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (a single phrase) but lacks substance, making it under-specified rather than appropriately concise. It does not earn its brevity by conveying rich constraints; it omits essential behavioral context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and no output schema, the description should clarify what gets deleted and any implications. It merely restates the action, offering no guidance on how the operation affects the board or how it relates to other diff-pair tools. The minimal context leaves the agent uncertain about consequences and prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single 'name' parameter with a description ('差分对名称'), providing 100% coverage. The tool description adds no additional meaning or context for the parameter beyond what the schema already declares, aligning with the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '删除差分对' translates to 'delete differential pair', clearly indicating the action (delete) and the target resource (differential pair). It is specific enough to differentiate from other deletion tools like pcb_delete_tracks or pcb_delete_via, though it doesn't add extra scope or nuance beyond the literal translation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 to alternatives like pcb_delete_tracks or pcb_list_diff_pairs. There is no mention of prerequisites, such as selecting a differential pair or its members, nor any conditions under which deletion is appropriate.
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?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states 'delete tracks' but does not mention side effects (e.g., irreversible removal), error handling for invalid IDs, or scope limitations. This is a significant gap 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of a single concise phrase with no wasted words. However, it is only a translation of the tool name, offering no extra information. Conciseness is good, but it borders on tautological.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should provide more context. It does not explain the return value, potential failures (e.g., invalid IDs), or whether the operation affects other elements. The low complexity of the tool does not excuse the absence of these details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the only parameter primitiveIds with a Chinese description '走线图元 ID 列表' (track primitive ID list). Since schema coverage is 100%, the description adds no additional meaning beyond what the schema already provides, matching the baseline for well-documented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '删除走线' clearly translates to 'Delete tracks', specifying a verb (delete) and a resource (tracks). It distinguishes from sibling tools by the resource type, but it is essentially a restatement of the tool name in Chinese without additional nuance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_delete_selected or pcb_delete_via. No context about typical scenarios, prerequisites, or exclusions 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?
No annotations are provided, and the description only states the purpose without disclosing any behavioral aspects such as whether it is read-only, potential side effects, or output format. For a ping-like operation, it is likely safe but this is not 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no unnecessary words, fully front-loaded with the purpose. It is highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without annotations, output schema, or parameter details, the description is insufficient to fully understand the tool's behavior. The term 'bridge' is undefined, and the return value or status semantics are unclear. Given the existence of similar tools, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the baseline score is 4 per the guidelines. The description adds no parameter information because none exist, so it meets the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Check bridge connection status' which has a clear verb and resource, but it is ambiguous what 'bridge' refers to and does not distinguish from sibling tool 'pcb_bridge_status' which likely has a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does 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 sibling 'pcb_bridge_status' exists and could be a more appropriate choice, but no such comparison is made.
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, and the description fails to disclose any behavioral traits such as whether the DRC check is read-only, whether it modifies the schematic, or what side effects might occur. The description carries the full burden and does not meet it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one phrase), which is concise in word count but under-specified for a DRC tool. It lacks structure and necessary details, making it less 'appropriately sized' than a balanced description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a DRC tool, the description is incomplete: it does not explain what DRC does, what the 'strict' mode entails, what the output or results are, or whether the operation has side effects. Given no output schema and no annotations, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'strict' is described in the schema as '是否严格模式' (strict mode). The description adds no additional meaning beyond the schema's own description, and schema coverage is 100%, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '运行原理图 DRC' clearly states the action (run) and resource (schematic DRC), and the 'sch' prefix distinguishes it from the sibling pcb_run_drc. However, it is terse and does not elaborate on the scope or purpose beyond the literal translation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_run_drc. There is no mention of context, prerequisites, 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 no annotations provided, the description must disclose behavior and it does not. It mentions the action but not whether changes are destructive, reversible, or if there are side effects on other board elements. This is a mutation tool with no safety 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, a single short sentence, and communicates the essential purpose without waste. This is appropriate for a zero-parameter tool, though it is slightly under-specified in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is nearly complete, but it omits usage context and behavioral side effects. It is adequate for basic understanding but lacks depth for a mutation tool that reorganizes board elements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 schema is complete. The description adds value by explaining the tool operates on all silkscreens and the goal is to avoid overlap, which is meaningful given the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool automatically arranges all silkscreens to avoid overlap. It is specific enough about the action and resource, but it does not clearly differentiate from sibling tool pcb_move_silkscreen, which also deals with silkscreen positioning but likely manually.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 manual silkscreen movement or other auto-placement tools. It also does not mention any prerequisites or expected board state, leaving the usage context unclear.
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 for behavioral disclosure. It only states that a rectangular keepout is created, with no mention of coordinate interpretation, default layer behavior, potential overlaps, or 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise phrase with no redundant information. It is appropriately front-loaded, though it leans toward under-specification rather than providing meaningful guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple rectangular keepout creation with a fully documented schema, the description provides the basic purpose. However, it omits context such as which PCB/document the keepout applies to and any effects on existing design elements, so it is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the parameter descriptions already explain the coordinates and the optional layer field. The tool description adds no extra parameter semantics beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '创建矩形禁布区' clearly states the tool creates a rectangular keepout area, using a specific verb and resource. It is distinguishable from siblings like pcb_delete_keepout and pcb_create_copper_pour, 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/5Does 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 when a keepout is needed for routing restrictions. There are no explicit contexts, prerequisites, or comparisons 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?
No annotations are provided, so the description must carry the behavioral disclosure burden. It only restates the delete intent and gives no information about irreversibility, side effects on routed tracks/constraints, or whether confirmation is needed. This is a significant gap 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short Chinese phrase with no filler or repetition, making it concise and easy to parse. It is under-specified in content but structurally appropriate for such a simple tool and parameter set.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter delete tool with no output schema and no annotations, the description gives the core operation but lacks context about expected outcomes, error conditions, or relationship to pcb_list_equal_lengths and pcb_create_equal_length. It is minimally viable but leaves behavioral gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single 'name' parameter described as '等长组名称'. The tool description adds no additional parameter semantics, but the schema already documents it adequately, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '删除等长组' clearly states the action (delete) and resource (equal-length group), which aligns with the tool name and is easy to understand. However, it does not add differentiation from sibling deletion tools beyond the resource name, 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/5Does 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 pcb_delete_diff_pair or pcb_delete_tracks. No mention of preconditions, related list/create tools, or scenarios where deletion 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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only says 'delete keepout' and does not mention whether deletion is permanent, whether it affects other PCB elements, or how the primitiveId should be obtained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded with no filler. While it is perhaps too sparse to provide complete context, it is not bloated and every word is relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one fully documented required parameter and no output schema, so the minimum information needed to invoke it is present. However, the absence of behavioral and usage context leaves meaningful gaps for an agent deciding whether to perform this destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the required primitiveId parameter is already documented. The description adds no additional meaning about how to acquire or validate the ID, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '删除禁布区' clearly states the action (delete) and the resource (keepout area), so the basic purpose is understandable. However, it essentially restates the tool name and does not explicitly differentiate it from sibling delete tools beyond the resource 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/5Does 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 pcb_delete_selected or pcb_delete_pour. It provides no prerequisites, exclusions, or contextual hints.
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 simply says 'Delete copper pour' without revealing that this is a destructive operation, whether it is reversible, or if there are any impacts on connected traces or nets. For a mutation tool, this is insufficient 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct phrase with zero waste, which is appropriately concise. It front-loads the core action. However, it is arguably too terse—it could include a sentence about usage or effects without losing conciseness. Still, it is free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a delete operation with no annotations and no output schema, the description should at least mention that it deletes the specified copper pour primitive and possibly note that it is destructive or cannot be undone. The current description is minimal and leaves the agent without enough context to predict side effects or errors. For a 1-parameter tool, it is still incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the one parameter (primitiveId) with description '铺铜图元 ID'. The description adds no additional meaning beyond what the schema already states. Since schema coverage is high, the baseline of 3 is appropriate; the tool does not need to compensate for missing parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '删除铺铜' translates to 'Delete copper pour', which clearly names the action (delete) and the resource (copper pour). It is specific enough to distinguish from sibling tools like pcb_delete_tracks or pcb_delete_keepout. However, it does not elaborate on the scope or effect, so it misses a tiny bit of 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/5Does 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 any prerequisites or context. Sibling tools like pcb_delete_selected or pcb_delete_keepout exist, and there is no mention of when to choose this one. It only states the action without situational advice.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Delete via' without describing any side effects, reversibility, error conditions, or return behavior, which is minimal 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which is concise, but it lacks any structured detail. It is not verbose, but it is also under-specified; however, for a simple delete operation, the brevity is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (one parameter, no output schema), the description is minimally sufficient. However, it omits details like whether multiple IDs can be handled, any prerequisites, or what the result looks like, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full coverage for the single parameter primitiveIds with description '过孔图元 ID 列表'. The description adds no additional meaning beyond what the schema already states, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '删除过孔' clearly specifies the action (delete) and target (via), which distinguishes it from siblings like pcb_delete_tracks or pcb_delete_keepout. It is 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 Guidelines2/5Does 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 or context, and while the name implies via-specific deletion, there is no explicit usage 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?
No annotations are supplied, so the description carries the full burden. It only restates that the tool queries pad information; it does not disclose whether the operation is side-effect-free, what the returned data contains, or how an omitted designator changes 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no filler or redundancy. It is appropriately concise for a simple query tool, though this brevity sacrifices explanatory content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and no usage guidance, the description is not complete enough for an agent to fully understand return values or filter behavior. It minimally establishes the tool's purpose but leaves key invocation context to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional 'designator' parameter, with the description '元件位号（可选）' documenting its meaning. The tool description itself adds no parameter behavior beyond that, but the high schema coverage supports a baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '查询焊盘信息' (query pad information) uses a clear verb and resource, distinguishing it from sibling getters for tracks, net primitives, board info, and silkscreens. However, it is terse and doesn't specify whether it returns all pads or pads for a given designator, 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/5Does 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_get_tracks or pcb_get_net_primitives. There are no exclusions, prerequisites, or context signals, so the agent gets no selection help beyond the resource 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 provided, so the description carries the full burden of behavioral disclosure. It fails to disclose whether the move replaces existing positions, whether rotation is preserved when omitted, if the component must be selected first, or if the operation is undoable. For a state-changing operation on a PCB design, this is a significant transparency gap given the description only restates the core operation with '(mil)' units as the only addition, similar to the update_drive example scoring a 2.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, minimal sentence achieves the communication goal efficiently. While it does closely mirror the function name (pcb_move_component), it adds the target-coordinate concept and unit specification. It earns full credit for brevity, similar to the update_drive example which received a 4 for an efficient single sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 4 parameters, no annotations, and no output schema, a single sentence is insufficient. The description fails to clarify interaction with the 3 required parameters (designator, x, y), whether the optional rotation overrides or sets rotation, or how this differs from pcb_relocate_component. An agent would have trouble selecting the correct tool among the many movement-related siblings, and a Chinese-only description may add friction for an English-oriented namespaced toolset. There is clear room for the description to add operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so per rubric the baseline is 3. The description adds the unit context '(mil)', which is already mirrored in the schema's x and y parameter descriptions ('X 坐标 (mil)'). The description adds no meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '移动元件到指定坐标 (mil)' (Move component to specified coordinates) clearly states a specific verb (move) and resource (component) with target coordinates. However, it does not differentiate from siblings like pcb_relocate_component, pcb_batch_move, or pcb_auto_place_components, all of which have overlapping semantics. Clear but no sibling differentiation, hence a 4.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. Given the crowded sibling space (pcb_relocate_component, pcb_batch_move, pcb_select_component, pcb_auto_place_components), the description should clarify its unique role, such as whether it's for moving a single component by exact coordinates while preserving rotation when unspecified. No when-to-use, exclusions, or alternative hints 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'switch to the specified document', which implies changing the active document, but does not disclose side effects, safety (read-only vs. mutating), permission requirements, or whether it affects any workspace state. Significant gaps exist for a tool that alters system state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no fluff. It is appropriately sized for the tool's simplicity, but lacks structured sections like examples or context. It is concise yet not particularly rich, hence a 4 rather than 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is functional but minimal. It tells what the tool does but omits when to use it (e.g., before performing operations on a specific document) and any related details. In the context of many siblings, more workflow guidance would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'uuid' has a schema description '文档 UUID' (document UUID). Schema description coverage is 100%, so the baseline is 3. The tool description adds no extra semantic detail beyond the schema, such as where to find the UUID or any format constraints, so it stays at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '切换到指定文档' (switch to specified document) and specifies it applies to schematics or PCBs. This is a specific verb+resource statement that distinguishes it from other tools. However, it doesn't explicitly contrast with sibling tools like pcb_select_eda_window, but the intent 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/5Does 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. It lacks any context on prerequisites, workflow placement, or situations where other tools might be more appropriate. The description is purely imperative with no contextual 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?
No annotations are provided, so the description must disclose behavior. It lists a sequence of actions (read, convert, import, generate) but does not say whether it modifies the existing schematic, overwrites files, or requires specific permissions. It also does not mention potential side effects or errors. The transparency is minimal beyond the bare steps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads 'one-click' and outlines a clear sequence with arrows. Every word is functional, and the structure conveys the workflow efficiently. There is no unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool performs a multi-step generation task but lacks explanation of the tool's output or return value (no output schema). It also does not specify prerequisites like having a current PCB with a netlist report or whether the schematic is created new or modified. For a moderately complex operation, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'type' with a description ('网表格式（默认 Protel2）') that is fully covered. The tool description itself does not add extra meaning to this parameter; it only mentions the default conversion to Protel2. Since schema coverage is 100%, the baseline is 3, and the description does not enhance it further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads the current PCB netlist report, converts it to Protel2 format, and imports it into the schematic to generate something. It implies the output is a schematic generated from the PCB, which distinguishes it from simple netlist import tools. However, the exact output (e.g., a new schematic file, an update) is not explicitly stated, and it could be confused with sch_generate_from_netlist without clear 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/5Does 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 like sch_generate_from_netlist or pcb_netlist_report. It does not mention prerequisites (e.g., an open PCB document, existing netlist) or exclusions. The intended context is only implied by the steps described.
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 behavioral disclosure burden. It only states 'delete currently selected object(s)'—it does not mention irreversibility, undo support, locked objects, or actions on an empty selection. The destructive nature is implicit but 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It directly states the core function and is appropriately sized for a zero-parameter tool, though additional context would benefit other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive selection-based tool with no annotations, no parameters, and no output schema, this description is incomplete. It lacks critical context about what selection means, how errors are handled, and how it compares to sibling delete operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so per the rubric baseline is 4. The description does not need to explain parameter meanings since there are none, and it correctly omits any parameter-related detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and target (currently selected object), using a specific verb+resource structure. It distinguishes from sibling delete tools by referencing the current selection rather than a specific object type, though it could be more explicit about what 'selected' encompasses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many specific delete tools (e.g., pcb_delete_tracks, pcb_delete_pour). The phrase 'current selected' implies a prior selection step, but there is no mention of prerequisites, alternatives, or behavior when nothing is selected.
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?
描述仅说'查询'，暗示只读操作，但未明确声明无副作用、无需权限或返回内容的结构，也没有提及可能的行为限制。鉴于无注释，描述承担全部责任，但信息不足。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
描述为单一简短句子，无冗余信息，信息密度高，易于快速理解。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
工具结构简单（单参数、无输出模式），但描述未说明返回的数据结构或可能包含的图元类型，在无输出模式的情况下，代理可能对返回值有不确定性，但整体信息足以基本理解功能。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
参数'net'在输入模式中已描述为'网络名称'，模式覆盖率为100%，描述未添加额外语义。根据规则，高覆盖率下基准为3。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
没有提供何时使用此工具而非其他类似工具（如pcb_get_tracks、pcb_get_pads）的指导，没有提及替代方案或使用场景。
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 all behavioral disclosure. It only says 'capture screenshot' without mentioning any side effects (likely none) or what the output format is (e.g., image path, binary). It does not clarify if the screenshot is saved automatically or returned, leaving the agent uncertain about the return 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose with no filler. It is appropriately sized for a simple, zero-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description should at least hint at the output type or any prerequisites. It does neither. An agent using this tool would not know if it returns a file path, binary data, or updates a UI. The description is too sparse to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 adds nothing about parameters (there are none), but the schema covers 100% of them (i.e., nothing to document). The description does not provide any additional semantics about how the screenshot is configured, but that's not required given no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (capture screenshot) and the target (current PCB editor). It is specific and not a tautology. However, it doesn't elaborate on what exactly is captured (e.g., full window, active view), nor does it distinguish itself from any sibling (though no other screenshot tool exists). It's clear enough for a simple tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 or alternatives. There is no mention of typical use cases like capturing the board for documentation, debugging, or sharing. The description gives no context for selecting this tool over others.
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 available, so the description must carry the full transparency burden. It only says '获取' (retrieve), implying read-only behavior, but it does not disclose response shape, whether this is a snapshot or live state, performance implications, or safety guarantees beyond the read-only implication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the purpose and scope. Every part contributes meaning, and there is no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clearly define what 'complete state' includes; it lists components, nets, and board outline but uses '等' (etc.), leaving the full contents ambiguous. Since this is a simple zero-parameter getter, the level of detail is adequate but not rich enough for a fully self-describing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters, so there are no parameter semantics to explain. The baseline for a zero-parameter tool is 4, and the description does not need to compensate for any missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the full PCB state, including components, nets, and board outline. It is distinct from narrower siblings like pcb_get_tracks or pcb_get_board_info because it is explicitly a comprehensive snapshot, though it does not mention those 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus specific getters such as pcb_get_tracks, pcb_get_pads, or pcb_get_board_info. The word '完整' implies a general-purpose query, but no explicit when-to-use 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?
There are no annotations, so the description carries the full burden. 'List' implies a read-only operation, but no additional behavior is disclosed such as required document state, return format, or side effects. It adds no transparency beyond what the name already conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase that states the action and target without any wasted words. 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core function but lacks any detail about the output structure or operational context (e.g., whether the PCB board must be open). Without an output schema, the agent cannot anticipate the return value, but the simplicity of the tool makes this a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the schema provides no semantics. The description correctly implies no filtering or arguments are needed, matching the baseline for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 'all equal-length groups', clearly distinguishing it from sibling tools like pcb_list_diff_pairs. However, it lacks context on what constitutes an equal-length group, so slightly below maximum.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description does not mention when to use this tool, prerequisites, or alternatives, leaving the agent to infer 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，描述应承担行为披露职责，但“移动丝印文字”仅复述意图，未说明坐标是绝对位置还是相对偏移、旋转角度的作用方式、是否可撤销或失败情况，行为透明度不足。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
描述极简，没有任何冗余信息，符合前置负载要求。但整个描述更像工具名而非结构化说明，虽然简洁不等于缺失，仍因缺少必要补充信息而降一档。
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
该工具操作简单、参数少且 schema 自解释，也没有 output schema，所以描述无需解释返回值。但缺少对 x/y 是移动目标坐标还是偏移量的明确说明，以及与 pcb_auto_silkscreen 的配合方式，整体上只能算勉强够用。
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
input-schema 中四个参数均有描述且覆盖率达到 100%，x/y 坐标单位、旋转角度、丝印图元 ID 都已在 schema 中说明。描述本身没有增加参数语义，因此按高覆盖率的基线给 3 分。
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
描述“移动丝印文字”直接说明动词“移动”和资源“丝印文字”，明确区分于 pcb_move_component、pcb_auto_silkscreen 等同类工具。用途具体、无赘述，不是名称的同义反复。
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
描述没有提供任何使用时机或上下文，未说明何时应使用本工具而不是 pcb_move_component、pcb_auto_silkscreen 或 pcb_batch_move，也没有给出前置条件或替代工具建议。
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 side effects and return behavior. It says it 'checks' and 'marks' nets, but does not state whether it modifies the board, what the output format is, or if it is read-only. The behavior is only partially clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the main purpose and adds brief parenthetical details. Every word contributes to clarity without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify what the tool returns. It mentions pad counts and track segment counts and marking unrouted nets, but does not specify the return format (e.g., a report, a list, a boolean). The tool's simplicity is offset by this ambiguity, leaving the agent uncertain about how to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'nets' is described in the schema as '指定检查的网络（默认全部）' (specify nets to check, default all), which already provides full semantic coverage. The description adds no extra beyond this, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks connectivity of all nets, and elaborates with specific outputs (pad count, track segment count, marking unrouted nets). This is a specific verb-resource combination that differentiates it from sibling tools like pcb_run_drc or pcb_component_clearance_check, which address different 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/5Does 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 typical scenarios, prerequisites, or exclusions. The description simply states what it does, leaving usage context 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 provided, so the description must fully disclose behavior. It only says 'select' without explaining what happens after selecting (e.g., visual highlight, deselecting other components, or any returned confirmation). This lack of behavioral detail makes it hard for an agent to anticipate 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence without any fluff. It is front-loaded and does not waste words. However, it is too minimal to convey any auxiliary information, so it is not as structured as one might expect for a useful tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description might be marginally acceptable. However, it does not mention any requirements (e.g., component must exist) or provide any detail on what the selection implies. It is complete in the sense of naming the action, but lacks the completeness expected for a full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 100% (the single parameter 'designator' is described as 'element reference designator' in Chinese). The description does not add any extra meaning to the parameter beyond what the schema provides. Since the schema already documents the parameter, the baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '在编辑器中选中元件' which means 'select the component in the editor'. It uses a specific verb (select) and a specific resource (component), distinguishing it from sibling tools like pcb_move_component or pcb_get_state. 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/5Does 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 whether it is a prerequisite for other operations (e.g., pcb_move_component), or if it is used for visual selection or context. No exclusions or conditions 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?
With no annotations provided, the description must fully disclose behavior, but it only states a batch move operation. It does not mention coordinate semantics, behavior on missing designators, partial failure handling, or whether the operation persists immediately. This is a significant transparency gap for a mutating 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, front-loaded phrase with no unnecessary words. However, it is so terse that it under-specifies some behavioral aspects, though those are covered by the schema. It is concise but not fully complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch operation with nested parameters and no output schema or annotations, the description should provide more context about execution semantics, return behavior, or failure handling. It only defines the action, leaving critical operational details undocumented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides 100% coverage for the single 'moves' parameter with its description listing structure [{designator, x, y, rotation?}]. The tool description adds no additional parameter meaning, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '批量移动多个元件' (Batch move multiple components) uses a specific verb 'move' and resource 'components' with explicit batching scope. This clearly differentiates it from sibling tools like pcb_move_component (single component move) and pcb_relocate_component.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The batching intent is implied by the word '批量' and the plural '多个', but there is no explicit when-to-use or when-not-to-use guidance. Alternatives such as pcb_move_component for single moves are not mentioned, leaving the usage context only 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?
No annotations are provided, so the description carries the full burden. It does not explicitly state that the tool is read-only, and the output type is ambiguous due to the use of '或' (or) without clarifying conditions. It fails to disclose any side effects or dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it packs multiple output types and input variants, making it slightly dense yet still front-loaded. No wasted words, but readability could be improved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must clarify what the response will include. It mentions file lists and JSON-lines statistics but doesn't explain how outputs vary or what the exact structure is. Error handling and return format are not specified, leaving agents uncertain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter description, and the tool description does not add significant detail about the path parameter beyond what is already in the schema (directory vs file types). The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inspects .eprj3 projects and returns project index, schematic/PCB/panel file lists, or source file statistics. It uses a specific verb '检查' (inspect) and names the exact resource type, distinguishing it from sibling tools that operate on open documents or specific 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when project structure info is needed from a file path, but it does not explicitly state when to use this over other tools or mention any alternatives. No exclusions or edge cases are noted.
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 bears full responsibility for behavioral disclosure. The short phrase only conveys the basic read operation; it does not clarify whether any side effects exist, what exact state is returned, or any details about error conditions or performance implications. This is thin for a tool expected to inform an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally brief—a single phrase with zero filler—and conveys the essential purpose. It loses one point for possibly being too terse to add context beyond the tool name itself, but it demonstrates strong economy of language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (0 params, no output schema, no annotations), the description covers the basic purpose adequately but does not explain what 'state' encompasses or what an agent should expect as a return value. It is minimally viable but lacks enriching behavioral details even for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is trivially 100%. With no parameters to document, the description has no requirement to compensate for schema gaps, meriting the baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '读取原理图状态' uses a specific verb+resource ('read'/'get' + 'schematic state') and clearly indicates this tool returns the state of a schematic. It distinguishes from the sibling `pcb_get_state` by the 'sch' prefix and the Chinese wording, though it doesn't explicitly call out the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidance is provided. The context in which to use this tool versus `pcb_get_state` is implied by the name and sibling structure, but the description itself offers no when-to-use or exclusionary notes.
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?
Since no annotations are provided, the description carries the full burden. It discloses that automatic LCSC querying is unavailable due to API protection, which is useful. However, it does not mention side effects (e.g., whether it modifies the board), or details about the output structure beyond noting JSON and CSV.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise and front-loaded with the core action and result. It packs key details (aggregation options, return format) without waste, though it could benefit from a brief usage scenario.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool without an output schema, the description is reasonably complete. It explains the input mapping and the output format, but lacks details on when the tool is necessary or how the CSV/JSON are structured, which could be important for an agent to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameters, and the description adds alpha information about the format of the mapping and the reason for limitation (protected API). The schema already provides the exact structure, so the description doesn't add much beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports a PCB BOM aggregated by component name, including quantity, designators, nets, and LCSC part numbers, and returns both JSON and CSV formats. It distinguishes itself from sibling tools by being an export-specific operation, though it doesn't explicitly name an alternative for BOM export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for exporting BOM data but does not explicitly specify when to use it versus alternatives. It mentions the LCSC codes mapping requirement but does not provide guidance on when this tool is preferred over other PCB analysis tools like pcb_netlist_report or sch_get_netlist.
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 of behavioral disclosure. 'Marks violating pairs' is ambiguous—it does not clarify whether this mutates board markers, only returns a report, or has other side effects. The lack of output or side-effect details is a significant transparency gap for a check-like 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the purpose and behavior. It is front-loaded with the action and resource, 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description should specify what the agent receives after invocation—such as a list of violations, a report, or a board marker update. It also does not clarify whether this is read-only or has persistent effects, making it incomplete for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter minClearance is fully documented in the schema with units (mil) and default value (20). The description adds the concept of a threshold but does not provide additional meaning beyond the schema. This matches the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: checking minimum clearances across all component pairs and marking violating pairs below the threshold. It includes a specific verb (check/mark), a specific resource (all component pairs), and the outcome (identified violations), which distinguishes it from broader or unrelated sibling 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the description—use this when you need to verify component-pair clearance against a threshold. There is no explicit guidance about when to prefer this over pcb_run_drc or other design rule checks, nor any stated 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'place component from library to PCB' and does not disclose board mutation effects, error conditions, library-reference requirements, or what happens if placement fails. This is minimal disclosure for a state-changing 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the meaning, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 6 parameters and no annotations or output schema, the description provides only one line. It lacks usage context, return value expectations, error behavior, prerequisites, and guidance relative to auto-placement siblings. This is under-specified for an agent to invoke reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, including units for x/y and layer meaning. The description adds no parameter semantics beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '从库中放置元件到 PCB' clearly states the action (place), object (component), source (library), and destination (PCB). It distinguishes itself from sibling tools like pcb_move_component and pcb_auto_place_components by specifying placement from a library onto the board.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for placing a component from a library at a specific position, but it provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives such as pcb_auto_place_components or prerequisites like an open PCB document.
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 burden. It only states the action without disclosing side effects, such as whether existing pours are replaced, coordinate system details, or layer restrictions. The parameter descriptions add some context (e.g., layer mapping), but the overall behavioral impact is not fully 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose. It is appropriately minimal and front-loaded with the verb and object, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward creation tool with 100% schema coverage, the description is mostly complete. It could benefit from noting typical use cases or constraints, but it adequately handles the core functionality. The sibling list and schema provide sufficient context 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by specifying units (mil) and coordinate meanings (top-left, bottom-right), and layer numbers (1=top, 2=bottom), which goes beyond simple parameter names. This additional context justifies a slightly higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '创建矩形铺铜区域' clearly states the tool creates a rectangular copper pour area. It is specific and distinguishes from siblings like pcb_create_keepout or pcb_delete_pour. However, it lacks explicit mention of the net/layer context that could clarify its role among other copper-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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating rectangular copper pour, providing clear context. However, it does not explicitly state when to use this tool versus alternatives like pcb_create_keepout or pcb_delete_pour, nor does it 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?
With no annotations provided, the description must fully disclose behavior, but it only says it gets info without mentioning side effects, read-only nature, or any state dependencies. For a getter, it's likely read-only, but this isn't explicitly stated, leaving the agent guessing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the core purpose without redundant wording. It's front-loaded and efficient, with no wasted space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters or output schema, but the description only hints at the return content ('etc.' is vague). It doesn't specify the exact return structure or any error conditions, which could leave the agent uncertain about what to expect. For a straightforward getter, this is minimally sufficient but could be more detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema covers everything trivially. The description adds context about what the tool returns (board name, layers, etc.), which is helpful even though there are no params to explain. Baseline for no params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets engineering information (board name, layers, etc.) with a specific verb and resource. It distinguishes from siblings like pcb_get_state or pcb_get_tracks by focusing on board-level metadata, though it doesn't explicitly contrast with those.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or alternative guidance is provided, but the tool's name and description imply it's for retrieving basic board info. Given the large sibling list, some indication of when to prefer this over pcb_get_state or pcb_get_feature_support would improve clarity.
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 implies a read-only query and signals the output is a list ('功能列表'), but it does not disclose potential failure modes, whether the bridge connection is required, or any side effects. This is basic transparency 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, clear sentence in Chinese that wastes no words. It is front-loaded with the action verb and directly conveys the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should explain return values and context. It partially does by stating the result is a feature list, but it omits details about list contents, possible errors, and when to use the tool. Sufficient for a trivial no-param getter, but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 does not need to explain parameters, and the empty input schema is fully consistent with a no-argument capability query.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '查询 bridge 支持的功能列表' clearly states the action (query) and the resource (list of features supported by the bridge). It is specific enough to distinguish from siblings like pcb_bridge_status, though it does not explicitly mention the format or consumption of the returned feature 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/5Does 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_bridge_status or other inspection tools. There is no mention of preconditions, use cases, or 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of explaining side effects. It does disclose one key behavior — automatic disconnection of traces — but '安全搬迁' is vague about whether existing tracks are deleted, whether nets require repair, or whether the move is reversible. Additional risk/impact context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, efficiently packaging both the purpose and a key behavioral side effect. It is well front-loaded for quick agent scanning, though slightly under-specified in other areas.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderate-complexity PCB manipulation tool with no annotations and no output schema, the description gives the essential operation and a key side effect. However, it does not address important operational context such as prerequisites, failure scenarios, whether existing routes are actually deleted, or the exact meaning of 'safe' in this context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters such as x, y, rotation, and designator are each minimally described. The tool description adds no further meaning to these parameters and leaves ambiguity such as rotation units, but the schema handles the basics, making the baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the specific operation: safely relocating a component with automatic trace disconnection. The phrase '自动断开走线' distinguishes it from the sibling candidate pcb_move_component, though it does not explicitly contrast alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for relocating a component while disconnecting existing routing, but it does not explicitly clarify when to choose this tool over pcb_move_component, pcb_auto_place_components, or pcb_fanout_component. No exclusions or alternative 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?
With no annotations, the description must disclose side effects, but it only lists the pipeline steps. It does not mention that routing may modify existing tracks, what happens if DRC fails, whether it's undoable, or any other behavioral details. For a mutating pipeline, this is insufficient 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the entire pipeline flow. It is efficiently structured with a clean arrow separator, avoiding waste while delivering the essential sequence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the pipeline is clearly defined, the description omits details like whether the tool works on the whole board vs current selection (it says 'all' but not explicit), error handling, or any preconditions. It meets the minimum for a multi-step automation but lacks depth for a complex mutation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the description does not need to explain any. According to the baseline, a 4 is appropriate since no parameter clarification is required and the schema is empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a pipeline performing fanout, routing, DRC, and silkscreen repair on all components/nets. It uses specific verbs for each stage, distinguishes from siblings like pcb_fanout_component which only does fanout, and makes the integrated nature obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit when-to-use or when-not-to-use guidance. It does not compare to individual tools or mention scenarios where the full pipeline may be inappropriate. The pipeline nature is implied but not clarified for selection purposes.
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 indicates this is a read-only status check (查看 = view), but does not mention safety implications, required permissions, or potential side effects. Given zero annotations, a 3 is reasonable but it could explicitly state it's non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the purpose, and includes key output details. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter diagnostic tool, the description is adequately complete. It specifies what status is checked. However, without an output schema, it would be helpful to mention the return type (e.g., JSON structure), but given the simplicity, a 4 is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has 0 parameters; description does not need to explain parameter semantics. Baseline 3 is elevated because no parameter documentation is needed at all. The description clearly states what it returns (service ID, connection counts, active window), which adds value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function (view Bridge Server connection status) and lists specific information returned (service ID, EDA window connection count, active window). It's distinct from pcb_ping and pcb_get_state in scope, though not explicitly contrasted with them, so it loses one point for lacking an explicit 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/5Does 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 pcb_ping or pcb_list_eda_windows. The description does not provide context about typical usage scenarios 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?
No annotations are present, so the description is the sole behavioral disclosure. '查询' implies a non-destructive read, but it does not state what attributes of the silkscreen text are returned (e.g., text content, position, layer), nor whether it filters by layer or board side. This leaves the agent uncertain about output format and scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb and resource. It contains no filler or redundant information, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter, the description is minimal but lacks any indication of the return structure, such as whether it returns an array of text strings with coordinates or layers. Since there is no output schema, this information would be needed to fully understand the tool's behavior, though the low complexity keeps the gap small.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100% by vacuity. With no parameters to document, the description does not need to add parameter semantics; baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb '查询' (query) with a clear resource '所有丝印文字' (all silkscreen text), indicating a read operation. This distinguishes it from sibling tools like pcb_move_silkscreen and pcb_auto_silkscreen, which are mutating or placement operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 pcb_get_tracks or pcb_get_pads. There are no exclusions, prerequisites, or alternative suggestions, so agents 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It only says 'list', which implies a read operation, but does not explicitly confirm it is read-only, nor does it describe the return format or any 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase with no unnecessary words. It is appropriately sized and front-loaded, with every word contributing to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool, the description is minimal but sufficient to convey the basic purpose. However, it lacks any detail about output format, read-only nature, or scope (e.g., current board), making it somewhat incomplete given no output schema or annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100%. According to criteria, the baseline score for 0 params is 4; the description does not need to add parameter info since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '列出所有差分对' (List all differential pairs) clearly states the verb 'list' and the target resource 'differential pairs', distinguishing it from sibling tools that create/delete diff pairs or list other element types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other list tools for tracks or pads. It only states the action without any contextual use cases 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?
No annotations are provided, and the description only says it generates a report. It does not explicitly state that it is read-only, whether it modifies any PCB data, or what the output format looks like. For an unannotated tool, this leaves behavioral expectations 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the purpose and scope without redundant words. Every word contributes to understanding, and it avoids unnecessary length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only report tool with no parameters, the description covers the core functionality but lacks specifics about the report's output format, structure, or usage context. Without an output schema, the agent must infer what the report returns. The description could be more complete by stating the expected output type or typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, so the baseline of 4 is appropriate. The description's mention of 'from PCB pad data' implies the source input, though no further parameter details are needed. It adds meaning beyond the empty schema by explaining the data source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 'netlist report from PCB pad data', specifying the direction (component→pin→net and net→component). This distinguishes it from sibling report tools like pcb_bom_export or pcb_design_health_report by focusing on netlist content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_get_netlist or pcb_get_net_primitives. It fails to mention prerequisites, use cases, or exclusions, which is essential for a reporting tool among many.
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 the routing style (parallel L-shaped, negative net offset by gap) and that it reports length deviation. However, it does not state whether existing traces are removed/replaced, which objects are mutated, or how the deviation report is delivered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single compact sentence, front-loaded with the core action and containing the method and report behavior. Every phrase earns its place with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating 4-parameter tool with no annotations and no output schema, the description covers the core routing behavior but leaves gaps: no return-value format, no side effects, no mention that pairName defaults to all pairs, and no preconditions. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with defaults for all four parameters, so the baseline is 3. The description adds context for gap as an offset between nets, but this largely restates the schema's '正负线间距' and adds no new parameter-specific syntax or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's specific verb+resource: differential pair auto-routing, with the routing method (parallel L-shaped traces, negative net offset by gap) and a distinct output (reports length deviation). This differentiates it from siblings like pcb_route_track, pcb_auto_route_nets, and pcb_create_equal_length.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as existing differential pairs, nor does it contrast with pcb_auto_route_nets, pcb_create_diff_pair, or pcb_create_equal_length. The only signal is the tool name and implied use case.
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 available, so the description carries the full burden of behavioral disclosure. It only restates that DRC will be run; it does not mention whether this is read-only, what happens when violations are found, what output is produced, or whether the design 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is immediately clear and contains no filler or unnecessary detail. It is appropriately sized for its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the minimal description is workable, but the lack of annotations and output schema leaves meaningful gaps: the agent is not told what DRC results look like or whether the tool has side effects. The description is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description has no parameter semantics to explain. With no parameters, the baseline of 4 is appropriate since there are no gaps to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description '运行 PCB 设计规则检查 (DRC)' clearly states a specific action (run) on a specific resource (PCB DRC). It distinguishes this tool from siblings like pcb_drc_autofix and sch_run_drc by explicitly naming DRC as the task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not explain when to use this tool versus alternatives such as pcb_drc_autofix, pcb_component_clearance_check, or sch_run_drc, 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?
With no annotations provided, the description must fully disclose behavioral traits. It mentions auto-fixing but does not state that it modifies the design, what exactly is changed beyond silk-screen conflicts, whether changes are reversible, or any side effects. The promise of a before/after comparison is vague about its format and safety implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action (run DRC and auto-fix) and includes the current scope (silk-screen conflicts) and output (before/after comparison). It is concise with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool that can alter the design, the description is incomplete. It does not explain the format of the before/after comparison, whether the tool requires an open document, if it is idempotent, or what happens when other fixable issues exist beyond silk-screen conflicts. No output schema exists, so the description carries the load for expected results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema trivially covers 100% of parameter semantics. Per scoring guidelines, baseline for 0 params is 4. The description adds no parameter info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs DRC and automatically fixes issues, specifically silk-screen conflicts, and returns a before/after comparison. It distinguishes itself from sibling tools like pcb_run_drc by the auto-fix behavior, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for automated DRC fixing but does not explicitly state when to use it versus alternatives like pcb_run_drc (for manual run) or pcb_move_silkscreen/auto_silkscreen (for targeted fixes). No 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?
No annotations are provided, so the description must carry the full burden. It mentions the underlying method (setNetlist) and supported formats, adding some context about behavior, but does not disclose side effects (e.g., whether it overwrites existing schematic, requires a specific document to be open, or has restrictions on netlist size). The mention of 'official' hints at reliability but is insufficient for full 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the main purpose, followed by a short list of formats. It is efficient, but the format list is a bit cryptic (e.g., 'DISA/DSNET') without explanation, which could be seen as slightly wasteful for users unfamiliar with those terms. Otherwise, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and minimal annotations, the description should ideally explain what the tool returns (e.g., success indication, generated schematic). It also lacks prerequisites (e.g., must have a schematic open) or error conditions. The description is adequate for a simple import tool but misses key context for an agent to fully anticipate the outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, describing both parameters, so the baseline is 3. The description adds format context for the 'type' parameter (lists formats) but does not add semantics for 'netlist' beyond what the schema's example already shows. No additional format syntax or validation details are provided, so it does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (import netlist to generate schematic) with a specific resource (sch_Netlist.setNetlist) and lists supported formats, distinguishing it from siblings like sch_get_netlist and sch_generate_from_pcb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for netlist-based schematic generation and lists formats, but does not explicitly state when to use this versus alternatives like sch_generate_from_pcb or when not to use it (e.g., for PCB generation). It lacks explicit exclusions or alternative pointers.
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 burden. It discloses the dual-mode behavior (forward calculation vs reverse calculation) and supported transmission line types, but does not mention edge cases like parameter validation, error handling, or what happens when both width and targetImpedance are 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the primary purpose and lists supported modes. 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 7 parameters with 100% schema coverage and no output schema. The description covers the core functionality and mode selection, but given the complexity of impedance calculations (multiple modes, mutual exclusivity of width/targetImpedance, differential spacing requirements), it could benefit from noting that spacing is required for differential modes and clarifying the reverse-calculation behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds the key semantic that width and targetImpedance are mutually exclusive (二选一), which is valuable. However, it doesn't explain the relationship between parameters beyond that, and the schema already covers defaults and units.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's dual purpose: calculate PCB trace impedance or reverse-calculate trace width from target impedance. It explicitly lists supported modes (microstrip/stripline/differential), which distinguishes it from sibling tools like calc_trace_width.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (PCB impedance calculation) but does not explicitly state when to use this tool versus calc_trace_width, which appears to be a closely related sibling. 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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only states the purpose and does not mention whether the tool is read-only, has side effects, or what output format to expect. This lack of behavioral transparency is a significant gap, though the 'calc' prefix suggests a non-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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence in Chinese that includes the purpose and the relevant standard (IPC-2221). There is no redundant information, and 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple calculation tool with no output schema, the description is adequate to convey the core function. However, it does not specify the result unit (e.g., mil or mm), error conditions, or any behavioral notes, leaving some gaps for an agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% parameter description coverage, so the tool description does not need to add parameter details. The description mentions 'current-carrying requirements' which maps to the 'current' parameter, but adds no additional semantic value beyond the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calculates the minimum trace width based on current-carrying requirements, referencing the IPC-2221 standard. It uses a specific verb and resource, and distinguishes itself from the sibling calc_impedance by focusing on trace width rather than impedance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context: use this tool when you need to determine trace width from current requirements. However, it does not explicitly mention alternatives or exclusions, such as when to use calc_impedance instead. The context is clear but not fully 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?
With no annotations provided, the description carries the full burden of disclosing behavior. It reveals that code runs in the extension environment and that 'eda' is the official API, but it omits crucial warnings about potential side effects, destructiveness, or permission requirements of executing arbitrary code. This is a significant gap for a code execution 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an illustrative example, front-loading the purpose and providing necessary context. Every sentence contributes value with no redundancy or filler, and the example is compact yet informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, execution environment, and provides an example, but it does not explain the output/return value format or warn about risks. Since there is no output schema, the description should clarify what the agent receives after execution, and it does not specify error behavior or that code may mutate state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both 'code' and 'windowId'. The description adds an example showing how to write a return statement, which provides practical semantic context beyond the schema's parameter descriptions. This extra example meaningfully helps the agent understand how to construct valid input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes JavaScript code directly in the JLC EDA Pro environment, with a specific verb ('执行') and resource ('JavaScript 代码'). It distinguishes itself from all sibling tools by being a generic code executor rather than a specific operation, and it explicitly labels itself as advanced/debug.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions '高级/调试用' (advanced/debug use), providing clear context for when to use the tool. However, it does not explicitly state when not to use it or mention alternatives among the many sibling tools, leaving the guidance somewhat 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 provided, so the description carries full burden for behavioral disclosure. It only says 'select' but does not explain what that entails—e.g., whether it changes the active window, affects subsequent commands, if it is reversible, or any prerequisites. This is a significant gap for a tool that sets execution 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly conveys the purpose and usage context. There is no redundant or filler content, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the basic purpose is covered, but the lack of behavioral details (e.g., how selection affects subsequent operations) leaves gaps. With no annotations, the description should disclose more to be fully complete, but it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full description coverage for the only parameter windowId, including its provenance from pcb_list_eda_windows. The description adds no further semantic meaning to the parameter, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'select' and the resource 'currently active JLC EDA window', and specifies the purpose of designating an execution target when multiple windows are open. It distinguishes from the sibling pcb_list_eda_windows which lists windows, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context: use when multiple EDA windows are open to specify the execution target. It implies when to use but does not explicitly mention when not to use or provide alternative tools, but the context is clear enough for an agent.
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 full burden of behavioral disclosure. It does reveal core behavior (moving components to pad centroids) and the locked-skip rule, but omits side effects (permanent placement changes), scope (all components vs selection), and reversibility. This is partial but not comprehensive 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured Chinese sentence that states the purpose ('自动布局'), method ('移动到其焊盘质心'), algorithm level ('一阶优化'), and exception ('锁定元件跳过') with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description explains the concept and provides the locked-skip detail, but it lacks information about operation scope, what '一阶优化' means in practice, and behavior when maxMoves is reached. These gaps make it sufficient but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter maxMoves has full schema coverage with its description ('最大移动数（默认 100）'), so the schema already carries the semantics. The tool description adds no extra meaning about how maxMoves is used in the first-order optimization, giving no value beyond structured data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool performs automatic layout ('自动布局') by moving components to their pad centroid ('移动到其焊盘质心') and skips locked ones ('锁定元件跳过'). This clearly distinguishes it from manual placement tools like pcb_move_component or pcb_batch_move.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys clear context: it is an auto-placement optimization tool that moves components to pad centroids, with locked components skipped. However, it does not explicitly mention when to prefer it over related automatic tools like pcb_fanout_component or pcb_auto_route_nets, nor does it state 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?
With no annotations, the description carries full burden. It discloses the main behavior (comparing and reporting) and implies read-only operation via 'report'. However, it does not explicitly state that no modifications are made, nor does it specify what happens if no snapshot exists or the exact nature of the 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence in Chinese, front-loaded with the core action and outcome. Every word adds value—no fluff or repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the core function and lists the types of changes reported, but since there is no output schema, additional details about the report format or return value would be helpful. It also omits any prerequisites or error conditions, making it adequate but not fully complete for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 correctly avoids adding parameter details because there are none, and the empty input schema requires no further explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares the current design with the last snapshot and reports added, removed, or moved components. It uses specific verbs ('compare', 'report') and a specific resource context, distinguishing it from sibling tools like pcb_design_snapshot (which likely creates snapshots) and pcb_get_state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reviewing design changes since the last snapshot, but it does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites like the existence of a snapshot. Guidance is implicit rather than 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?
No annotations are provided, so the description must carry behavioral transparency. It clearly states that fanout vias are created for all pads and that they belong to the same net, which is useful. However, it does not disclose side effects, constraints, reversibility, or what happens to existing traces/vias, leaving notable gaps 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact, front-loaded sentence that conveys the action, target, and net context without filler. Every word earns its place, making it appropriately concise for a one-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core operation and target, which is adequate for a simple one-parameter tool with no output schema and strong sibling context. Yet it omits potential side effects, success/failure signals, and explicit differentiation from pcb_auto_fanout_and_route, leaving the context only minimally complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter 'designator' is already described in the schema as '元件位号，如 U1'. The tool description only references '指定元件' without adding extra meaning beyond the schema, so it meets the baseline but does not enrich parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('创建扇出过孔' / create fanout vias) targeting a specific resource ('指定元件的所有焊盘' / all pads of the specified component). The added '（同一网络）' clarifies the net relationship, and the component-level scope distinguishes it from broader tools like pcb_auto_fanout_and_route.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies component-scoped fanout usage by emphasizing '为指定元件' (for the specified component). However, it does not explicitly compare with alternatives like pcb_auto_fanout_and_route or state when this tool should not be used, so it stops short of full usage 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?
With no annotations provided, the description carries the full burden. It discloses the two routing strategies and the requirement for DRC recheck, which adds valuable context. However, it fails to mention potential side effects such as modifying or deleting existing tracks, or whether it routes all nets or only selected ones.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the core action ('自动布线') and packs all key mode information compactly. There is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex board-modifying operation with 6 parameters and no output schema, the description is too sparse. It misses critical operational details like whether existing tracks are ripped up, how failures are handled, and the scope of nets affected, making it incomplete for the AI agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds cross-parameter meaning by linking 'useVias' to the two-layer L-shape mode and 'clearance' to obstacle avoidance, which goes beyond the individual schema descriptions and helps the agent understand parameter interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states '自动布线' (auto-routing) and specifies two routing modes: single-layer obstacle avoidance and two-layer L-shape with vias. This distinguishes it from manual routing tools like pcb_route_track and other auto-routing variants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when automatic routing is desired and explicitly notes that DRC recheck is needed afterward. It does not explicitly name alternatives or exclusions, but the context of 'auto' versus manual routing is clear from sibling tool names.
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 carry the transparency burden. It discloses the estimation approach and the 'mark low nets' behavior, but does not clarify whether 'mark' is a visual overlay, a persistent design modification, or a report output, and it does not mention side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one short, front-loaded sentence that packs the purpose, method, and expected outcome with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter analysis/report tool, the description is reasonably complete: it names the calculation standard, the input concept (trace width sum), and the output behavior (flagging low-capacity nets). It does not detail the report format or threshold, but the low complexity reduces the burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 adds useful semantic context by explaining that the calculation converts summed trace width per net into a current capacity estimate, which is more informative than an empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (estimate current-carrying capacity), the target resource (each net), the method (IPC-2221, sum of trace widths to current capacity), and the outcome (mark low-capacity nets). This distinguishes it from sibling report/calculation tools like pcb_design_health_report or calc_trace_width.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is implied but not explicit: it is for evaluating net current-carrying capacity across the board. It does not state when to prefer this over alternatives such as calc_trace_width or pcb_run_drc, nor are exclusions provided.
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?
There are no annotations, so the description carries the transparency burden. It clearly states the tool is read-only in intent by listing windows and their active status, which covers the core behavioral context. However, it does not clarify what values 'activity status' may take or whether the list may be empty.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One short Chinese sentence conveys the action, resource, and output scope with no filler. This is highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple, zero-parameter listing tool, so the description is close to sufficient. However, there is no output schema, and the description does not state the exact return format or explain how the returned data would be consumed by related tools like pcb_select_eda_window.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no parameter ambiguity. The description correctly communicates the only meaningful thing needed: the tool's scope is all connected EDA windows, not any specific one.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('列出' / list) and a specific resource ('所有已连接嘉立创EDA窗口') with a clear scope ('活动状态' / active status). It clearly distinguishes this tool from siblings like pcb_select_eda_window, which selects a window.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used for inspecting connected EDA windows before interacting with them, but it does not explicitly say when to prefer it or when not to use it. Given the sibling pcb_select_eda_window, a brief 'use this before selecting a window' would improve 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?
No annotations are provided, so the description must convey safety side effects. It mentions 'one-click output' and lists checks, suggesting a read-only report operation, but it does not explicitly state that it makes no modifications to the design. Since there are no annotations, the description carries the full responsibility for behavioral clarity and only implies a non-mutating action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that immediately conveys the core purpose ('one-click design health report'), lists key checks, and ends with the rating scale. It is concise without being vacuously short, packing all essential information into one line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters and no sibling context in the description, it's important to explain what the report includes and how to interpret it. The description does this well, listing the checks and the rating scale. It doesn't mention return format or side effects, but for a report aggregator with no inputs, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameterstons, so there is no parameter semantics to clarify. The description nonetheless adds value by explaining what the output encompasses, which is effectively the 'parameterless' contract. With no params to document, the baseline of 4 is justified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool produces a design health report, explicitly enumerates the checks included (BOM, connectivity, current carrying, DRC, clearance), and specifies the output rating scale (READY/NEEDS_WORK/POOR). This distinguishes it from sibling tools that perform individual checks (e.g., pcb_run_drc, pcb_bom_export), positioning it as an aggregator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a one-click comprehensive health check. It does not explicitly state which sibling tools to use instead of or in addition to this one, but the inclusion of multiple check types in the description implicitly advises using this aggregate tool for a quick overview. It lacks explicit 'use this instead of individual checks' guidance, but the intent is clear.
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 burden. It discloses that a snapshot is saved, implying a persistent side effect, but does not mention whether prior snapshots are overwritten, how many can be stored, or whether the design is modified. For a zero-parameter tool, this is acceptable but not fully 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence states the action and purpose with no filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no annotations, and no output schema, the description provides the essential context: what the tool does and why it matters (baseline for pcb_design_diff). Return behavior is not described, but for a simple snapshot tool this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers everything. The description adds the key semantic context that the snapshot is meant as a baseline for pcb_design_diff, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: save a snapshot of the current design. It also names the downstream consumer (pcb_design_diff), which distinguishes this tool from the many other pcb_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: create a baseline before later comparisons via pcb_design_diff. It does not explicitly state when not to use it or name alternatives, but the baseline purpose is clear enough for an agent.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/hyl64/jlcmcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server