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 the tool aggregates data (read operation) and mentions 'bounded structure', hinting at output limiting. However, it doesn't cover permissions, error handling, rate limits, or performance implications, leaving behavioral transparency incomplete.

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, front-loaded with the core purpose, followed by a compact list of included content. Every phrase adds necessary information with 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?

The description gives a clear overall purpose but lacks details on return structure, parameter behavior, or caveats. Given the absence of an output schema and six parameters, the description is adequate but not thorough, leaving an agent to infer important usage details.

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?

Only nodeId has a schema description (17% coverage). The description hints at depth/maxNodes/maxChildren via 'bounded structure' and includeScreenshot via 'optional screenshot', but does not define scale or clarify the relationship between depth and maxChildren. This partial compensation is insufficient given the low 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 the tool builds an implementation-ready context pack from a selection or node, listing specific content types (tokens, components, variables, styles, assets, screenshot). This distinctly differentiates it from sibling get_* tools that each return a narrower slice.

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 specifies it is for generating a comprehensive context pack, implying when to use this over simpler getters. It provides clear context but does not explicitly name alternatives or provide when-not-to-use guidance, though the 'implementation-ready' framing is informative.

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 must disclose behavior. It indicates a read operation ('Read'), implying non-destructiveness, and notes the dependency on the current file in Figma Desktop. However, it does not describe failure modes (e.g., no file open) or what metadata specifically is returned.

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 that is front-loaded with the action 'Read metadata' and includes the essential context. There is no wasted wording.

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, no-output-schema, read-only tool, the description gives the essential purpose and context. It is vague about what 'metadata' encompasses, but given the low complexity and sibling tools covering specific aspects, it is reasonably 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, so there is no parameter information needed. The description adds contextual meaning about the implicit input (the current file), but since the schema is empty, the description is sufficient and the 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 uses a specific verb ('Read') and identifies the resource ('metadata for the Figma file currently open in Figma Desktop'), which clearly differentiates it from sibling tools focusing on page structure, selection, nodes, or screenshots.

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 tool is for retrieving metadata about the current file but provides no explicit guidance on when to use it over alternatives or when not to use it. The context of 'currently open in Figma Desktop' gives some situational clarity, but sibling comparisons are absent.

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?

Without any annotations, the description carries the burden of disclosing behavioral traits. It clearly indicates a read operation ('Read') and hints at limits via 'bounded child tree', but it does not explain what the bounds are, how limits are enforced, or any error behavior. This is minimal but not misleading.

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 that front-loads the core action and resource. Every word earns its place, with no redundant or extraneous 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 with four parameters and no output schema or annotations, the description is too brief to be fully complete. It explains the basic purpose and that the tree is bounded, but it omits how the bounds are controlled and what the tool returns in specific scenarios.

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 only 25% (only nodeId is described). The description adds only a general notion of 'bounded child tree', which relates to the depth, maxNodes, and maxChildren parameters, but it does not explain their individual meanings or defaults. This is insufficient compensation for the low 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 uses the specific verb 'Read' and clearly identifies the resource as 'one Figma node by ID', which distinguishes it from sibling tools that work with selections or whole files. The phrase 'including its bounded child tree' further specifies the scope of the 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 gives no explicit guidance on when to use this tool versus alternatives. It only states what it does, without mentioning that it should be used when a specific node ID is known, nor does it reference any sibling tools 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 provided, the description carries the full burden for behavioral disclosure. It only states that the operation is a read and that it defaults to the current page. It does not disclose behavior regarding depth limits, node limits, or the structure/shape of the returned data.

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, only two short sentences, and the primary verb/resource is front-loaded. Every word earns its place, though the conciseness comes at the expense of necessary 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?

Given the absence of an output schema and annotations, the description should explain more about expected return values and parameter effects, but it does not. Although the default current-page behavior is mentioned, the tool is not complete enough for an agent to understand the full impact of the other parameters or interpret the result.

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 only 25% (only pageId has a description), but the tool description adds no additional meaning for depth, maxNodes, or maxChildren. It merely reinforces the pageId default, leaving the other three parameters without useful clarification.

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 ('Read') and the resource ('top-level nodes on a Figma page'), making it specific and distinguishable from sibling tools like figma_get_node or figma_get_selection. The addition 'Defaults to the current page' further clarifies scope.

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 use this tool versus alternatives such as figma_get_selection or figma_get_node. The only contextual hint is that it defaults to the current page, but there is no explicit when-to-use or when-not-to-use advice.

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 the behavioral disclosure burden. It states the tool exports a PNG image, but doesn't mention behavior with no selection/nodeId, scale constraints, or potential errors. It adds minimal context beyond the 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 concise sentence that front-loads the primary action and object, with no redundant wording or filler.

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 two optional parameters and no output schema. The description covers the main purpose and nodeId semantics. It could improve by mentioning what happens if neither selection nor nodeId is available, but overall it's adequate for its 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 description coverage is 50% (nodeId is described, scale is not). The description clarifies that nodeId defaults to the current selection ('current selection or a Figma node'), adding meaning to that parameter. However, scale is not mentioned or explained.

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 ('Export') and clearly identifies the resource ('the current selection or a Figma node as a PNG image'). It distinguishes itself from sibling get-style tools by focusing on image export rather than data retrieval.

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 'for visual comparison' implies a use case, but there is no explicit guidance on when to use this tool versus alternatives or when not to use it. Sibling tools are all read-only getters, making this the clear export option, but the description doesn't emphasize that distinction.

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 does indicate 'Read', implying a non-mutating operation, and lists some output content, but it does not disclose important behavioral traits such as what happens with an empty selection, the meaning of 'bounded child tree', or performance implications. The description is too sparse for full behavioral transparency.

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 that front-loads the core function ('Read the current Figma selection') and includes no redundant or unrelated information. It earns every word.

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 and no annotations, the description needs to be more self-sufficient. It states the basic action and some output categories but does not explain the result format, how the parameters shape the output, or edge cases. For a simple tool this is still a significant 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 description coverage is 0%, so parameters (depth, maxNodes, maxChildren) are only known by name and constraints. The description's phrase 'bounded child tree' hints that parameters control limits, but it does not explain each parameter's meaning or effect. The compensation is minimal and leaves the agent to guess from names and defaults.

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 the specific verb 'Read' and names the resource 'current Figma selection', while listing key output categories (layout, text, fills, bounded child tree). This clearly distinguishes it from sibling tools like figma_get_node (specific node) and figma_get_screenshot (image).

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 context is clear: it reads the current selection. However, there is no explicit guidance on when to use this tool versus alternatives, no exclusions, and no mention of when not to use it. The usage is implied by the name and description, 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. The verbs 'check' and 'report' imply a read-only, non-mutating operation, but the description does not disclose potential failure modes (e.g., what happens if the plugin is not connected) or any side effects. It adds minimal context beyond what the verbs convey.

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 that states the tool's purpose without any extraneous words. It earns its place completely.

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 status check with no parameters and no output schema, the description covers the core purpose and main outputs. It omits details about the reporting format or connection semantics, but the tool's simplicity makes this acceptable.

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?

With zero parameters, the schema fully defines the input structure. The description adds no parameter details, but none are needed. The baseline for zero parameters is 4, and the description does not detract from this.

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 specific verbs 'check' and 'report' with clear targets: the local Figma Desktop plugin connection and the active file/page. This clearly distinguishes it from sibling tools that fetch metadata, page structure, selection, nodes, design context, or screenshots.

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 tool is for status checks but provides no explicit guidance on when to use it over siblings or when not to use it. It does not mention alternatives or exclusions, leaving the agent to infer usage from the sibling list.

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