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

The description discloses concrete side effects: it writes files to a directory, creates the directory if missing, resolves relative paths against the process working directory, reports missing images, and explains refreshIgnored behavior. This goes well beyond the annotations and is consistent with readOnlyHint=false, since the tool writes to the local filesystem.

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 dense but well-structured, front-loading the core action and then detailing output, missing-image behavior, and file resolution semantics. Every sentence adds value, though the file semantics could be slightly tighter without losing important 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?

With no output schema, the description compensates by specifying the exact array shape, per-image fields, missing-image reporting, and layer usage information. It also covers file source resolution, refresh behavior, and directory creation, giving an agent nearly everything needed to call the tool 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?

The description adds substantial semantics beyond the schema for file (path/key/URL forms and node-id in URL), out_dir (creation and relative path resolution), and refresh (ignored for local .fig files). However, node_id itself is only indirectly mentioned and its expected format is not fully specified, leaving a small gap.

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: "Write the original image assets ... to a directory" for a node or the whole file. It clarifies the domain (image fills and stroke paints) and describes the return format, making it easily distinguishable from sibling tools like figma_screenshot or figma_get_node.

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 clear context for when the tool is appropriate: it can target a node or the whole file, accepts a local .fig path, a file key, or a URL, and explains refresh behavior. It does not explicitly name alternatives or say when not to use it, but the usage context is strong enough for an agent to make a reasonable selection.

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 already indicate readOnlyHint=true, so the description doesn't need to repeat that. It adds substantial behavioral context: it explains that internal-only pages are excluded from lists but still counted (except library components on such pages are skipped), and it clarifies the meaning of 'exportedAt' and 'fileModifiedAt' including the fact that local .fig file times can be unreliable. This goes beyond annotations and helps the agent understand the data's freshness.

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 dense paragraph, which is somewhat heavy but every sentence adds important technical detail about the tool's output and edge cases. It is front-loaded with the core content and then explains nuances; a slight structure improvement would be splitting into bullet points, but it's efficient overall.

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 covers the tool's output structure, counting logic, edge cases (internal-only pages), and staleness semantics, including the difference between URL and local file paths. Given the complexity of the tool and the absence of an output schema, the description is remarkably complete for an agent to understand what it returns and how to interpret it.

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%, so the schema fully documents parameters. The description adds no new parameter semantics beyond what the schema already says; it mentions 'refresh' but not in a way that expands on the parameter description. Thus a baseline 3 is appropriate.

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 identifies the tool as returning component definitions and usage counts from a Figma file, with a specific structure distinguishing componentSets, components, and libraryComponentsUsed. It is distinct from siblings like figma_get_tree or figma_get_node because it focuses on components specifically.

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 implicitly covers when to use this tool (when you need component definitions and usage counts) and provides important guidance on staleness: it explains the exportedAt field, when refresh is needed, and the caveat about local .fig files. Sibling tools are not explicitly named, but the clear scope and context make usage clear.

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?

The description goes well beyond the readOnlyHint annotation by disclosing that instances are not expanded, that the result is tied to a snapshot timestamp (exportedAt vs fileModifiedAt), and that local .fig copies can silently carry stale data whose age cannot be determined. It also explains the refresh parameter's effect and the refreshIgnored case. This is rich, actionable behavioral 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 a single dense paragraph, but every clause carries useful information: content list, instance expansion, timestamp semantics, and local-file caveat. It front-loads the tool's primary purpose before diving into snapshot timing. Slightly long but justifiably so for a tool with this much behavioral nuance.

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 data-retrieval tool with no output schema, the description enumerates the returned design aspects and explains the critical freshness limitations that could otherwise mislead an agent. It does not detail the output structure or how to obtain node_id, but the schema's file parameter covers node-id-in-URL, and the listed content areas are sufficient to set expectations. Minor gaps exist around error cases and depth defaults, but these are already in the schema.

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 input schema already describes file, depth, and refresh, covering 75% of parameters. The description adds meaning for refresh ('pass refresh to export it again') and clarifies the local-file behavior, but it does not explain node_id or depth beyond what the schema/name implies. With partial schema coverage, this is adequate but not exhaustive.

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 returns 'Detailed design data for a node and its subtree' and enumerates the content (geometry, fills/strokes/effects, auto-layout, text styling, component/instance info). It distinguishes from siblings by noting 'Instances are not expanded', but it lacks an explicit verb and doesn't name alternative tools, so it falls just short of full differentiation.

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 explicit when-to-use guidance or comparison to sibling tools such as figma_get_tree or figma_get_text. The description provides operational cautions about data freshness ('The result is dated by the copy it answers from', 'pass refresh to export it again') but these are behavioral caveats, not selection criteria. The intended use must be inferred from the tool name and content 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?

The description discloses the empty-result behavior, the refresh option to bypass local copies, and the ability to write output via out_file. However, it does not explicitly state whether the tool modifies any state beyond optional file writing, and it omits authentication requirements or network effects. Since annotations provide no read-only guarantee (readOnlyHint=false), the description carries the burden but does not fully clarify.

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 three short, focused sentences that front-load the core purpose and types before mentioning formats and edge-case behavior. It is efficient and avoids redundancy, though it could be slightly more structured with bullet points for readability.

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 6-parameter tool with no output schema, the description explains the main behavior and output formats but leaves css_prefix undefined and does not describe the structure of the returned data. The empty-result note is helpful, but the lack of details on authentication, pagination, or error cases makes it incomplete for an agent needing to call 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?

The schema covers 67% of parameters with descriptions. The tool description adds the default format ('json (default)') and lists the style types, complementing the schema. However, css_prefix is entirely undocumented in both schema and description, and the description does not clarify the interaction between type and format beyond what is in 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?

The description clearly identifies the resource (styles) and the verb (get) along with the supported types (FILL, STROKE, TEXT, EFFECT, GRID) and formats (json/css). It distinguishes itself from siblings like figma_get_variables and figma_get_components by focusing specifically on styles, though it does not name an alternative 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?

The description provides context about behavior (e.g., empty result if no styles) and formats, but does not mention when to prefer this tool over related ones like figma_get_variables or figma_get_components. There is no guidance on prerequisites (e.g., authentication) or typical use cases.

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 already mark it read-only and open-world, but the description goes far beyond that. It discloses how component instances are expanded, that hidden layers are excluded by default, the meaning of unresolvedInstances and the snapshot timing with exportedAt and refresh. It even explains local file quirks with fileModifiedAt. This is exemplary transparency with no contradiction to 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 long but every sentence contributes critical edge-case information. It front-loads the primary purpose and then systematically covers instances, hidden layers, unresolved instances, and timing. It is not verbose for the complexity, though it could be better structured with bullet points. Overall, it earns its length.

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, so the description compensates by explaining the result fields (total/truncated/unresolvedInstances, unresolved, unresolvedComponentsOmitted) and their meanings. It also covers snapshot dating, refresh behavior, and local file caveats. For a tool with this many nuances, the description is remarkably 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?

Schema description coverage is 80% (node_id lacks a description). The description adds meaningful semantics for file (local resolution, URL handling, node_id inheritance), refresh (skip caches, no effect on .fig), and include_hidden (default false). It also indirectly clarifies node_id via the file parameter. This exceeds the schema baseline, though limit remains generic.

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 opens with 'All text content under a node (or the whole file) in reading order, with node ids', which is a specific verb and resource. It clearly distinguishes this from sibling tools like figma_get_tree or figma_get_node by focusing exclusively on text extraction and detailing instance expansion. The purpose is unambiguous and well-scoped.

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?

While the description never explicitly names alternatives or says 'use this instead of X', it strongly implies usage by describing exactly what it returns and when. The coverage of node vs. file, hidden layers, and refresh behavior makes the appropriate use cases obvious. However, it does not explicitly state what it is NOT for or compare to siblings, so it misses the top score.

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 already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds behavioral context by noting the output is a 'compact outline' and that omitting node_id returns all pages, which is useful beyond the schema. However, it does not describe pagination behavior, output structure nuances, or the meaning of 'hints', so it only partially complements the 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, tight sentence that front-loads the core purpose ('Compact outline of the layer tree') and immediately follows with the most important behavioral tip (omit node_id for all pages). Every word earns its place; there is no fluff or repetition.

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 read-only outline tool with a well-documented schema and safety annotations, the description conveys the essential purpose and key default behavior. It does not explicitly guide selection among the many sibling tools, but the term 'compact outline' offers enough distinction. Given the absence of an output schema, a brief note on return shape or the meaning of 'hints' would improve completeness, but the current definition is adequate for correct invocation.

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%, so the baseline is 3. The description adds meaning beyond the schema by instructing 'Omit node_id for all pages,' which clarifies the default behavior of the node_id parameter. This is a meaningful semantic addition that helps an agent correctly use the tool without opening the schema.

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 retrieves a 'compact outline of the layer tree' with specific fields (id, type, name, size, hints), which identifies the verb and resource. It does not explicitly name a sibling alternative, but the phrase 'compact outline' and the instruction to omit node_id for all pages differentiate it from more detailed or targeted tools like get_node or search.

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 one explicit usage instruction: 'Omit node_id for all pages.' This implies when the tool is appropriate (whole-file tree overview) but does not state when to prefer a sibling like get_node or token_usage, nor does it provide when-not-to-use guidance. The usage context is implied rather than explicit.

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?

Beyond the sparse annotations (readOnlyHint false, openWorldHint true), the description discloses meaningful behavior: supported output formats and their semantics, the empty-result behavior, and the distinction from sibling tools. It also clarifies via refresh semantics that file paths are read as-is while keys/URLs may require browser export, which is useful behavioral 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?

Three dense sentences deliver the core purpose, format semantics, plan availability, and sibling differentiation with no filler. Every sentence earns its place, and the most decision-relevant information is front-loaded.

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 7-parameter tool with no output schema, the description covers the key behavioral decisions: how to interpret output, how to pick among formats, what happens when no variables exist, and which sibling to choose instead. Combined with the schema's parameter descriptions, this is sufficient for correct invocation.

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 71% schema coverage, the schema already documents most parameters. The description adds value by explaining the format enum (json default, css custom properties with extra modes, dtcg W3C design tokens), which maps directly to the format parameter, and by explaining which sibling tools cover alternative extraction approaches.

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 the resource ('Design variables (tokens)') and what the tool provides: collections, modes, per-mode values, and resolved aliases. It also explicitly contrasts itself with figma_token_usage and figma_get_styles, so an agent can distinguish it from siblings without opening schemas.

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?

It gives clear selection guidance: use this for variables/tokens, figma_token_usage for deriving tokens from raw values, and figma_get_styles for styles. It also clarifies plan availability ('Works on any plan') and that a file with no variables answers empty in the selected format.

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 already declare readOnlyHint and openWorldHint, and the description adds valuable context about the source-specific behavior (local .fig files vs. recently viewed web files) and the totalUnfiltered field with query. This goes beyond the annotations and enriches the agent's understanding of what the tool does.

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 two sentences with no wasted words. It front-loads the core purpose and then efficiently explains the key nuances of source and query. Every sentence 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?

There is no output schema, so the description should explain what the tool returns. It mentions searchedDirs and totalUnfiltered but does not describe the overall structure of the returned list (e.g., file names, paths, pagination). This leaves some ambiguity about the exact output format, making it only partially complete for a listing tool.

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 67%, and the description adds meaning to the source parameter by explaining the local/web distinction and to the query parameter by mentioning totalUnfiltered. It does not add meaning to limit, but limit is already described in the schema. Overall, it compensates well for the gaps.

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 action and resource: 'List Figma files.' It further distinguishes between local and web sources, making the tool's scope clear and distinct from siblings like figma_load_file or figma_search. The verb 'list' is precise and the resource is unambiguous.

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 how to use the tool (source selection, query behavior) but does not explicitly mention when to choose this tool over alternatives like figma_search or figma_get_tree. Usage is implied by the purpose, but no exclusions or alternatives are named.

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?

Annotation Contradiction: annotations mark readOnlyHint=true, but the description explicitly says 'Export (Save local copy)' and describes caching and re-exporting, which are state-writing behaviors. The description adds useful staleness context (exportedAt, fileModifiedAt, refreshIgnored), but the read-only signal is directly contradicted.

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 text is dense but well organized: purpose, caching/performance, and date semantics each get a distinct passage. It is longer than strictly needed for two parameters and repeats the export/cache idea, but every sentence carries real operational guidance.

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 snapshot/load tool with no output schema, the description covers the return summary, cache reuse, large-file latency, refresh behavior, and the fileModifiedAt staleness caveat. There is enough for an agent to call it correctly and interpret its results without inspecting siblings or schemas.

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?

Even though schema coverage is 100%, the description adds substantial meaning: node-id handling in URLs, the local '<name> [<key>].fig' fallback from FIGMA_FILES_DIRS, the distinction between live export and disk read, and refreshIgnored behavior. An agent gains much more than the bare schema would provide.

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 names a specific action and resource: 'Export (Save local copy) and decode a Figma file' and lists the returned summary (pages, node counts, variable collections, styles, components). It also separates this tool from the many sibling tools by presenting it as the cached snapshot source: 'Snapshots are cached; other tools reuse 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?

It explains when to use a cached result versus refreshing ('pass refresh to export it again'), and gives a clear when-not for paths ('Has no effect when file is a path to a .fig ... pass the key or URL'). The note that other tools reuse the snapshots implies this is the intended entry-point loader.

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?

The description goes well beyond the annotations (readOnlyHint=false, openWorldHint=true) by disclosing that it opens a non-remote-controlled browser, that the window self-closes, that headless work resumes afterward, and that wait_seconds blocks until login completes.

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 two sentences with no filler. Purpose, trigger condition, user interaction, and headless continuation are front-loaded in a compact, readable form.

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 one-optional-parameter tool with no output schema, the description covers the essential behavior, UI side effect, and blocking semantics. The only noticeable gap is timeout/failure behavior, which is minor given the tool's simplicity.

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 0%, so the description must carry the parameter meaning. It states that wait_seconds blocks until login completes, which adds semantic value beyond the schema's min/max, but it does not explain the default behavior when omitted or what happens if the timeout is reached.

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 names a specific operation and resource ('ensure ... logged into figma.com') and explains the trigger condition ('if not') and action. It is clearly distinct from all sibling tools, none of which handle authentication or login.

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?

It communicates the use case (before headless work that requires an authenticated account) and behavior ('if not, opens a normal browser window'). It does not name alternatives, but no sibling tool provides this function, so no exclusions are needed.

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?

Beyond the annotations, the description adds valuable behavioral detail: the system clipboard is not touched, the live file is used instead of a snapshot, and the returned image is downscaled to max_dimension. This provides meaningful transparency about side effects and data source, though it doesn't cover auth or failure modes.

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 sentences, each carrying distinct information: rendering method, side-effect negation, source, and output scaling. There is no filler, repetition, or unnecessary 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, the description conveys the core behavior—returns an image, downscaled, from the live file—and the key side-effect it avoids. It is slightly thin on edge cases like omitted node_id or error behavior, but the schema covers file format details, so an agent has enough to call 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?

The input schema already provides descriptions for 75% of parameters, and the tool description mostly restates or reinforces that information, such as downscaling to max_dimension and using the live file. It adds little meaning beyond the schema, and node_id remains only indirectly described.

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 ('Render'), a resource ('a node'), and an output format ('PNG'), making the tool's purpose immediately clear. It also distinguishes itself from snapshot-based or export-related siblings by noting it uses Figma's own 'Copy as PNG' with the live file, not the snapshot.

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 useful context, such as 'Uses the live file, not the snapshot,' which implies when this tool is appropriate, but it does not explicitly state when to use it versus alternatives or name exclusions. An agent must infer usage rather than receiving direct guidance.

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 only declare readOnlyHint=true and openWorldHint=true, so the description carries the burden of behavioral disclosure. It does this thoroughly: it discloses that the result is dated by the snapshot copy (exportedAt vs fileModifiedAt), that refresh re-exports, that characters is truncated to 120 chars with charactersTruncated flag, that unresolvedInstances counts unresolved text, and that local .fig file times can be misleading. This is rich behavioral context beyond the 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 dense and information-rich, with the core purpose front-loaded in the first sentence. Every sentence adds meaningful behavioral detail. It is long, but the length is justified by the tool's complexity (11 parameters, subtle text-search semantics). A slight deduction for density: the paragraph on exportedAt/fileModifiedAt could be tightened, but it 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 tool with 11 parameters, no output schema, and only readOnly/openWorld annotations, the description is remarkably complete. It covers search semantics, regex behavior, instance expansion, truncation, result dating, refresh behavior, and error conditions (invalid regex). It also names sibling tools for follow-up (figma_get_text). Nothing critical is missing for an agent to select and invoke this tool 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 description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema: it explains the interaction between types and include_text ('A list without TEXT also turns include_text off'), the semantics of regex patterns (bare or /pattern/flags), and the meaning of via tags. It doesn't enumerate every parameter, but the schema already covers them; the description adds the non-obvious interactions.

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 opens with a specific verb and resource: 'Find nodes by name (and optionally text content).' It immediately distinguishes the tool from siblings like figma_get_node and figma_get_text by stating it searches by name/text across nodes, and the rest of the description clarifies scope (literal substring vs regex, instance expansion). This is a clear, non-tautological purpose statement.

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 explicit when-to-use guidance: it explains when regex=true is appropriate, when include_text is needed, and when to search a component instead of a collapsed instance ('Name matching sees only real layers... search that component instead'). It also names figma_get_text as the alternative for retrieving full strings, and figma_get_text for naming unresolved components. This is explicit routing to alternatives with conditions.

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 sparse (readOnlyHint=false, openWorldHint=true) and do not explain side effects. The description adds a valuable behavioral guarantee: it does not launch anything, which is safety-relevant for an agent deciding whether to call it. This goes beyond the annotations, though it does not disclose return format or network behavior.

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 sentences with no redundancy. The core state information is front-loaded, and the clarifying no-launch note is placed immediately after.

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 status tool with no output schema, the description is largely complete: it names what is reported and clarifies a key side-effect constraint. It could briefly mention what the agent will receive in the response, but the low complexity keeps this from being a major 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?

The tool has zero parameters and the schema is an empty object with 100% coverage, so there is nothing the description needs to add. The 0-parameter baseline of 4 is appropriate.

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 identifies the resource as 'account, browser and login state', which clearly signals a status-checking tool. It lacks an explicit verb like 'reports' or 'checks', but the follow-up 'Does not launch anything' differentiates it from file-loading and login siblings.

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 explicit when-to-use guidance or mention of alternatives. The note about local .fig paths never needing the browser implies a use context, but the description never says 'use this to verify login state before...' or contrasts it with figma_login or figma_load_file.

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 only say readOnlyHint and openWorldHint; the description adds substantial behavioral context: counts, variable/style binding, typography edge cases, textWithoutTypography accounting, exportedAt/fileModifiedAt meaning, and the local-file staleness trap. This far exceeds what structured annotations provide and correctly aligns with readOnlyHint.

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 front-loaded with the core purpose and use case, then adds genuinely necessary caveats about timestamps, typography, and refresh. It is dense and somewhat tangled, but every sentence earns its place given the absence of an output schema.

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 covers result composition, counting semantics, typography edge cases, and snapshot timing, which is strong given no output schema. It still leaves node_id and include_hidden behavior underspecified, though their schema types provide some basic signal.

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 60%, and the tool description supplements refresh semantics and subtree scoping, but node_id and include_hidden are left to their bare schema types. The file parameter's key/URL/path nuance is largely schema-provided; the description adds a little extra but does not fully compensate for the undocumented parameters.

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 precise operation: scan a subtree or whole file and aggregate raw design values actually used, listing the value categories and counts. It also distinguishes the tool's purpose from variable/style-based tools, making it easy for an agent to tell it apart from siblings like figma_get_variables and figma_get_styles.

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?

It gives an explicit intended use—'derive a token set from files that do not define variables or styles'—and explains when to pass refresh versus when it is ignored. It implies alternatives but does not explicitly name them or give when-not-to-use conditions, so it falls just short of a 5.

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