Set opacity

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

Annotations already establish the safety profile (idempotent, non-destructive, not read-only), so the bar is lower. The description adds genuinely useful behavior beyond that: per-item result shape and the partial-failure contract ('one node failing does not fail the call'), plus editor support caveats. It stops short of noting how locked/invisible or cross-page nodes behave.

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 sentences, zero filler, front-loaded with the core action and range then the return/failure semantics. Every clause (range, partial failure, editor support) 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?

With no output schema declared, the description usefully specifies the return shape and partial-failure semantics, and flags editor support limits. For a batch mutation tool it is nearly complete; the remaining gap is behavior on locked, invisible, or unmounted nodes.

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 50%: session and idempotencyKey are well documented in the schema, but the two required parameters nodeIds and opacity carry no schema descriptions. The description restates the 0–1 range, which the schema already enforces via min/max, and adds nothing about nodeIds (e.g., 1–500 items, batch semantics). Baseline 3 for mid 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?

States a specific verb (set) and resource/property (opacity) with the valid range, so the agent knows exactly what mutation occurs. It does not, however, explicitly contrast itself with adjacent property-setting siblings like figma_set_visible, figma_set_blend_mode, or figma_set_effects, leaving the agent to infer the distinction from the property name alone.

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 it on node IDs to change opacity), and the 'Editors: Design; unverified: FigJam, Slides' note gives useful applicability context. But there is no explicit when-to-use vs. alternative guidance, no prerequisite/permission note, and no statement about 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.