figma_screenshot

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 discloses that scale is configurable (not hardcoded) and references a gap analysis, which adds context about behavior depth. However, it does not clarify if the export is synchronous, what happens on failure, or any rate limits. A score of 3 is appropriate as it adds some value beyond the schema but leaves notable gaps for a tool with zero 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?

The description is a single, focused sentence that front-loads the core action and key differentiator (configurable scale). Every word earns its place, and the parenthetical reference to a gap analysis provides additional context without bloating. No waste.

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 3 parameters, 0 required, no output schema, and no annotations, the description is relatively lean. It covers the essential export purpose and a key differentiator, but does not explain what the output looks like (e.g., does it return a URL or raw data?), nor does it address the `nodeId` parameter or any prerequisites. Given the absence of output schema and annotations, there is room for more 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 0%, so the description must compensate fully. It mentions scale and format (scale is configurable, format implied by 'PNG or SVG'), but does not explain the meaning or constraints of `nodeId`, nor does it clarify that `scale` has a maximum of 4 (as per schema) or that `format` has an enum. The description adds minimal semantic value beyond what the schema already defines via type/enum, and for a 0% coverage tool this is insufficient.

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 ('Export') and resource ('a node'), and explicitly mentions the output formats (PNG, SVG) and the configurable scale. It effectively distinguishes from a sibling tool by referencing 'Plumb's bulk-export path', clarifying that this tool offers dynamic scaling unlike that 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 clear context on when to use this tool (to export a node with adjustable scale) and explicitly contrasts it with another tool (Plumb's bulk-export path) to guide selection. It does not, however, specify when not to use it or list any prerequisites (e.g., required design access).

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