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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic operations and supported modes; it does not disclose output units, formula assumptions, handling of invalid or conflicting parameters, or any limits on accuracy or applicability.

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

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

The description is two short sentences with no filler. The primary operations are front-loaded, and the supported geometry list is compactly appended.

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

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

With no output schema, no annotations, and a 7-parameter calculation tool, the description should clarify expected results, permissible parameter combinations, and constraints. It does none of that, leaving an agent to infer return values and optional-parameter behavior from parameter names alone.

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

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

Schema description coverage is 100%, so the schema already documents every parameter, including the default values and the mutual exclusivity between width and targetImpedance. The description adds only a concise restatement of the dual calculation direction and mode support, which does not meaningfully extend the structured parameter semantics.

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

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

The description clearly states the tool's actions: compute PCB trace impedance or reverse-calculate trace width from a target impedance, and lists supported geometries. However, it does not explicitly distinguish this tool from the sibling calc_trace_width, which likely overlaps in the reverse-calculation use case.

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

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

The description implies when the tool is useful by naming impedance calculation, reverse width calculation, and supported transmission-line types. It does not provide explicit when-to-use versus alternatives guidance, such as when to choose calc_trace_width instead of calc_impedance.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses that this is a calculation following IPC-2221, which implies a deterministic, non-destructive operation. However, it does not mention return format, units of the calculated width, or behavior for invalid inputs, leaving moderate gaps.

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

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

The description is a single focused sentence that states the essential purpose and standard with no filler or redundancy. It is appropriately sized and effectively front-loaded.

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

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

Inputs and defaults are fully documented in the schema, and the purpose is clear. However, with no output schema, the description does not specify the result's units or format, which is a meaningful gap for interpreting the tool's return value in a PCB design context.

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

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

Schema description coverage is 100%, so the parameters are already well-documented with units and defaults. The description adds general formula context but does not enrich any specific parameter beyond what the schema provides, matching the baseline-3 case.

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

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

The description states a specific action ('计算最小走线宽度'), a clear resource ('minimum trace width'), and the governing standard ('IPC-2221'), which makes the tool's purpose immediately identifiable. It is clearly distinguishable from siblings like calc_impedance because it targets trace width based on current-carrying requirements.

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

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

The description provides clear context: use this tool when you need to size a trace for a given current-carrying requirement according to IPC-2221. It does not explicitly name alternatives or exclusions, such as distinguishing from calc_impedance, but the context is clear enough for an agent to select it appropriately.

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

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 says it rearranges all silkscreens but does not warn that this is a bulk mutation, whether it can be undone, or whether it affects existing manual placements.

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

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

A single short sentence with no filler; the core operation is front-loaded and every word adds meaning.

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

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

For a zero-parameter tool with no output schema, the description is minimally adequate: the agent knows what action will be taken. However, because it mutates all silkscreen placements and no annotations cover side effects, a note about reversibility or confirmation would make it more complete.

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

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

The tool takes zero parameters and schema coverage is complete, so there are no parameters to document. The description does not need to add parameter details, and the baseline for a zero-parameter tool applies.

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

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

The description states a specific verb (自动排列/auto-arrange), a resource (所有丝印/all silkscreens), and a goal (避免重叠/avoid overlap). This clearly distinguishes it from the sibling pcb_move_silkscreen, which is a manual per-element move.

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

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

The intended use is implied: use this when you want automatic, board-wide silkscreen arrangement rather than manual movement. However, it never explicitly names alternatives or states when not to use it.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It only restates the operation and does not clarify whether the move is absolute or relative, whether the operation overwrites existing positions, what happens on invalid designators, whether the action is reversible, or what the tool returns.

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

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

The description is a single efficient sentence with no filler, and the key batch/multiple scope is front-loaded. It is concise and well structured, though it sacrifices important contextual detail.

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

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

For a mutating tool with no annotations and no output schema, this one-phrase description is not enough for confident invocation. It omits coordinate units, behavior on partial failure, interaction with current selection, and any return value expectations.

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

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

The schema already provides 100% description coverage for the single parameter, defining the moves array structure with required designator, x, y and optional rotation. The description adds no parameter-specific meaning, so the baseline score of 3 is appropriate.

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

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

The Chinese description '批量移动多个元件' names a specific action (batch move) and resource (multiple components). It distinguishes the tool from single-component move siblings like pcb_move_component by emphasizing 'batch' and 'multiple', though it leaves some ambiguity about whether '元件' means PCB footprints or generic design elements.

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

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

The word '批量' (batch) and '多个' (multiple) imply this tool is for moving several components at once rather than a single component, which is the likely alternative pcb_move_component. However, there is no explicit when-to-use guidance, no exclusion of alternatives, and no mention of constraints like designator existence or selection prerequisites.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action and does not mention side effects, such as creating a new instance on the board, how it interacts with existing components at the same coordinates, whether it requires a pre-opened document, or how failures are surfaced. Important behavioral context is missing.

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

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

The description is a single short sentence that communicates the core purpose immediately. There is no redundancy or filler, and the key action is front-loaded.

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

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

Although the schema is complete, there is no output schema and no annotation coverage. The description does not address potential failure modes, what happens after placement, or the behavioral aspects required to use the tool confidently in an agent loop. More context about the placement operation and its effects would be needed for full completeness.

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

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

Schema description coverage is 100%, so the input schema already documents every parameter, including units for coordinates (mil) and layer codes (1=top, 2=bottom). The description adds only the conceptual link between 'library' and libraryUuid/componentUuid, so it does not need to compensate for missing schema information.

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

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

The description clearly states a specific action: '从库中放置元件到 PCB' (place a component from the library onto the PCB). It names the resource (component), the source (library), and the destination (PCB), and this wording differentiates it from sibling tools like pcb_relocate_component or pcb_move_component, which imply moving existing components rather than placing new ones.

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

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

The description implies the main use case—placing a new component from a library—but gives no explicit guidance about when to choose this tool over alternatives, such as pcb_relocate_component for moving existing components. It also does not mention prerequisites like having a PCB document open or a valid library loaded.

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

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

没有 annotations，描述需承担全部行为披露责任，但它只说“创建”，未提及对已有铺铜区域的影响、层或网络有效性、调用后如何确认结果等。对于写操作而言，行为透明性不足。

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

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

描述只有一句话，信息密度高，主题前置，没有冗余内容。虽然过于简短，但作为工具用途描述而言足够简练且易于快速理解。

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

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

参数 schema 完整且无嵌套对象，复杂度较低；但无 annotations 和 output schema，描述也没有提供调用时机、与兄弟工具的区分或结果返回方式。基本可完成调用，但缺少边界场景和备选工具信息。

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

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

input schema 对所有 6 个参数均有描述，覆盖率 100%，因此描述无需重复参数含义。描述中的“矩形”仅与 x1/y1/x2/y2 的几何意义泛泛对应，未额外增加参数格式、单位或约束信息。

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

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

描述明确使用动词“创建”和目标资源“矩形铺铜区域”，清楚表明该工具用于创建矩形铺铜。虽然没有明确与 pcb_create_keepout 等兄弟工具做区分，但资源类型本身足以初步辨别其用途。

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

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

描述仅陈述功能，未说明何时应选择铺铜而非走线、keepout 或其他创建类工具。没有列出替代工具或排除条件，代理只能从工具名和上下文推断使用时机。

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

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

With no annotations provided, the description bears the full burden of disclosing behavioral traits. It only states that a differential pair is created, omitting any behavior around validation, failure modes, effects on existing objects, or requirements for the positive and negative nets. This is less informative than even minimally acceptable create-operation descriptions.

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

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

The description is extremely short, but this is under-specification rather than effective conciseness. A single restatement of the tool's name lacks the structured, front-loaded detail expected of a helpful tool description.

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

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

For a create tool with three required parameters, no annotations, and no output schema, the description should provide more context about expected input relationships, possible errors, and how the created diff pair behaves. The current description leaves the agent to infer preconditions and postconditions, making it incomplete for confident invocation.

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

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

Schema description coverage is 100%, so the input schema already documents all three parameters ('name', 'posNet', 'negNet') with clear Chinese descriptions. The tool description adds no additional parameter meaning, but the baseline of 3 applies because the schema fully covers parameter semantics.

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

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

The description '创建差分对' simply restates the tool name pcb_create_diff_pair ('create differential pair'), providing no additional specificity beyond the name itself. It does not distinguish the tool from related sibling tools such as pcb_create_equal_length or pcb_delete_diff_pair.

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

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

The description provides no guidance on when to use this tool versus alternatives, such as pcb_list_diff_pairs, pcb_delete_diff_pair, or pcb_create_equal_length. There is no mention of prerequisites like whether the referenced nets must already exist or how this differs from creating equal-length constraints.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that an equal-length group is created, but does not mention side effects, whether existing groups are replaced, validation behavior, or any other operational consequences.

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

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

The description is extremely short and free of filler, but it is under-specified for the decision an agent must make. It is concise without being adequately informative.

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

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

The schema covers parameters, but there are no annotations, no output schema, and no usage or behavioral context. An agent has little information about what actually happens when the equal-length group is created or how this fits with related tools.

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

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

Schema description coverage is 100%, so the input schema already documents both 'name' and 'nets'. The tool description adds no parameter-level meaning beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description '创建等长组' ('Create equal-length group') clearly identifies a specific action and resource. However, it does not explicitly distinguish this tool from related siblings such as pcb_create_diff_pair or pcb_list_equal_lengths.

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

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

The description provides no guidance on when to use this tool versus the many related alternatives. There is no stated context, prerequisite, or exclusion to help an agent choose correctly.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'create rectangular keepout' and does not mention document state requirements, return behavior, side effects on existing keepouts, or whether the operation can fail.

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

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

The description is a single compact phrase with no filler, front-loading the verb and object. It is appropriately concise for a simple tool, though it could carry more useful context without becoming verbose.

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

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

For a 5-parameter tool with no annotations and no output schema, the description is too terse. It omits behavior after creation, coordinate ordering beyond the schema, layer semantics, and expected result, leaving an agent unable to fully anticipate the invocation outcome.

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

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

The schema covers 100% of parameters with descriptions including coordinate roles and units (mil). The description adds only the 'rectangular' shape context, which slightly clarifies that x1/y1 and x2/y2 form opposite corners, but does not significantly expand on the schema.

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

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

The description clearly states the action (create) and the resource (rectangular keepout region). It differentiates itself from pcb_delete_keepout by the create action, though it does not explicitly contrast with any sibling tool.

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

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

No guidance is given about when to use this tool versus alternatives such as pcb_delete_keepout or pcb_create_copper_pour. Usage is only implicit in the verb 'create' and the noun 'keepout.'

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Create via' implies a mutating operation but does not state whether an open document is required, whether the operation is reversible, or what side effects may occur on the board.

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

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

The description is extremely terse and contains no waste, but it is under-specified for a five-parameter mutation tool. Brevity here comes at the cost of missing context that the schema and annotations cannot provide.

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

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

This is a mutating PCB tool with no annotations and no output schema. The description does not mention board state requirements, how the via relates to existing nets or tracks, or what the result of a successful creation is, leaving important context absent.

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

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

Schema description coverage is 100%, with each parameter documented in Chinese (coordinates in mil, net name, drill and outer diameters). The description adds no additional parameter meaning, 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.

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

The description '创建过孔' clearly states a specific verb and resource: create a via. It is unambiguous about the tool's purpose, though it does not explicitly differentiate itself from sibling tools like pcb_delete_via or pcb_create_component.

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

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

There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites such as having a board open or a valid net. The agent must infer usage entirely from the tool name and schema.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a destructive operation but does not mention whether associated tracks, vias, or routing are also removed, whether the deletion is reversible, or what happens when the named differential pair does not exist.

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

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

The description is a single short sentence with no filler. The action and object are immediately visible, and every character contributes meaning.

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

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

For a single-parameter delete operation, the description is minimally usable because the schema already documents the parameter. However, with no annotations and no output schema, it lacks side-effect and failure-mode context, leaving the agent unable to predict the full impact of a destructive call.

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

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

The input schema already documents the only parameter, 'name', with the description '差分对名称'. The tool description adds no additional semantic meaning beyond that, so the baseline score of 3 applies due to high schema coverage.

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

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

The description '删除差分对' clearly states a specific verb ('delete') and resource ('differential pair'), so the core purpose is unambiguous and distinguishable from delete-tracks or delete-via tools. However, it does not explicitly disambiguate from pcb_delete_selected or state that deletion is by name rather than by selection.

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

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

There is no guidance about when to use this tool versus alternatives such as pcb_delete_selected, pcb_delete_equal_length, or pcb_delete_tracks. No prerequisites or conditions are provided; the intended usage is only implied by the tool name and resource type.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It only says 'delete equal-length group' and does not state whether deletion is irreversible, whether related tracks or design rules are affected, or what happens to the group's name after deletion.

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

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

The description is a single efficient sentence with no filler or repetition. It is appropriately concise, though it is arguably too terse because it omits behavioral and contextual details.

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

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

For a destructive tool with no annotations and no output schema, the description is incomplete. It does not clarify what 'equal-length group' means in this PCB context, whether the operation is reversible, or what the result is, leaving the agent without key information for a delete operation.

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

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

The schema describes the only parameter 'name' as 'equal-length group name' with 100% coverage. The description adds no additional meaning about the parameter, so it is correctly at the baseline for fully schema-documented parameters.

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

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

The description states the verb 'delete' and the resource 'equal-length group', so the core operation is clear. It does not explicitly differentiate itself from sibling deletion tools, but the resource name already sets it apart from pcb_delete_tracks, pcb_delete_via, pcb_delete_pour, pcb_delete_keepout, and pcb_delete_diff_pair.

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

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

No guidance is given about when to use this tool versus alternatives such as pcb_delete_selected or how prerequisites like an existing equal-length group should be verified. The description neither provides exclusions nor names alternative tools, so the agent receives no decision support.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It conveys the destructive delete action but says nothing about scope, reversibility, permissions, or what happens to connected design data. This is minimal but not contradictory.

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

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

The description is a single short phrase with no filler or redundant clauses. For a one-parameter delete operation, this is appropriately sized and front-loaded.

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

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

The operation is simple and the parameter is fully documented, so the minimal description is arguably sufficient. However, with no annotations and no output schema, the agent receives no information about side effects, return value, or failure behavior, leaving some gaps.

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

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

Schema description coverage is 100%, so primitiveId is already documented. The description adds no extra meaning or usage detail beyond the schema, matching the baseline for fully documented parameters.

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

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

The description '删除禁布区' states a specific action (delete) and resource (keepout area), making the tool's purpose unambiguous. It does not explicitly differentiate from siblings like pcb_delete_selected or pcb_delete_pour, but the keepout-specific target is clear.

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

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

No usage context is provided: there is no statement about when to delete a keepout by primitiveId versus using pcb_delete_selected or other deletion tools. The intended scenario is only implied by the tool name and parameter schema.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It only says 'delete' without warning that the operation is destructive, irreversible, or what happens to associated copper-pour data; this is a meaningful gap.

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

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

The description is a compact four-character phrase with no filler or redundancy. While minimal, every word contributes to stating the core operation.

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

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

For a one-parameter delete tool the description is minimally sufficient: the agent knows the action and the schema supplies the required input. However, it omits guidance on how to obtain primitiveId, whether the action is undoable, and any side effects, so there are clear gaps.

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

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

Schema coverage is 100%: the only parameter, primitiveId, is described as '铺铜图元 ID' (copper pour primitive ID). The description adds no extra meaning beyond this, 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.

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

The description states a specific action and resource: delete a copper pour ('删除铺铜'), which is distinct from sibling tools like pcb_delete_via or pcb_delete_keepout. It doesn't add detail beyond the tool name, so it is clear but not enriched.

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

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

No guidance is given on when to invoke this tool instead of pcb_delete_selected or other deletion tools, and there are no prerequisites or exclusions. The intended usage must be inferred from the name and the required primitiveId.

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

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

No annotations are present, so the description must carry the full behavioral burden. It only says 'delete currently selected objects' and does not disclose irreversibility, whether a confirmation occurs, what happens when nothing is selected, or the exact scope (though the pcb_ prefix hints at PCB context). This is thin for a destructive mutation.

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

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

A single short sentence, perfectly sized for a zero-parameter tool. No filler, no redundant restatement, and every word contributes to the action and target.

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

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

For a tool with no annotations and no output schema, the one-liner is minimally viable but leaves gaps: no behavior on an empty selection, no undo or destructive warning, and no return/result description. Since the tool is simple and parameterless, these gaps are noticeable but not fatal.

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

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

There are zero parameters and an empty schema, so the baseline is 4. The description identifies the implicit input — the current selection — and needs to describe no parameter syntax. It adds just enough context for a parameterless tool.

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

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

The description states a clear verb ('删除' / delete) and a resource ('当前选中的对象' / currently selected objects). It is more specific than a tautology and implies a generic delete operation on the active selection, which distinguishes it from type-specific delete siblings such as pcb_delete_tracks or pcb_delete_via, though it doesn't explicitly name them.

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

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

No guidance is given about when to use this generic deletion tool versus the many specific delete siblings (tracks, vias, pours, keepouts, diff pairs, equal lengths). The qualifier 'current selected' is the only implicit usage signal; there are no explicit conditions, prerequisites, or exclusions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly indicates a destructive operation, but it does not mention side effects, undoability, what happens to connected nets, invalid-ID handling, or whether only track primitives are accepted. Basic intent is conveyed, but meaningful behavioral context is missing.

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

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

The description is a single short phrase with no filler or redundant detail. It is appropriately sized for a one-parameter destructive operation and every word contributes to stating the operation's purpose.

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

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

For a destructive tool with no annotations and no output schema, the description is too thin. It lacks behavioral caveats, any usage context, and clarification of what the operation does to the broader PCB state. The schema covers the parameter, but the description alone is not enough for an agent to confidently invoke this tool in varied situations.

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

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

Schema description coverage is 100%: the only parameter, primitiveIds, is described as "走线图元 ID 列表" (track primitive ID list). The tool description adds no meaning beyond restating the target resource, so the baseline score of 3 applies; it neither harms nor meaningfully enriches parameter understanding.

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

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

The description "删除走线" (delete tracks) states a specific action and target resource, making it clear that this tool deletes track primitives rather than vias, pours, or other objects. It is not a tautology and is distinguishable from sibling deletion tools like pcb_delete_via and pcb_delete_selected by the resource named, though it does not explicitly contrast those alternatives.

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

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

There is no guidance about when to use this tool versus alternatives such as pcb_delete_selected or pcb_delete_via. No prerequisites, exclusions, or use-case conditions are mentioned, leaving the agent to infer which deletion operation fits a given situation.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only repeats the operation. It does not state whether deletion is irreversible, whether connected routing is affected, or whether permissions are required.

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

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

The description is extremely short and front-loaded, but this is under-specification rather than effective conciseness. It omits meaningful behavioral and usage guidance that an agent needs.

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

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

The single parameter is fully described in the schema, but the description provides no output behavior, scope, or side-effect information. For a destructive deletion tool with no annotations and no output schema, this is incomplete.

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

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

Schema description coverage is 100%, and the schema already defines primitiveIds as a list of via primitive IDs. The description adds no additional parameter semantics, 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.

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

The description '删除过孔' simply restates the tool name pcb_delete_via in Chinese. It conveys the action and object, but adds no differentiation from sibling tools such as pcb_delete_selected or pcb_delete_tracks.

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

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

No guidance is provided on when to use this tool versus alternatives like pcb_delete_selected or pcb_delete_tracks. The only usage hint comes indirectly from the parameter name, so the context is implied rather than stated.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the purpose and gives output examples; it does not disclose whether the tool is read-only, requires an open PCB document, or what error behavior to expect. The 'get' wording implies read-only, but the description does not explicitly confirm this.

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

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

The description is a single, front-loaded sentence with no filler. It communicates the action and two representative output fields in minimal space, and every part contributes to understanding the tool's purpose.

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

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

For a zero-parameter simple getter, the description is acceptable but has gaps: it does not specify that a PCB document must be open, does not list the full return shape, and relies on '等' to cover unlisted outputs. Since there is no output schema and no annotations, these omissions leave some important context to inference.

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

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

The tool has zero parameters and the input schema is empty, so there is no parameter semantics for the description to clarify. The baseline of 4 applies because no parameter information is needed; the description focuses on the output content instead.

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

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

The description states a clear action ('获取工程信息' — get engineering information) and gives concrete examples of the resource scope ('板名、层数等' — board name, layer count, etc.). It is specific enough to distinguish from sibling tools like pcb_get_state, though it does not explicitly name the sibling it differs from.

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

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

The description provides no guidance on when to use this tool versus alternatives. There are many sibling tools with potentially overlapping scopes (e.g., pcb_get_state), but no mention of when this one is preferred or when another should be used instead.

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

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

No annotations are provided, so the description carries the behavioral burden. '查询' signals a read-only query operation, but the description does not disclose return format, side-effect profile, or other behavioral details beyond what the name already implies.

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

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

The description is a single, front-loaded sentence with no filler or redundant information. It conveys the essential purpose efficiently.

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

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

Given the low complexity (zero parameters, no nested objects, no output schema), the description is mostly complete for selecting and invoking the tool. It could be improved by noting the format of the returned feature list, but this is a minor gap.

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

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

The tool has zero parameters, and the schema already fully covers parameter requirements. There is nothing for the description to add, so the baseline score of 4 is appropriate.

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

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

The description states a clear action ('查询' / query) and a specific resource ('bridge 支持的功能列表' / feature list supported by bridge). This distinguishes it from sibling tools like pcb_get_state or pcb_ping, although the term 'bridge' is not explicitly defined.

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

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

Usage is implied: an agent would call this to discover which features the bridge supports. However, there is no explicit when-to-use guidance or mention of alternatives. The implied context is enough for a zero-parameter introspection tool but not explicitly stated.

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

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

There are no annotations, so the description carries the full burden. 'Query' implies a read-only operation, but the description does not disclose the return shape, whether all primitive types are included, or what happens for an unknown or empty net.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes to stating what the tool returns.

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

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

For a single-parameter query this is minimally viable: an agent knows what to supply and what kind of data comes back ('all primitives'). However, there is no output schema or description of the return format, so the agent cannot predict the response structure or error behavior.

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

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

Schema coverage is 100%: the only parameter 'net' is already documented as '网络名称' (net name). The description only restates this by referring to the 'specified net' and adds no format, validation, or default information.

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

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

The description uses a specific verb ('query') and a precise resource ('all primitives of the specified net'), making the operation unambiguous. This distinguishes it from sibling getters like pcb_get_tracks and pcb_get_pads, which filter by primitive type rather than by net.

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

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

No guidance is given on when to choose this tool instead of related retrieval tools such as pcb_get_tracks, pcb_get_pads, or pcb_get_silkscreens. The agent must infer the appropriate context 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.

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

With no annotations provided, the description carries the behavioral burden. '查询' (query) reasonably implies a read-only operation with no side effects, but the description does not disclose return shape, filtering semantics, or any state requirements, leaving some ambiguity.

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

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

The description is extremely concise with no filler words, and the core action is front-loaded. It is efficient, though perhaps too terse to fully compensate for the lack of annotations and output schema.

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

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

For a simple tool with one optional parameter and no output schema, the description names the returned concept (pad information) but does not say whether designator filters results, whether a list or single item is returned, or whether an open document is required. It is minimally adequate but has clear gaps.

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

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

The input schema already describes the only parameter with 100% coverage ('元件位号（可选）'). The description adds no additional meaning beyond the schema, 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.

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

The description states a clear verb-resource pair: 查询 (query) 焊盘信息 (pad information). It is clear about what the tool does, though it does not explicitly distinguish itself from siblings like pcb_get_tracks or pcb_get_net_primitives.

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

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

There is no guidance on when to use this tool versus alternative getters, no mention of the optional designator filtering behavior, and no prerequisites or context for invocation. The agent must 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.

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, but it only says 'query all silkscreen text'. It does not describe what data is returned, whether coordinates or text strings are included, or whether an open board context is required.

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

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

The description is a single short sentence with no filler, stating the action and the target resource directly. It is appropriately sized for a simple parameterless query tool.

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

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

The description is minimally sufficient for a zero-parameter read tool, but it lacks detail about the expected return contents and any operational context such as requiring an open PCB document. Since there is no output schema, a bit more description would make the tool easier to use correctly.

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

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

The input schema has zero parameters, so there are no parameter semantics that the description needs to clarify. The baseline for a zero-parameter tool is 4, and no additional parameter-specific information is required.

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

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

The description states a clear action, '查询' (query), and a clear resource, '所有丝印文字' (all silkscreen text). It is understandable on its own, though it does not explicitly differentiate it from sibling silkscreen-related tools such as pcb_move_silkscreen or 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.

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

There is no guidance about when to use this tool versus related tools, nor any mention of prerequisites such as an open PCB document. An agent must infer usage entirely from the tool name and the brief description.

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

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

No annotations are provided, so the description carries the full burden. It implies a read operation and mentions scope ('complete state'), but it does not disclose return format, potential size/cost, side effects, or how the state is structured.

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

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

One compact sentence with the key information front-loaded and a short parenthetical list of examples. No filler or redundant phrasing.

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

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

For a parameterless getter, the description is minimally viable: it names the resource and gives examples of contents. However, with no output schema and no return-shape details, an agent can only guess at what fields will be present.

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

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

There are zero parameters, so the 0-parameter baseline of 4 applies. The description does not need to explain parameters.

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

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

The description states a specific verb ('获取'/'get'), a clear resource ('PCB 完整状态'/'PCB complete state'), and gives concrete inclusions (components, nets, board outline). This helps distinguish it from sch_get_state and narrower getters such as pcb_get_tracks or pcb_get_pads, though it does not explicitly contrast them.

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

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

There is no guidance on when to call this tool versus sibling getters like pcb_get_board_info, pcb_get_tracks, or pcb_get_pads. The description defines what it returns but not when it should be preferred.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'query' and does not explain whether the tool returns segments, selects them, what properties are included, how filters behave, or whether there are any side effects. The query wording implies a read operation, but this is not explicit enough.

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

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

The description is very short and front-loaded, containing no filler or redundant phrasing. It is concise to the point of being sparse, but as far as structure and economy of language go, it is effective.

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

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

For a read-oriented tool with no annotations and no output schema, the description is too minimal to give an agent a complete picture. It does not describe return format, units, coordinate system, filtering semantics, or what differentiates this tool from other PCB query tools. The agent would need to rely on trial and error.

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

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

Schema description coverage is 100%, with both optional parameters ('net' and 'layer') documented in the schema. The tool description itself adds no parameter-level meaning, but because the schema already explains the parameters, the baseline of 3 is appropriate.

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

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

The description states a clear verb ('查询' / query) and a specific resource ('走线段' / track segments), and the optional filters are suggested by the schema. However, it does not explicitly differentiate this tool from sibling retrieval tools like pcb_get_net_primitives or pcb_get_pads, so it stops short of a perfect score.

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

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

There is no guidance on when to use this tool instead of alternatives such as pcb_get_net_primitives, pcb_get_pads, or pcb_delete_tracks. The description only states what the tool does, without any context, prerequisites, or exclusions.

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

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

With no annotations, the description must carry behavioral weight, and the word 'list' does convey a read-only, non-mutating operation. Still, it does not describe the return format, ordering, or any dependence on board state or open document, so some behavioral aspects are left unspecified.

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

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

The description is one short sentence that front-loads the operation and resource with no filler or redundancy. For a zero-parameter list tool, this is appropriately concise and well-structured.

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

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

For a simple zero-parameter list operation, the description is mostly sufficient, but there is no output schema and the description does not say what the returned differential-pair data contains or how it is structured. This is a minor gap given the tool's simplicity, but it prevents full completeness.

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

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

The input schema has zero parameters and schema description coverage is effectively 100%, so there are no parameter semantics for the description to clarify. Per the baseline for no-parameter tools, the description is adequately silent.

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

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

The description uses a clear verb ('列出' / list) and specifies the exact resource ('所有差分对' / all differential pairs), making the operation unambiguous. However, it does not explicitly contrast with sibling tools such as pcb_create_diff_pair or pcb_list_equal_lengths, so differentiation is implicit rather than stated.

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

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

The phrase 'list all differential pairs' implies the tool should be used when a read-only enumeration of differential pairs is needed. However, it gives no explicit when-to-use or when-not-to-use guidance and does not mention alternatives among the sibling tools.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. '列出' implies a read-only listing, but the description does not explain the return format, scope, or what constitutes an equal-length group. Transparency is minimal.

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

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

The description is a single, direct sentence with no filler or redundancy. It is appropriately sized for a zero-argument list tool.

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

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

For a zero-parameter list operation, this is minimally viable: it names the action and resource. However, with no output schema and no annotations, it does not describe the returned structure or the exact scope of '等长组', leaving some ambiguity.

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

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

There are zero parameters and the schema is empty, so the 0-parameter baseline of 4 applies. No parameter clarification is needed because none exist.

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

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

The description uses a specific verb '列出' (list) and a clear resource '所有等长组' (all equal-length groups), which distinguishes it from sibling create/delete equal-length tools and from pcb_list_diff_pairs. The action and target are unambiguous.

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

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

No guidance is given for when to use this tool versus alternatives. It does not state prerequisites such as an open PCB document, nor does it contrast with pcb_list_diff_pairs or other list operations. Usage context is only implied by the name.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It correctly implies a mutating action ('move') and includes the unit 'mil', but does not disclose whether a document must be open, whether the change is reversible, what happens on an invalid designator, or what the tool returns.

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

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

The description is a single front-loaded sentence with no filler. It states the action, target, and unit efficiently, earning its place despite being minimal.

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

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

This is a minimum-viable description for a simple move operation: the action is clear and the schema covers all parameters. However, with no annotations and no output schema, it lacks details about prerequisites, coordinate system origin, or expected response, leaving meaningful gaps for an agent.

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

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

Schema description coverage is 100%, so the schema already documents designator, x, y, and rotation. The top-level description adds only 'mil' and 'specified coordinates', which adds minimal value beyond the parameter descriptions. 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.

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

The description states a specific action ('move'), a resource ('component'), and a target ('specified coordinates'), so an agent can understand the core function. However, it does not distinguish this tool from the similarly named sibling 'pcb_relocate_component', so it cannot fully clarify which one to choose.

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

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

The description provides no guidance on when to use this tool versus alternatives such as pcb_batch_move, pcb_relocate_component, or pcb_move_silkscreen. It does not mention exclusions, prerequisites, or typical contexts, leaving the agent to 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.

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 merely restates the tool name in Chinese and does not disclose coordinate semantics (absolute vs. relative), whether the move affects only the specified primitive, reversibility, or failure behavior.

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

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

The description is very short and contains no filler, but it is under-specified and essentially duplicates the tool name. It lacks the structure needed to convey any context beyond the basic action and object.

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

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

For a state-changing tool with no annotations and no output schema, this one-line description is insufficient. It omits whether x/y are new absolute positions or deltas, what rotation means in this context, and any error or edge-case behavior, leaving an agent without enough information for confident invocation.

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

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

Schema description coverage is 100%, so the schema already documents primitiveId, x, y, and rotation. The description adds no parameter-level meaning, but the baseline of 3 is appropriate because the schema carries the parameter information.

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

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

The description '移动丝印文字' ('move silkscreen text') states a specific verb and resource, clearly identifying this as the tool that relocates silkscreen text rather than components or tracks. It does not explicitly differentiate from siblings like pcb_move_component or pcb_batch_move, so it falls just short of a 5.

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

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

There is no guidance on when to use this tool versus alternatives such as pcb_batch_move or pcb_auto_silkscreen. The phrase only implies a generic use case and provides no exclusions, prerequisites, or selection criteria.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'switch to' a document and does not disclose whether the document must already be open, whether this changes the active document or opens a file from disk, what happens for an invalid UUID, or whether the operation has any side effects on subsequent commands.

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

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

The description is a single concise sentence with no filler or repetition of the tool name. It is appropriately front-loaded, although the brevity comes at the cost of missing usage context.

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

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

For a simple one-parameter utility, the core invocation is captured: the UUID identifies a document and the action is to switch to it. However, with no annotations and no output schema, operational context such as prerequisites, failure behavior, and how to confirm the active document has changed is absent.

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

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

The schema already describes the only parameter as a document UUID at 100% coverage, so the description does not need to repeat it. It adds marginal semantic value by clarifying that the UUID refers to either a schematic or PCB document, but it provides no extra format or usage details.

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

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

The description states a specific verb and resource: '切换' (switch) to a specified document, and it clarifies that the document can be a schematic or PCB. This is clear enough to identify the operation, though it does not explicitly differentiate itself from sibling tools by naming an alternative.

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

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

The description provides no guidance about when to call this tool versus alternatives, nor does it mention prerequisites such as the document already being open in the session. It does not state that this should be used before PCB/schematic editing commands, even though that is likely the intended pattern.

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

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

No annotations are present, so the description must carry the full behavioral burden. It discloses that the tool performs a status check, but it does not say what response to expect, whether the call is purely read-only, or how failures are signaled. This is a meaningful gap for a tool with no output schema.

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

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

The description is a single front-loaded phrase that names the action and the target with no filler or repetition. It is appropriately sized for a parameterless health-check tool, though it could have added a bit more context.

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

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

For a simple zero-parameter ping tool, the description is nearly sufficient: an agent can identify and invoke it without constructing arguments. However, 'bridge' is left somewhat ambiguous and the expected result/return value is not described, so the description is not fully self-sufficient in the absence of an output schema.

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

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

The tool has zero parameters and 100% schema description coverage, so the schema already exhaustively documents the inputs. The description adds no parameter details, and none are needed; for a zero-parameter tool the baseline score of 4 applies.

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

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

The description uses a specific verb ('检查' / check) and a specific target ('bridge 连接状态' / bridge connection status), so an agent can tell this is a bridge connectivity health check rather than a design-editing operation. It does not explicitly contrast with sibling tools, but none of the siblings cover bridge status, so the purpose is distinct enough.

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

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

Usage is implied: call this tool when you need to verify whether the bridge connection is alive, as 'ping' in the tool name also suggests. There is no explicit guidance on when not to use it or what alternative to prefer, but no sibling appears to be a direct alternative.

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

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

With no annotations, the description carries the behavioral disclosure burden. It does reveal a significant non-obvious side effect: the operation automatically disconnects traces. However, it does not explain what happens to the disconnected tracks, whether the action is reversible, or what 'safe' precisely guarantees.

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

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

The description is a single compact phrase that states the purpose and key behavior without filler. It is efficiently sized, though it sacrifices important usage context for brevity.

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

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

For a four-parameter relocation tool with full schema coverage, the description covers the core purpose and a key side effect. But with no annotations and no output schema, the lack of usage guidance and ambiguous post-move routing behavior leaves notable gaps for an agent deciding whether to invoke it.

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

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

Schema description coverage is 100%, as x, y, rotation, and designator all have individual descriptions. The tool description adds no extra parameter-level meaning, 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.

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

The description states a clear verb and resource: 'safe relocate component' with a key behavioral qualifier 'auto-disconnect traces'. It conveys what the tool does, though it does not explicitly differentiate it from the overlapping sibling tool pcb_move_component.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as pcb_move_component or pcb_batch_move. The phrasing implies use when a safe relocation with automatic trace disconnection is desired, but that is left to inference.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure, but it only says 'draw a track.' It does not explain whether existing tracks are overwritten, whether design rules are checked, whether a document must be open, or what the tool returns after execution.

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

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

At three characters, the description is extremely concise and has no filler, but it is under-specified rather than appropriately sized for a tool with four required parameters. The single phrase lacks useful structure and does not earn its place as a standalone definition.

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

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

With no output schema, no annotations, and a nested points array among four required parameters, an agent needs more context about what happens when the tool runs and how results are reported. The description is incomplete and leaves almost all behavioral context to the schema and tool name.

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

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

Schema description coverage is 100%, and each parameter (net, layer, width, points) has a basic descriptive comment. The description text adds no parameter-specific meaning beyond what the schema already provides, 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.

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

The description '画走线' clearly identifies a drawing/routing operation on a PCB track, so an agent can infer the primary resource and action. However, it does not differentiate this tool from sibling track-related tools such as pcb_create_via or pcb_delete_tracks, though it is not a tautology.

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

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

The description provides no guidance on when to use this tool versus alternatives like pcb_create_via, pcb_create_diff_pair, or pcb_delete_tracks. No prerequisites, exclusions, or contextual selection cues are given.

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

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the operation and does not reveal whether DRC modifies the design, what results are returned, whether it is asynchronous, or any side effects. It is not misleading but is minimal.

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

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

The description is a single, focused sentence that immediately conveys the tool's purpose with no filler or redundant content.

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

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

For a simple no-parameter tool, the description is minimally adequate, but it does not explain the output or return format, and there is no output schema to fill that gap. It also omits potential side effects, though the operation appears to be a check.

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

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

There are zero parameters, and the input schema is empty. The description has no parameter-explanation burden, so the 0-parameter baseline of 4 applies.

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

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

The description, '运行 PCB 设计规则检查 (DRC)', states a specific verb ('run') and resource ('PCB design rule check'), expanding the acronym. The explicit 'PCB' clearly distinguishes it from the sibling sch_run_drc and other PCB operations.

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

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

Usage is implied by the 'PCB' prefix and the DRC operation, but the description gives no explicit when-to-use guidance, prerequisites, or mention of the schematic alternative sch_run_drc. There are no exclusions or contrasting sibling references.

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

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

No annotations are provided, so the description bears the full burden of behavioral disclosure. It states the action but does not disclose what the tool returns (e.g., image path, base64 data, or rendered artifact), whether it opens a UI, or whether any state is affected. This is a meaningful gap for a tool whose output is not schema-defined.

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

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

The description is a single, front-loaded sentence with no filler or redundant phrasing. For a parameterless tool, this level of brevity is appropriate and every word contributes meaning.

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

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

Given the tool has no parameters and no output schema, the description is nearly sufficient for selecting and invoking it. However, it does not explain the result format or side effects, which are important for an agent that must consume the screenshot afterward. The missing output semantics keep it from being fully complete.

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

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

The tool has zero parameters and the schema fully documents this with an empty properties object. There is no parameter ambiguity for an agent to resolve, and the description adds the only relevant semantic information: the operation targets the current PCB editor.

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

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

The description uses a specific verb ('截取', capture) and a clear resource ('当前 PCB 编辑器截图', current PCB editor screenshot). It clearly identifies the tool's function and is distinct from all sibling tools, which perform editing, routing, or inspection operations rather than screen capture.

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

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

The description provides no guidance on when to use this tool, what situation it is designed for, or how it relates to alternatives. There is no implied context beyond the literal action, so an agent receives no help in deciding between this and other PCB tools.

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

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

With no annotations provided, the description carries the full burden of explaining behavior. 'Select a component in the editor' reveals the action but not side effects such as clearing previous selection, focusing/zooming the view, whether an open document is required, or what happens if the designator is not found. These are significant unknowns for a UI-state-mutating operation.

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

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

The description is a single, front-loaded sentence with no filler. It directly states the action and resource, and it is appropriately sized for a simple one-parameter tool. Every word earns its place.

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

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

The combination of description and schema is minimally sufficient to invoke the tool with a designator, but missing behavioral context leaves gaps: no return value indication, no statement about side effects, and no mention of prerequisites like an open PCB document. This is adequate but not complete, especially given that no annotations or output schema exist to fill those gaps.

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

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

Schema description coverage is 100%, so the designator parameter is already documented as '元件位号' (component designator). The description adds little about the parameter beyond implying that the selected entity is a component, but per the rubric the baseline of 3 applies when the schema fully covers parameter semantics.

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

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

The description clearly states a specific action ('select') and resource ('component in the editor'). It is not a tautology and is understandable, but it does not explicitly mention selecting by designator or differentiate itself from sibling tools, though the verb 'select' helps separate it from move/create/delete operations.

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

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

No guidance is provided for when to use this tool versus alternatives. It does not mention preconditions, exclusions, or scenarios where another sibling tool such as pcb_move_component or pcb_create_component would be more appropriate. The only implied usage is 'when you want to select', which is tautological.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It explicitly states that every component, wire, net label, and junction in the current schematic will be cleared, making the destructive scope unambiguous. It stops short of 5 because it does not mention whether the operation is undoable or whether any confirmation is required.

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

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

The description is a single sentence with a clarifying parenthetical. The verb and resource are front-loaded, the object types are enumerated compactly, and every word earns its place.

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

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

For a zero-parameter destructive operation with no output schema and no annotations, the description covers the essentials: what gets cleared, in which document, and in what workflow ('重绘前清理'). It could add an explicit caution about irreversibility, but nothing needed to invoke the tool correctly is missing.

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

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

The tool has zero parameters and the schema is empty, so the baseline is 4. The description correctly focuses on scope rather than parameters, since there is nothing to document for invocation.

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

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

The description uses a specific verb ('清空', clear) and names the exact resource ('当前原理图', current schematic), then enumerates all affected object types: components, wires, net labels, and junctions. This clearly distinguishes it from sibling tools like sch_create_wire or pcb_delete_selected, which operate on different canvases or perform opposite operations.

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

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

The parenthetical '重绘前清理' explicitly frames the intended use case: clean the schematic before redrawing. This gives clear context, though it does not name alternatives or state when not to use the tool.

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

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

With no annotations, the description carries the burden of behavioral disclosure, and it does disclose non-obvious behavior: it tries JLCMCP native creation first and falls back to delegating to easyeda-agent on failure, and lcsc/query identity resolution is delegated externally. It omits details like return/error behavior, but it meaningfully reveals the tool's execution strategy.

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

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

Two dense sentences: the first states purpose, the second states both input strategies and the fallback behavior. No filler or repeated schema information; all sentences earn their place.

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

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

For a 9-parameter creation tool with no annotations and no output schema, the description covers the main decision an agent must make: how to specify the component and what execution path to expect. It leaves minor gaps such as coordinate-system assumptions and exact failure semantics, but it is sufficiently complete for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3, and the description adds value by relating parameters: libraryUuid+uuid are one identity path while lcsc/query are the alternative auto-resolved path. This cross-parameter relationship is not evident from the individual property descriptions.

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

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

The description opens with '在原理图放置元件' — a specific verb (place) plus resource (schematic component) — and clearly distinguishes this from the pcb_* placement siblings. It also names the two accepted identity routes, making the tool's role unambiguous.

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

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

It gives concrete guidance: pass libraryUuid+uuid for direct identity, or lcsc/query for auto-resolution via easyeda-agent, and states the native-first-then-delegate fallback. It does not explicitly list when-not-to-use or name a schematic-specific alternative, but the routing guidance is clear enough for selection.

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

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 states the placement action and does not disclose coordinate units, behavior if a junction already exists, whether a wire must be present, or what the outcome is. This leaves important behavioral context undocumented.

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

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

The description is a single short sentence containing no redundant words or filler. It is appropriately concise for a simple two-parameter creation tool.

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

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

The tool is simple with only two required coordinates and no output schema, so the description does not need to be lengthy. However, it omits coordinate units and any validity conditions for placing a junction, which would help an agent invoke it correctly. The description is minimally adequate but leaves a few contextual gaps.

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

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

Schema description coverage is 100%: both x and y have 'X 坐标' and 'Y 坐标' descriptions. The tool description itself adds no parameter meaning beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description states a specific verb and resource: '在原理图放置连接点（junction）' — 'place a junction in the schematic'. This clearly distinguishes it from sibling tools like sch_create_component, sch_create_wire, and sch_create_netlabel by naming the exact object being created.

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

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

There is no guidance about when to use this tool versus alternatives. It does not mention conditions, prerequisites, or name related tools like sch_create_wire or sch_create_netlabel. The usage context is only implied by the action itself, not explained.

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

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It mentions that the label binds to a wire, but it does not disclose whether the wire must already exist, what happens if placement coordinates are invalid, whether orientation has a default, or any side effects of the operation.

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

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

The description is a single, focused sentence that front-loads the core operation and includes a useful parenthetical about wire binding. 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.

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

For a creation tool with no annotations and no output schema, the description is too thin. It does not cover prerequisites (wire existence), behavior when the wire is absent, orientation default, or what the tool returns. An agent would need additional information to invoke it reliably in ambiguous situations.

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

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

The schema already describes all parameters at 100% coverage, giving a baseline of 3. The description adds meaningful context by clarifying that the label is bound to a wire, which implies that the x/y coordinates must correspond to wire positions. This goes beyond the schema's minimal 'X 坐标' / 'Y 坐标' descriptions.

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

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

The description states the specific action ('放置网络标号' – place a net label) and its required context ('绑定到导线上' – bound to a wire). It clearly identifies the resource as a schematic net label, which distinguishes it from sibling tools like sch_create_component, sch_create_wire, and sch_create_junction.

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

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

The description implies when to use this tool: when a net label needs to be placed on a wire in the schematic. However, it does not explicitly state when not to use it or mention alternatives, so the guidance is only 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.

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

With no annotations, the description carries the full behavioral disclosure burden. It does state the drawing action and the key constraint that the wire is orthogonal, plus the point-string format. However, it does not disclose side effects, coordinate-system assumptions, or behavior on invalid input.

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

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

The description is one efficient sentence that front-loads the operation and domain, then gives the essential point-string format. There is no filler, and every part contributes to correctly invoking the tool.

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

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

For a simple 3-parameter tool with no output schema, the core call details are present: action, domain, point format, and schema-defined defaults. Still, the lack of usage alternatives and behavioral side-effect disclosure leaves the description merely adequate rather than complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful format clarity by explaining that points is a space-separated 'x1 y1 x2 y2 ...' string, which goes beyond the schema's single example and helps the agent construct valid input.

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

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

The description uses a specific verb and resource: 绘制正交导线 (draw an orthogonal wire) scoped to 原理图 (schematic). This clearly distinguishes it from PCB-oriented tools like pcb_route_track and from other schematic creation tools such as sch_create_component.

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

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

The description gives no explicit when-to-use or when-not-to-use guidance. The domain qualifier 'in schematic' implies it is for schematic wiring rather than PCB routing, but the agent must infer the selection criteria instead of being told directly.

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

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

With no annotations, the description carries the full burden for behavioral disclosure, but it only says 'export netlist.' It does not state whether the tool returns the netlist content, writes a file, has side effects, or requires an open schematic, leaving important behavior undocumented.

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

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

The description has no filler and is front-loaded, but it is a single terse phrase with no elaboration. It is under-specified rather than appropriately concise, similar to a placeholder-level description.

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

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

For a tool with no annotations, no output schema, and an optional format parameter, the description leaves critical context missing: valid values for 'type', default behavior, return format, and whether any schematic state is required. An agent would have to guess or call the tool blindly.

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

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

The input schema's description of 'type' as '网表格式' (netlist format) gives basic meaning to the only parameter, and schema coverage is 100%, so the baseline is 3. The tool description adds no extra parameter guidance, such as accepted format values or what happens when the optional parameter is omitted.

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

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

The description states a specific action and object: '导出网表' (export netlist), which clearly identifies the tool's function. It does not explicitly distinguish itself from sibling tools, but no sibling performs netlist export, so the purpose is unambiguous.

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

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

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of whether it should be run after schematic editing or before PCB layout. The agent must infer usage entirely from the tool name and terse description.

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

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

With no annotations, the description carries the behavioral burden. It does convey that this is a read-only operation through '读取', but it does not disclose what the returned state actually contains, whether an open schematic is required, or any error behaviors.

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

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

The description is extremely short and front-loaded, but the brevity borders on under-specification because '状态' is ambiguous. For a zero-parameter tool, this level of concision is acceptable, though not exemplary.

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

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

Even with no parameters, the lack of an output schema and the vague term 'state' leave the agent without a clear expectation of the return value or how this tool fits into a broader workflow. A brief sentence naming the state fields or return type would make it complete.

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

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

The input schema has zero parameters, so the 0-parameter baseline of 4 applies. There is no parameter meaning for the description to add.

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

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

The description uses a clear verb ('读取' / read) and identifies the resource as '原理图状态' (schematic state), which distinguishes it from PCB-state and netlist tools. However, 'state' remains somewhat broad and the description largely restates the tool name.

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

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

No guidance is provided on when to use this tool versus alternatives such as pcb_get_state or sch_get_netlist. There are no conditions, exclusions, or workflow hints.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'run schematic DRC' and provides no insight into whether the operation is read-only, what checks are performed, how results are returned, or how strict mode affects behavior. This is a significant transparency gap for a tool with no annotation support.

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

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

The description is a single compact phrase with no filler or repetition. It front-loads the core action, though its brevity leaves behavioral details to other dimensions; that is a completeness issue, not a conciseness flaw.

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

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

For a simple one-parameter tool, the description is minimally viable: an agent can infer the operation and see the strict parameter in the schema. However, with no output schema and no annotations, it lacks any indication of return format, side effects, or what strict mode actually changes, leaving useful context missing.

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

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

The schema already documents the only parameter strict with the description '是否严格模式' (whether strict mode). The tool description adds no additional parameter-level meaning, but since schema description coverage is 100%, the baseline of 3 is appropriate.

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

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

The description states a specific action ('运行原理图 DRC' = run schematic DRC) on a clear resource, and the 'schematic' qualifier distinguishes it from the sibling pcb_run_drc. The name is expanded into an unambiguous, human-readable operation.

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

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

The description implies usage: run DRC against a schematic rather than a PCB, especially given the sibling pcb_run_drc. However, it does not explicitly state when to choose this tool over alternatives or mention any prerequisites such as having an open schematic document.

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