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

With no annotations, the description carries the full behavioral burden. 'Save it to disk' usefully signals a filesystem write, but it omits where files land, whether existing files are overwritten, required auth/scopes, and any rate limits.

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 front-loaded sentence with zero padding; every clause (verb, formats, destination) carries information.

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 that writes files, with no output schema, no annotations, and one fully undocumented parameter (outPath), the description leaves the destination path semantics and overwrite behavior unaddressed. Too thin for the tool's complexity.

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 50% (nodeId and scale are documented, format is self-describing via enum), so a 3 is the baseline. The description only echoes the format enum and adds nothing about outPath, which is undocumented in both the schema and the description.

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 (render), resource (node), output formats, and the side effect (save to disk). It is clearly distinguishable from siblings like figma_export_json and figma_export_image_fills, though it never names them explicitly.

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 choose this over figma_export_json or figma_export_image_fills, nor any stated prerequisites. Usage is only implied by the format list.

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 are absent, so the description carries the full behavioral burden. It does disclose that original bytes are preserved and files are named by imageHash, which is useful, but says nothing about where files land when outDir is omitted, overwrite behavior, required auth, or rate/size limits.

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 tight sentence with the resource and the output convention front-loaded and no filler. It is efficient, though slightly under-specified for a tool that writes files to disk.

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 annotations, no output schema, and half the parameters undocumented, the definition leaves key facts missing: the destination directory behavior and what the call returns on success or when no image fills exist. For a disk-writing export tool this is a notable 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?

Schema coverage is 50%: nodeId is documented in the schema, but outDir has no description anywhere. The description adds no parameter-level detail (no default directory, no path format), so it fails to compensate for the undocumented parameter.

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 (Save) and a precisely scoped resource: raster images used as IMAGE fills inside a given node. The parenthetical '(original bytes, named by imageHash)' further pins down what gets written, which implicitly separates it from the sibling figma_export_image, though it never names that sibling explicitly.

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 when-to-use guidance, no alternatives, no prerequisites. An agent cannot tell from the text when this should be preferred over figma_export_image or figma_export_json, nor what happens if a node contains no IMAGE fills.

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 but only partly meets it: it does disclose the disk-write side effect and that a path plus summary come back, and it explains the 'auto' fallback behavior. It omits what happens on an existing file (overwrite/error), permission requirements, and any size or rate limits on large node exports.

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 tight sentences with the action and return value front-loaded, followed by the format semantics. No filler, though the format clause could be split for scannability.

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?

Absent an output schema, the description correctly states the return shape (path plus short summary) and the file-writing destination. It is nearly complete for a 3-parameter exporter; only failure/overwrite semantics and any export size constraints are unaddressed.

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 'rest', 'compact', and 'auto' enum values carry no schema descriptions, and the description supplies their meaning precisely (JSON_REST_V1 vs trimmed tree with resolved names vs rest-with-fallback). nodeId and outPath are already documented in the schema at 67% coverage, so the added value is concentrated on the enum.

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+resource (export full JSON of a node) plus the output side effect (writes to disk, returns path and summary). It is distinguishable from figma_export_image by the JSON payload, though it never contrasts itself with figma_get_tree, the closest sibling for reading node structure.

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 prefer this over figma_get_tree (in-memory tree) or the image exporters, nor any note on prerequisites such as file scope or node validity. Usage must be inferred purely from the tool name.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the shallow/lightweight nature of the response and the depth-bounded traversal, which helps distinguish it from full export tools, but it says nothing about error behavior, large-tree cost, or what happens when nodeId is omitted beyond the implicit 'current page'.

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 short clauses, front-loaded with the operation and its output shape, followed by the use case. 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 simple read tool with no annotations and no output schema, the description covers the return fields, the depth-bounded traversal, and the optional node target. Only minor gaps remain (default depth behavior, error cases), which is adequate for this complexity.

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 50%: nodeId is documented in the schema while depth is undescribed there. The description partially compensates by explaining that depth bounds the outline and that the target can be a node or the current page, but it doesn't state the default (3) or maximum (10) 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?

States a specific operation and its return shape: an outline of a node or the current page containing id, name, type, and box. This clearly separates it from heavyweight siblings like figma_export_json, though it doesn't name those siblings explicitly.

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?

"Use to find node ids" gives a clear motivation, which is more than nothing, but there is no when-not guidance, no mention of the alternative export tools, and no prerequisites (e.g. whether a page or node must be selected first).

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 disclosure burden, and it says nothing about whether this is a safe read, what the returned page objects contain, their ordering, or whether pagination applies. 'List' implies read-only but that is an inference, not a disclosure.

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 that front-loads the action and resource with zero filler. Nothing in it is redundant or padding.

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 read tool with no output schema and no annotations, the description is minimally viable but thin. An agent can invoke it correctly, yet gains no information about the return shape or how results relate to other Figma listing 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?

The tool takes zero parameters, so there is nothing for the description to clarify and the baseline of 4 applies. The description's reference to 'the file open in Figma' does usefully clarify the implicit input (the active file) that the empty schema leaves unstated.

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 and resource ('List pages') and scopes it to 'the file open in Figma,' which is concrete. It does not, however, contrast itself with siblings like figma_get_tree or figma_export_json, so an agent must infer the boundary between listing pages and getting the node tree.

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 when-to-use guidance, no prerequisites, and no named alternative among the six sibling tools. The only usage signal is the implicit scoping to the currently open file, which is inferred rather than stated as a condition.

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 and does much of it: it discloses that the tool can read AND modify the open file (mutation), that top-level await is supported, that `return` supplies the result, and that large results are written to a file. It stops short of stating permission requirements, timeouts, or reversibility of file modifications.

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?

Three short, dense sentences with the core action front-loaded and zero filler; each clause conveys distinct information (API surface, language semantics, mutation scope, output handling).

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 tool with no output schema, the description covers the important gaps: what runs, what scope exists, mutation capability, and where large output goes. Error behavior and any execution limits are unaddressed but are not essential to invoking it 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?

Schema coverage is 100% for the single `code` parameter, so baseline is 3; the description adds genuine meaning by explaining the code is an async function body with `figma` in scope and that `return` is the result mechanism, which shapes how the agent should author the parameter.

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+resource: run arbitrary JavaScript against the `figma` Plugin API global. This is clearly distinct in kind from the read-oriented siblings (figma_get_tree, figma_export_json), though the description never explicitly contrasts itself with 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?

Usage is only implied: 'run arbitrary JavaScript' suggests a general-purpose escape hatch for operations the structured siblings do not cover, but the description never states when to prefer this over figma_get_tree or figma_export_json, nor any precondition.

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. It implies a read-only status check and discloses what is returned, which is useful, but says nothing about failure behavior (what is returned or thrown when the plugin is disconnected) or any timeout/permission characteristics.

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 front-loaded sentence with no wasted words, moving from action to returned state in one pass.

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?

There is no output schema, and the description compensates by enumerating the return fields (file name/key, page, selection), which is sufficient for an agent to use the result. The only gap is unstated behavior on a disconnected plugin.

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, so there is no parameter meaning to convey; the baseline for a no-param tool is 4. The description correctly does not invent parameter 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 gives a specific verb ("Check") and resource ("plugin connection") and even enumerates the returned state (file name/key, current page, selection), so the agent knows exactly what this tool is for. It does not explicitly position itself against siblings like figma_list_pages or figma_get_tree, keeping it 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?

The purpose strongly implies usage (verify the plugin is connected before running other figma tools), but no explicit when-to-use or when-not-to-use guidance is stated. It is adequate but leaves the agent to infer the trigger condition.

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