Adjust the transparency of inactive PCB layers to reduce visual clutter and focus on the active layer during editing.
pcb_Layer.setInactiveLayerTransparency(transparency: number) -> Promise 设置非激活层透明度 returns: 操作是否成功
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | 按官方签名顺序排列的JSON参数数组 | |
| windowId | No | 目标EDA窗口ID；省略时使用当前活动窗口 |
Changes observed during successful MCP inspections.
v2.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return type (Promise<boolean>) and that it's a setter operation, but doesn't state side effects, whether it persists, or what the boolean indicates beyond '操作是否成功'. It doesn't mention if it requires a specific window or document context.
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 compact: a signature line, a one-line Chinese purpose, and a return note. It front-loads the API signature and purpose. Minor redundancy between the signature and the Chinese description, but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a setter tool with no annotations and no output schema, the description is thin. It doesn't explain the transparency value range, whether it applies to the current document, or how it relates to display mode. An agent would need to guess the parameter semantics and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the args array and windowId, but the actual transparency parameter is inside an untyped array with no description. The description mentions 'transparency: number' in the signature, which adds some meaning, but doesn't specify valid range (e.g., 0-100 or 0-1) or units. Baseline 3 is appropriate since the schema covers the wrapper structure but the core parameter is underdocumented.
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: 'setInactiveLayerTransparency' with a transparency number parameter, and the Chinese text '设置非激活层透明度' clarifies it sets the transparency of inactive layers. It is distinguishable from sibling layer tools like set_layer_visible/invisible or set_inactive_layer_display_mode, 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 on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., active PCB document), valid transparency range, or that it affects only inactive layers. The context of layer display settings is implied by the name but not explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.