figma-unified-mcp

by sso-ss

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation3/5
Many tools have overlapping purposes, such as multiple node retrieval methods (figma_get_node, figma_get_nodes, figma_get_selection, figma_search, figma_scan_nodes_by_types) and several export options (figma_export_svg, figma_export_png, figma_get_images, figma_screenshot, figma_export_to_file). However, detailed descriptions and slightly different scopes help mitigate confusion, though the sheer volume makes selection difficult.
Naming Consistency5/5
All tools follow a strict 'figma_verb_noun' pattern in snake_case, which is highly consistent and predictable. There are no deviations in style or format, making it easy to infer the function of each tool from its name.
Tool Count1/5
With 106 tools, the server has an extremely large and overwhelming surface. This far exceeds a reasonable scope for an MCP server, likely leading to high cognitive overhead and potential selection errors. The tool count is excessive even for a comprehensive Figma integration.
Completeness4/5
The server covers a vast range of Figma capabilities including file manipulation, node operations, styles, variables, prototypes, code generation, and more. Minor gaps exist, such as the absence of delete/update for comments and limited page management (no rename/delete page), but overall the coverage is extensive and well-rounded.
Average 3.1/5 across 100 of 106 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on March 2, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits, but it only states the action 'Create a rectangle'. It does not mention that the operation adds a new node to the document, what parent is used by default, coordinate units, or any side effects, leaving the agent completely uninformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but under-specified. It is a single sentence that essentially repeats the tool name, providing no value. It cannot be considered efficient since it fails to convey any useful information beyond the schema/name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no annotations, and no output schema, a one-sentence description is severely incomplete. It should explain the rectangle's placement, default behavior, and parameter semantics, but instead leaves almost all context missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 18% schema description coverage (fillColor, strokeColor), the description must compensate for the other 9 parameters, but it adds nothing. It does not explain required width/height, x/y coordinates, opacity, cornerRadius, strokeWeight, name, or parentId semantics, forcing the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a rectangle' exactly restates the tool name (figma_create_rectangle) without adding any new information. While it identifies the verb and resource, it is tautological and does not provide any differentiation from sibling creation tools beyond the noun itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no context about when to use this tool versus alternatives (e.g., figma_create_ellipse, figma_create_frame, figma_create_text). There are no exclusions, prerequisites, or references to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the only source of behavioral context. It discloses nothing about side effects (e.g., whether resizing overwrites existing dimensions), units of measurement, whether changes are reversible, or any constraints on the operation. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but under-specification is not conciseness. The single sentence 'Resize a node' provides no operational detail and could apply to any resizing API. A concise, useful description would include key constraints or usage hints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations, no output schema, and an extremely minimal description. It lacks all contextual information needed for an agent to safely invoke it, such as whether it requires a selected node, what happens on failure, and how the parameters interact. Clearly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description provides no parameter explanations. While the property names (nodeId, width, height) are somewhat self-evident, the description doesn't clarify units, bounds, or relationships (e.g., whether aspect ratio is preserved). The description fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Resize a node' is a clear verb+resource but essentially restates the tool name, offering no additional context about what resizing involves or how it differs from sibling mutation tools. It is more informative than a pure tautology like 'Process' but still minimal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description doesn't state when to use this tool, prerequisites (e.g., node must exist), or alternatives (such as set_constraints or move_node for similar layout operations).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states a vague action. It does not mention side effects, required permissions, return values, or how the nodeId parameter affects the presentation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified rather than concise. It omits essential information, making it more of a placeholder than a helpful tool explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and an undocumented parameter. The description is far too brief to provide a complete understanding of its purpose, usage, or behavior, especially given the large sibling toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (nodeId) with 0% description coverage, and the description does not mention it. The description adds no meaning beyond the naked schema, so it fails to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Open prototype presentation view' uses a specific verb and resource, clearly indicating the tool enters a prototype presentation mode. It is distinct from siblings like figma_get_flows or figma_screenshot, though it lacks detail about what 'open' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as figma_create_flow or figma_get_flows. The description offers no context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action, omitting any details about side effects, required permissions, response format, error behavior, or potential risks of sending raw commands. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, but it is under-specified. While not as degenerate as a single word, it omits critical information and could be more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 params, no annotations, no output schema), the description is entirely inadequate. It does not explain what the command does, what parameters mean, return values, or any usage context. This is unusable for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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. It only mentions 'raw command' and does not explain the 'command', 'params', or 'timeout' parameters. The input schema provides minimal structural info, but the description adds no semantic meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Send') and resource ('raw command to the plugin'), but 'raw command' is ambiguous and does not clarify what kinds of commands are valid. It is distinguishable from siblings as a generic escape hatch, but the purpose remains vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many specific sibling tools (e.g., figma_create_ellipse, figma_get_node). No context is given for appropriate use cases or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states 'Group nodes together' without explaining what grouping entails (e.g., whether it creates a frame, changes node hierarchy, or requires a minimum number of nodes). There is no mention of side effects, permissions, or reversal, leaving the agent without critical behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (six words), which could be seen as concise, but it is under-specified rather than efficiently informative. It does not front-load any context beyond the basic action, and the sentence does not earn its place by adding meaningful detail. It is more a placeholder than a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 parameters, no output schema) and minimal annotations, the description should provide more context about the operation's constraints and effect. It does not explain when grouping is appropriate, what happens to the selected nodes, or any return value. The description is barely sufficient to define the tool's existence but not its usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description does not mention any of the parameters (nodeIds and name). No additional meaning is provided beyond the bare property names in the schema. The description fails to clarify how the 'name' parameter is used or how nodeIds should be structured, leaving the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'Group nodes together.' It identifies the verb 'group' and the resource 'nodes,' making the tool's purpose immediately understandable. However, it does not explicitly differentiate from sibling tools like figma_reparent_node or figma_move_node, though 'group' is a distinct operation in design tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, such as needing multiple nodes or whether the nodes must be on the same parent, nor does it contrast with other node-manipulation tools. Usage context is entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It only mentions WebSocket as the transport but omits details about connection lifecycle, side effects, or what happens after connecting. This is minimal transparency for a tool that likely establishes a persistent connection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, but it is under-specified. Conciseness should not come at the expense of necessary detail; the lack of elaboration on parameters or behavior makes it insufficiently informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a connection tool with one parameter and no output schema), the description is woefully incomplete. It doesn't explain how to use the tool, what the connection enables, or expected outcomes, making it inadequate for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema contains one parameter ('channel') with a default but no description, and the tool description provides no explanation of what 'channel' means or how it affects the connection. With 0% schema description coverage, the description fails to compensate, leaving the parameter's purpose unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Connect') and the target ('Figma plugin'), with the method ('via WebSocket') adding specificity. It distinguishes itself from sibling tools, which are mostly get/set operations, though it could be more explicit about what 'connect' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or setup steps. The description only states the action without context on typical use cases or preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure, but it only says 'Create a line.' It does not describe coordinate space, units, default properties, or how the line is placed in the document.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
'Create a line.' is extremely concise, but this is under-specification rather than efficient communication. It front-loads the core action but omits essential details, failing to earn its place as a useful tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, no output schema, and no annotations, a one-sentence description is severely incomplete. It does not explain return values, side effects, or how this tool fits into the broader Figma workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 13%, and the description adds nothing about parameter meanings. While some property names are self-explanatory (startX, startY, endX, endY), fields like parentId, name, strokeColor, and strokeWeight lack explanation beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a line.' clearly states the action (create) and the resource (line), distinguishing it from sibling create tools for ellipses, rectangles, and text. However, it lacks any context about the Figma canvas or coordinate system, making it less informative than it could be.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives like create_path or create_from_svg. It does not mention prerequisites such as a parent container or how this differs from drawing a path with multiple segments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility. It only repeats the action name and adds no behavioral details such as merge vs replace semantics, idempotency, error conditions, or whether it requires an existing instance. This provides little transparency beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified and largely restates the tool's name. It lacks the detail needed to be practical. While not verbose, it does not earn its place because it conveys minimal added information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (nested object parameter, no annotations, no output schema), the description is severely incomplete. It does not mention return values, error behavior, how overrides should be structured, or any constraints. It is inadequate for an agent to invoke this tool correctly without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameter. The 'overrides' parameter is a loosely-typed object with no property definitions, making its structure opaque. The description offers no clues about how to format overrides, what targetNodeIds refer to, or the relationship between the two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the primary action (Apply overrides) and the target resource (component instances). It distinguishes itself from the sibling tool figma_get_instance_overrides, though not explicitly. The verb and resource are specific enough for basic understanding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description does not state when to use this tool versus alternatives, no prerequisites, and no exclusions. The only implicit signal is the sibling get_instance_overrides, which is not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Create an ellipse/circle,' which implies a mutating operation but does not explain side effects, return values, coordinate system, units, or whether the operation uses the current selection. This is minimal behavioral information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), which is good for front-loading. However, it is under-specified — while every word earns its place, it sacrifices necessary information. A concise but more informative description would score higher.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple shape-creation tool with 7 parameters and no output schema, the description is incomplete. It does not explain coordinate origins, units (pixels), default parent behavior, or what happens after creation. While the tool is relatively simple, the description should at least clarify these basics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14%, with most parameters (width, height, x, y, name, parentId) lacking semantic explanations. The description adds no parameter detail whatsoever, leaving the agent to infer the meaning of coordinates, units, and optional fields from the schema alone. For a 7-parameter tool with 2 required, this is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and a clear resource ('ellipse/circle'), which clearly communicates the primary action. It is distinct from sibling tools like figma_create_rectangle or figma_create_text, but it does not mention any additional context like where the ellipse is created or what the parameters represent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., figma_create_rectangle or figma_create_path). There is no mention of prerequisites, typical use cases, or exclusions, leaving the agent without direction for choosing this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states that it uses the REST API and doesn't require a plugin, but fails to disclose prerequisites, side effects, or response behavior. This is minimal transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core purpose, and contains no waste. However, it is brief to the point of underspecification, so it does not earn a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, nested objects, no output schema) and low schema coverage, the description is severely incomplete. It fails to explain where to find the fileKey and collectionId, how to format values, or what the response contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 38%, so the description should compensate by explaining parameters. However, it only repeats the enum values already present in the schema, adding no meaning for parameters like collectionId, name, value, scopes, or valuesByMode.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a variable') and lists the allowed types (COLOR, FLOAT, STRING, BOOLEAN). It distinguishes from sibling tools like create_variable_collection by focusing on the variable resource, though it doesn't explicitly mention that a collection ID is required.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like update_variable or set_variable_value. The note 'Uses REST API — no plugin required' is a technical detail, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits, but it doesn't. It implies mutation but fails to disclose whether x/y are absolute or relative, what units are used, or any side effects. This leaves the agent guessing about critical behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, but this brevity is under-specification rather than conciseness. It front-loads the verb but omits essential details, making it less useful than a longer, more informative description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema and no annotations, the description alone is insufficient. It doesn't explain return values, coordinate handling, or error conditions. A minimal move operation still needs more context to be safely invoked.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds no meaning to the parameters. x and y are just numbers, nodeId is just a string, but their roles in positioning are entirely unspecified. The description fails to compensate for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Move a node to a new position,' which identifies a specific action (move) and resource (node) with a clear intent. It distinguishes from sibling tools like resize or reparent, though it doesn't explicitly call out alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. The description is a bare statement of functionality with no context about prerequisites, coordinate systems, or exclusion cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only states the action without mentioning potential side effects, such as overwriting existing corner radii, whether the change is reversible, if it affects child nodes, or if specific permissions are required. This is a minimal disclosure that adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it omits critical information about parameters and behavior. This is under-specification rather than effective conciseness, as every sentence (only one) should earn its place but does not convey enough to properly use the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no annotations, no output schema), the description is severely incomplete. It does not explain how to use the parameters, the difference between uniform and per-corner radii, or what happens after the operation. The agent would need to guess or inspect the schema, which has no descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter explanations. The relationship between the uniform 'radius' parameter and the individual corner parameters is undefined, leaving the agent without any semantic understanding beyond raw schema names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'set' and the resource 'corner radius' of a node, which is distinct from sibling tools that set other properties. However, it fails to mention that individual corner radii (topLeft, topRight, bottomLeft, bottomRight) can be set, leaving out a major part of the tool's functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, such as node selection or type restrictions, and no exclusions or recommendations relative to other set_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only says 'set default transition'—implying a mutation—but does not mention whether it is destructive, requires specific permissions, how it affects existing transitions, or what the return behavior is. This is a significant gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words or redundant information. It is appropriately front-loaded, though its brevity veers toward under-specification, which prevents a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 5 parameters, no annotations, and no output schema, the description provides only a bare action statement. It lacks essential context about parameter semantics, usage conditions, and expected outcomes, making it completely inadequate for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 5 parameters (nodeId, transition, duration, easing, direction) with 0% description coverage, and the description entirely fails to mention or explain any of them. It does not compensate for the schema's lack of detail, leaving the agent with no guidance on what values mean or how they interact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('set') and the resource ('default transition') scoped to 'this frame,' which conveys the tool's core purpose. However, it does not differentiate this from other set_* tools or explain what 'default transition' means in context, so it loses the full top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like create_interaction or remove_interactions. The description gives no context on prerequisites, typical scenarios, or why one would choose this over other transition-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies mutation (configuring a frame) but does not state side effects, whether existing prototype settings are overwritten, or any requirements like the frame being part of a prototype. This is too vague for an agent to anticipate consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words, but it is under-specified. It lacks the detail needed to be truly concise; it is more terse than informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, this description is far from complete. It fails to explain the purpose of each parameter, the behavior of the overlay configuration, or how it fits into the prototyping workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description offers zero parameter information, and schema description coverage is 0%. It does not explain what nodeId refers to, nor the meaning of overlayBackground, overlayBackgroundColor, or overlayBackgroundInteraction. The agent must infer everything from the schema alone, which is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('configure') and the resource ('a frame as an overlay in prototypes'), which distinguishes it from sibling tools like figma_create_interaction. However, it could be more specific about which overlay properties are configured (e.g., background, interaction).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as figma_create_interaction or figma_set_default_transition. There are no prerequisites, exclusions, or context cues to help the agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing side effects. It merely restates the function name ('Add a prototype interaction to a node') without mentioning that this mutates prototype state, whether existing interactions are replaced, or what conditions must be met.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler or unnecessary words. It is front-loaded with the key verb and object, though it lacks the detail that a 12-parameter tool would benefit from.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 12 parameters, 3 required fields, 6 enums, no annotations, and no output schema, a one-sentence description is grossly insufficient. It does not explain the supported interaction types, required fields, or the effect of the operation, leaving the agent without essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 12 parameters with 0% description coverage, and the tool description adds no explanation of any parameter. It does not clarify how nodeId, trigger, action, destinationId, or transition relate to one another, so the agent must guess from enum names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add'), the resource ('a prototype interaction'), and the target ('to a node'). This is specific enough to distinguish it from sibling tools like figma_get_interactions or figma_remove_interactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as figma_create_flow, figma_set_default_transition, or figma_setup_overlay. The description only states what it does, not when it should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must reveal behavioral traits but does not. It fails to mention whether the operation is destructive, whether it creates a new node or modifies existing ones, what happens to the input shapes, or any side effects. This is a significant gap for a boolean operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, using simple language. However, it is under-specified for a tool with nuanced behavior, so the brevity comes at the cost of clarity. It could be expanded slightly without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool involves non-trivial boolean operations, yet the description omits critical context such as node type requirements, result structure, and behavior specifics. The absence of an output schema and annotations further increases the burden on the description, which does not meet it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. It partially does by listing operation values and mentioning '2+ nodes', but it does not explain the optional 'name' parameter or clarify semantics like ordering for SUBTRACT. The enum values are already in the schema, and the description adds little beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the core action ('Boolean op') and lists the possible operations (union/subtract/intersect/exclude) with a requirement on '2+ nodes'. This makes the tool's purpose clear and distinguishes it from grouping or other node-manipulation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like figma_group_nodes or figma_move_node. The description implies a scenario (2+ nodes) but does not mention exclusions, prerequisites, or when another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the basic action. It does not explain what 'semantic' means, whether styles are included by default, what node types are supported, or how the HTML output is returned (inline string, file, etc.). This is a significant transparency gap for a codegen tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words, making it easy to parse. However, it is under-specified for the tool's complexity, so while structurally efficient, the extreme brevity borders on under-specification rather than conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has three parameters, no output schema, no annotations, and many sibling codegen tools, yet the description provides no return value details, parameter semantics, or behavioral nuances. It is incomplete for an agent to invoke correctly without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about the three parameters (nodeId, semanticTags, includeStyles). The parameter names hint at their role, but the description does not compensate for the lack of documentation, leaving the agent to guess how each parameter affects generation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates semantic HTML from a node, using a specific verb ('generate') and resource ('node'). It distinguishes itself from sibling codegen tools like generate_css and generate_react by naming the output format (HTML), though it does not explicitly contrast with those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many sibling codegen tools (e.g., generate_css, generate_react, generate_swiftui). The intended use case is only implied by the phrase 'generate semantic HTML,' with no exclusions, prerequisites, or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Generate SwiftUI code from a node,' which reveals nothing about whether the tool performs a read-only operation, has side effects, requires authentication, or returns data in a particular format. The absence of any behavioral context makes it nearly impossible for an agent to anticipate the tool's impact or requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence, which is concise and front-loaded. However, it is so terse that it borders on under-specification. It communicates the core purpose but omits essential details, making it minimally acceptable rather than genuinely helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain what the generated code looks like, how the parameters affect the output, or what the agent should expect in the response. For a code-generation tool, this level of context is inadequate for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 4 parameters but 0% description coverage, and the description offers no explanation of what parameters like structName, includePreviews, or useSystemColors do. The only hint is 'from a node,' which corresponds to nodeId, but even that is not explicitly tied. The description adds no value beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: generating SwiftUI code from a node. The verb 'generate' is specific, and 'SwiftUI code' differentiates it from sibling tools like figma_generate_css or figma_generate_react. It explicitly names the input resource ('a node') and the output type, making the purpose immediately obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage in contexts where SwiftUI code generation is needed, but it does not explicitly state when to use this tool over alternatives like figma_generate_react or figma_generate_html. No exclusions or conditional guidance are provided, so the usage context is only inferred from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states that it 'exports' tokens. It does not clarify whether this is a read-only operation, whether it acts on the current selection or entire file, or how the output is delivered (e.g., download, clipboard, inline response). The lack of any behavioral context beyond the verb leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, which is positive for front-loading. However, it is underspecified for a tool with two parameters and no annotations; brevity is achieved at the expense of necessary detail. It is not overly verbose but fails to be 'appropriately sized' in terms of complete information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fails to explain what 'export design tokens' concretely means—what is exported, where it comes from, or what the output looks like. There is no output schema and no annotations to fill the gaps. Given that the schema only provides enums without descriptions, the missing context makes the tool hard to use correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only partially compensates by listing a few format values (CSS vars, JSON, SCSS) while omitting javascript, typescript, and the tokenTypes parameter entirely. The description does not explain what 'tokenTypes' controls or the distinction between format options. It adds minimal meaning beyond the schema's own enums.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Export design tokens' and lists common formats (CSS vars, JSON, SCSS). This distinguishes it from sibling generation tools like figma_generate_css or figma_generate_react, which target code generation rather than token exports. However, it omits the javascript and typescript formats from the parenthetical, slightly underrepresenting the schema's capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not mention that it should be used for design token extraction rather than node-based CSS generation, nor does it reference any sibling tools. The only implied usage is via the name and formats, but this is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only restates the tool's basic function without mentioning read-only nature, pagination, the scope of comments (e.g., resolved/unresolved), or any response details. It adds no behavioral traits beyond what the tool name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, easily parseable sentence, making it concise. However, it is so minimal that it borders on under-specification, lacking important context that could be added without much length. It is not optimally structured for helping an agent select the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is far too sparse. It does not clarify any nuances such as what the response contains, whether comments are threaded or flat, or how it relates to figma_get_annotations. The absence of an output schema makes this incompleteness more significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains one parameter (fileKey) with no description, and schema description coverage is 0%. The phrase 'on a file' gives minimal inference that fileKey identifies the target file, but it does not explain the format, source, or validation of the key. The description fails to adequately compensate for the complete lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get) and resource (comments on a file), which is a specific verb+resource combination. However, it does not explicitly differentiate from sibling tools like figma_get_annotations or figma_post_comment, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the description—use this when you need comments on a file—but there is no explicit guidance about when to choose this over alternatives like figma_get_annotations or figma_post_comment. No when-not-to-use or alternative mentions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral transparency. It discloses the return content (properties, styles, children) but omits any mention of depth semantics, authentication requirements, or side effects. For a read operation, it is under-transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It is appropriately concise, though this 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description should at least clarify the depth parameter and the node pointer. With 0% schema coverage, no output schema, and no annotation context, this one-liner is insufficient for an agent to confidently use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 by explaining parameters. It does not mention fileKey, nodeId, or depth at all, leaving the agent without any semantic clues beyond the raw schema property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a node with properties, styles, and children, using the specific verb 'Get' and resource 'node'. While it doesn't explicitly distinguish from the plural `figma_get_nodes` sibling, the singular 'a node' implies a single-node scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like `figma_get_nodes` or `figma_get_file`. There is no mention of use cases, exclusions, or alternatives, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It only states the basic find-by-type capability and does not reveal whether the search is document-wide or scoped, how maxResults interacts, what is returned (full nodes vs summaries), or if there are any side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, and the examples add value. However, it is too minimal to be effective; it could include the purpose of maxResults and parentNodeId without being verbose. It is concise but under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three parameters, no output schema, and no annotations, the description is inadequate. It omits how results are returned, the scope of scanning, and the roles of maxResults and parentNodeId. The agent would need to guess crucial operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides examples of valid values for nodeTypes (FRAME, TEXT, COMPONENT) but does not explain maxResults (limit, default 100) or parentNodeId (scoping to a subtree). With 0% schema description coverage, these parameters are otherwise undocumented, leaving the agent to guess their meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Find') and resource ('nodes by type') with concrete examples (FRAME, TEXT, COMPONENT), making its core function clear. However, it does not differentiate from sibling tools like figma_scan_text_nodes or figma_search, which may also locate nodes by criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention suitable contexts, exclusions, or mention that figma_scan_text_nodes is more specialized for text nodes, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It does not mention side effects, whether it overrides existing constraints, permission requirements, or the return value. The phrase 'Set' implies mutation but provides no additional 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It is appropriately sized for a simple mutation tool, though it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, an output schema, and any parameter description, this is incomplete. The tool has three required parameters with enums, but the description fails to explain the concept of constraints, typical use cases, or what happens when the tool is invoked. An agent would struggle to invoke it correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% — the description mentions no parameter names or meanings. The schema provides enum values (MIN, MAX, CENTER, STRETCH, SCALE) but the description does not explain their semantic significance. The agent must rely entirely on the schema, which is insufficient for understanding how to choose values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Set') and the resource ('resize constraints') applied to a node. It is specific enough to distinguish from other setting tools like figma_set_opacity, but it does not elaborate on what 'resize constraints' means or how it relates to siblings like figma_resize_node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention of prerequisites, contexts, or exclusions. The description simply states the action, leaving the agent to infer usage from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'apply effects' without revealing whether it overwrites existing effects, what node types are supported, or what the return value is. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and resource, containing zero wasted words. It is as concise as possible, though the brevity negatively impacts other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a complex schema with multiple effect types and properties, no annotations, and no output schema. The one-line description is grossly inadequate for an agent to understand the full behavior, such as whether effects replace existing ones, supported node types, or how to construct the effects array correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 for parameter semantics, but it provides none. It doesn't explain the structure of the 'effects' array, the meaning of nodeId, or any field details beyond what the schema already shows with its enums and required fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Apply') and resource ('effects (shadows, blurs)') on a node, which distinguishes it from sibling tools like figma_set_fill or figma_set_stroke. However, 'apply' is slightly ambiguous about whether it adds to or replaces existing effects, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool instead of other set* tools, nor any prerequisites or edge cases. The description simply states what it does without any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral implications. It only mentions the plugin connection requirement, but fails to mention that the tool creates a new style (mutation), where it is created, or potential errors. This is a significant transparency gap for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one 9-word sentence), which is concise but sacrifices necessary detail. It is front-loaded, but under-specifies; the sentence itself is not wasted, yet the brevity does not serve the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without annotations or an output schema, the description is the only source of guidance. It fails to explain the structure of `properties`, the meaning of each type (including missing GRID), or what the tool returns. This is incomplete for a tool with 4 parameters including a nested object.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description adds no parameter semantics beyond the literal type examples (paint, text, effect) that are already in the enum. It does not explain the `properties` object, `name`, or `description` parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (create) and resource (reusable style), and lists example types. However, it omits the GRID type present in the schema, so it is slightly incomplete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no explicit guidance on when to use this tool versus alternatives like apply_style or get_style. The only additional context is the prerequisite 'Requires plugin connection,' which is not a usage guideline but does imply that a plugin connection must already be established.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it only states the basic action and does not mention what the generated component looks like, whether it returns code as a string, any dependencies, or side effects. It does not contradict annotations (none exist), but provides minimal 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the core action and object. There is no wasted wording or redundancy. However, while concise, it is arguably under-specified for the complexity of the tool, but that is already captured in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, no annotations, and numerous sibling code generation tools, this terse description is profoundly incomplete. It provides no information about parameter options, expected output, limitations, or which sibling tool to use. The agent would have no way to correctly configure or invoke the tool based on this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 5 parameters, but schema description coverage is 0%. The description does not explain any of the parameters such as 'typescript', 'styleFormat', 'includeProps', or 'componentName'. It only loosely implies 'nodeId' via 'from a node'. With zero coverage and no parameter explanations, the description fails to convey the meaning of the options.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Generate React component from a node.' It uses a specific verb ('generate'), identifies the output ('React component'), and specifies the source ('from a node'). This distinguishes it from siblings like figma_generate_html or figma_generate_css, which target different output formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. Sibling tools such as figma_generate_html, figma_generate_css, and figma_generate_swiftui represent similar code generation actions, but the description does not explain scenarios where React generation is preferred or where other tools should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits, but it only says 'Map' without indicating whether the operation is read-only, what it returns, or whether it requires a specific node selection. It doesn't explain the nature of the mapping or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the primary verb and object. It is free of fluff, but it omits useful details that would make it more informative without adding significant length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter documentation, the description is underspecified. It doesn't explain what the mapping looks like, how to interpret the result, or any limitations. For a tool with this complexity, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists one optional parameter 'nodeId' with no description, and schema coverage is 0%. The description does not mention the parameter or explain how it affects the mapping. Since the parameter name is self-explanatory, it gains a slight pass, but the description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Map' and identifies the resource: 'Figma components to source code locations.' This clearly conveys the tool's core function. However, it doesn't explicitly distinguish it from sibling tools like figma_get_dev_resources or figma_match_components, which could overlap in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, selection requirements, or scenarios where other tools would be more appropriate. The description offers no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose safety and return behavior. It only says 'Get', implying a read operation, but does not explicitly confirm read-only, describe the return payload, or mention any authentication requirements. This is insufficient for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no filler, making it easy to parse. It is appropriately concise for a simple getter, though it sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should explain what the tool returns and when to use it. It does neither, leaving the agent to infer the response format and differentiate from related tools. This is incomplete for a tool with even a single parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter componentKey has no description in the schema (0% coverage), and the description adds only 'by key' – essentially restating the parameter name without explaining the key format, where to find it, or how it's used. The description fails to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get a published component by key' – a clear verb+resource+scope. It differentiates from sibling tools like figma_get_components (plural) by specifying a single component lookup via key, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus figma_get_components, figma_get_team_components, or figma_import_component_by_key. The context is only implied by the word 'by key'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only reveals that the operation returns download URLs, which is useful, but it doesn't indicate whether the operation is read-only, if any mutations occur, rate limits, or authentication requirements. This is insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, each with clear value. 'Export nodes as images.' states the primary action, and 'Returns download URLs.' adds the output type. There is no fluff or redundancy, making it highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description should provide more complete context. It covers the basic purpose and return value but omits parameter semantics, usage guidance, and behavioral details. This is short of what is needed for a tool with multiple export siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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 by explaining the parameters. It mentions none of the four parameters (fileKey, nodeIds, scale, format), leaving the agent to infer their meaning from names alone, which is not reliable for the scale and format specifics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: export nodes as images and return download URLs. This is specific and understandable, but it doesn't explicitly differentiate from sibling export tools like figma_export_svg or figma_export_png, which could have similar purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or conditions for choosing this over other export tools, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not reveal whether renaming is permanent, whether it requires specific permissions, whether it affects the document tree, or any side effects. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words, achieving high conciseness. However, it is so minimal that it carries little informational value beyond the tool name, so it is not a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with no annotations and no output schema, the description is grossly incomplete. It does not explain return values, error cases, or the effect on the document, leaving the agent without essential operating context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% parameter description coverage, and the description adds no meaning beyond the property names 'nodeId' and 'name'. The implication that nodeId identifies the target and name is the new label is left entirely to the reader, so the description does not compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Rename') and a clear resource ('a node'), making the core action immediately understandable. However, it does not provide any scope or differentiation from sibling tools like figma_move_node or figma_set_text_content, so it lacks the distinguishing context needed for a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no mention of prerequisites or context, and no exclusions. The description simply states the action without explaining the appropriate usage scenario in the larger toolset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a read operation ('Search') but does not explicitly state whether it is read-only, how matching works (exact, partial, case sensitivity), or any limits/pagination. Minimal behavioral context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. However, it is somewhat underspecified, so while concise, it sacrifices completeness for brevity. Still, the structure is clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is too sparse. It does not explain return values, search behavior, depth implications, or any constraints. The tool is moderately complex, and the description fails to provide sufficient context for an agent to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. It maps 'name' to likely the 'query' parameter and 'type' to 'nodeType', but provides no detail on 'depth' or the required 'fileKey'. The added meaning is partial and does not fully clarify parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Search'), resource ('nodes'), and scope ('in a file'), and specifies search criteria ('by name or type'). It distinguishes somewhat from sibling tools like figma_scan_nodes_by_types, but does not explicitly differentiate itself, so it loses a point for not naming alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as figma_scan_text_nodes or figma_scan_nodes_by_types. The description only implies usage for name/type searches, without exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must disclose behavioral characteristics, but it does not. It fails to mention that this is a mutation, that existing layout properties may be overwritten, or that the node must be a frame for the operation to succeed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence with no redundancy. It is front-loaded but slightly under-specified; however, conciseness is evaluated as appropriate sizing, and no words are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 17 parameters, no output schema, and no annotations. The one-line description is grossly insufficient to understand the tool's full behavior, parameter interactions, or prerequisites, making it far from complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29%, and the description provides no parameter-level details. It only introduces the term 'flexbox,' which does not clarify the many enum and numeric parameters; the description does not compensate for the schema's gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: configure auto-layout (flexbox) on a frame. The verb 'configure' and the specific resource 'auto-layout' distinguish it from sibling set tools like set_fill, set_stroke, and set_constraints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention that it should be used for flexbox layout instead of set_constraints, nor does it state exclusions (e.g., only applies to frames).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure, but it only states the basic action. It does not mention side effects (e.g., whether children are affected), reversibility, permission requirements, or whether the opacity change is applied immediately. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded with the verb and resource. While it is terse, it is efficiently structured for a simple operation, though it lacks supporting details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter mutation tool with no output schema, the description is still incomplete. It does not specify which node types support opacity, whether the operation is undoable, or how it interacts with fills/strokes. Given the many sibling tools, more context is needed for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must explain parameter meaning. It adds no information about 'nodeId' (which node? what type?) or 'opacity' beyond the schema's min/max constraints. The description does not compensate for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set node opacity' clearly states the action and target resource. It is a specific verb+resource pair, making the primary purpose obvious. However, it does not differentiate from sibling mutation tools like set_visible or set_fill beyond the property name, which is inherent to the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention whether it works on all node types, whether the node must be selected, or any prerequisites. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It fails to mention that the tool is likely read-only, what the output/return format is (e.g., list of issues), or whether it modifies anything. The only disclosed behavior is the types of checks performed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but it is a sentence fragment rather than a complete phrase. It conveys the core action but lacks any structural elements such as a subject or explanatory clauses, which makes it feel terse rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool signature (1 param, no output schema, no annotations), the description is still incomplete. It fails to explain what nodeId refers to, what happens when issues are found (return value, logging, side effects), and any limitations. The description does not sufficiently compensate for the lack of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single parameter 'nodeId' with no description, and schema coverage is 0%. The description does not mention or explain nodeId, so the agent receives no guidance on what this parameter represents or how to fill it. This is a critical gap for a required (even if marked not required) parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Check' and names concrete resources (overlaps, bounds, padding, alignment) that clearly define the tool's validation purpose. It distinguishes itself from sibling tools like figma_check_accessibility, which focuses on a different validation domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. It does not mention whether the tool requires a selected node or how it relates to other layout or validation functions, leaving the usage context entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only says 'Analyze node structure for best codegen strategy,' which implies a read-only operation but does not disclose what the analysis returns, whether it has any side effects, how 'best' is determined, or any error behaviors. Key behavioral information is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It is efficient, but it is also under-specified. The sentence earns its place, but an additional clarifying sentence would not harm conciseness and would improve other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and parameters are undocumented. The description does not explain what the analysis returns, how to interpret results, or how it relates to sibling codegen tools like figma_generate_react. For a tool that likely produces strategic recommendations, this is a significant incompleteness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no parameter information. It does not explain what nodeId refers to or how targetPlatform influences the analysis. The enum values are self-explanatory, but the meaning and impact of the parameters remain entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'analyze' and a clear resource 'node structure' with a defined goal ('best codegen strategy'). It conveys the tool's core function but does not explicitly distinguish it from sibling analysis tools like figma_validate_layout or figma_get_dev_resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: the tool should be used when preparing for code generation. However, there is no explicit mention of when to use it versus alternatives, when not to use it, or any prerequisites. The phrase 'for best codegen strategy' gives context but no actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It does not state whether the clone is inserted into the same parent, whether children are duplicated, whether the new node becomes selected, or any other side effects. 'Optional offset' hints at placement but provides no behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the core action and resource. There is no fluff or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficiently complete. It lacks information about return values, error conditions, offset coordinate semantics, and how the clone relates to the original node.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 4 parameters (nodeId, newName, offsetX, offsetY) with zero description coverage. The description only mentions 'optional offset', which adds minimal meaning for offsetX/offsetY but says nothing about newName or the required nodeId. With 0% schema coverage, the description fails to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Clone a node with optional offset' clearly identifies the action (clone) and resource (node). It distinguishes from siblings by using a unique verb not present in other tool names like 'create' or 'move', though it does not elaborate on what cloning entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as figma_move_node or figma_create_instance. There is no mention of prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the burden of disclosing side effects and behavior. It only asserts capability ('full support') without explaining what creating a component actually does in Figma, such as library implications, required permissions, or default behaviors. This is insufficient for a complex creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. 'Create a reusable component' is immediately clear, and the feature list is compact. All words earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (28 parameters, no annotations, no output schema), the description is grossly incomplete. It omits crucial context such as return value, side effects on existing nodes, prerequisites like parentId requirements, and how component mutability works. The description provides only a surface-level promise of functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 11% schema description coverage and 28 parameters, the description should compensate by explaining parameter semantics. It merely hints at auto-layout, stroke, and children feature areas, but does not clarify any specific parameter formats, defaults, or relationships. The schema already does more for children and colors than the tool description does.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a reusable component' which is a specific verb+resource. The mention of 'full auto-layout, stroke, and nested children support' adds scope and helps differentiate from generic frame or rectangle creation tools, though it could be clearer about component vs instance semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like figma_create_frame or figma_create_rectangle. With many similar creation siblings, the agent gets no context for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It correctly implies a write operation but fails to disclose side effects (e.g., whether it uses current selection, requires page context, or is undoable). The terse statement adds little beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words or repetition. It efficiently conveys the core purpose and distinguishing features.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (27 parameters, no output schema, no annotations), this one-sentence description is insufficient. It doesn't explain return values, default behaviors, or how children objects are structured, leaving the agent to rely heavily on the sparse schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 11%, and the description does not compensate: it mentions auto-layout and stroke features but doesn't map them to the many undocumented parameters (padding, spacing, alignment, etc.). The one sentence provides only a vague hint about capabilities, not parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a frame' clearly identifies the action and target resource, and the added features (auto-layout, stroke, nested children) distinguish it from simple shape-creation siblings like figma_create_rectangle. However, it doesn't explicitly contrast with figma_create_component or figma_create_instance, so it's not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to choose this tool over alternatives among the many sibling creation tools. The description implies it's for frames requiring layout/stroke/children but provides no usage context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'create an instance' without detailing mutational effects, permissions required, failure cases (e.g., invalid componentId), or consequences for the document. The user cannot infer side effects or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the verb, and contains no redundant phrasing. While extremely short, it is not bloated or overly verbose; however, it lacks necessary detail, preventing a perfect score for structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, 0% schema description coverage, no annotations, and no output schema, the description is severely incomplete. It provides only the basic purpose, omitting parameter details, usage context, behavioral nuances, and any return/error information, making it inadequate for an agent to reliably use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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, but it mentions no parameters at all. The required componentId and optional properties (x, y, name, scaleX, scaleY, parentId) are completely unaddressed, offering no semantic meaning beyond the raw schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create an instance of a component' uses a specific verb ('create') and resource ('instance of a component'), clearly distinguishing it from siblings like figma_create_component, which creates a component definition. It precisely states the tool's function without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as whether to use it for placing repeated components in a design, or prerequisites like needing a valid componentId. There is no mention of exclusions or comparison with related creation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It adds the detail 'with base64 data' as a return format hint, but omits side effects, error behavior, or authorization needs. This is insufficient for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. Every word contributes to the core meaning, making it well-structured and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with zero annotations and no output schema, the description is too sparse. It fails to explain how nodeId is determined, what scale does, or how the base64 data is returned, and the lack of differentiation from siblings compounds the incompleteness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain the meaning of scale or nodeId. It only hints at the format enum via 'PNG/SVG/PDF', leaving most parameter semantics ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Export' with a clear resource 'a node' and lists explicit output formats (PNG/SVG/PDF). It conveys the core function effectively, though it does not differentiate from the overlapping sibling figma_export_svg.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like figma_export_svg or figma_export_to_file. There are no selection criteria, prerequisites, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It states the export action but does not clarify whether the operation is read-only, has side effects, or returns data vs. saves a file. The phrase 'raw SVG markup' hints at return content but is not explicit about behavior beyond the operation itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the core purpose without any wasted words. It is appropriately concise for the simplicity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter descriptions, this one-liner is insufficient. It does not explain return value details, fileKey semantics, or provide usage context, making it incomplete for an agent to invoke correctly in varied situations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate by explaining parameters. It aligns 'node' with nodeId but does not mention fileKey or explain how the two parameters relate to the export. The parameter names are intuitive, but the description adds minimal meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Export') and resource ('a node'), and specifies the output as 'raw SVG markup', which distinguishes it from siblings like figma_export_png. However, it does not explicitly differentiate from other export tools or mention alternatives, so it stops 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as figma_export_png or figma_export_to_file. There is no mention of context, prerequisites, or exclusions, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states a read action ('Get') but does not reveal what the version history contains (e.g., timestamps, authors, pagination), any permissions required, or whether the result is a summary or full details. This is minimal and lacks context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single succinct sentence, front-loaded with the main action and resource. There is zero wasted wording, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is incomplete. It does not specify the return format, file scope (e.g., current file vs. any file), or any limitations. The complexity of version history retrieval (e.g., pagination, ordering) is not addressed, leaving the agent with insufficient information to fully leverage the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (fileKey) with 0% description coverage, and the tool description provides no additional meaning. While 'fileKey' is semantically self-evident as a file identifier, the description does not explain how to obtain it or its format. Given the low coverage, the description fails to compensate, though the parameter name helps slightly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Get') and resource ('version history of a file'), distinguishing it from sibling tools like figma_get_file or figma_get_comments. It is unambiguous in intent, though it could be more explicit about the file context or what 'version history' encompasses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention of prerequisites, such as needing a fileKey from another tool, or common use cases, nor any exclusions. The description relies solely on the name to imply usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the action without detailing whether the operation is read-only, if authentication is required, or what the return format looks like. No mention of edge cases like nodes without interactions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It is appropriately sized for a simple getter, though it could include more detail without excessive verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description should explain what 'interactions' means and what the response contains. It does neither, leaving the tool's functionality underspecified for a node-based API.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'nodeId' parameter at all. The only parameter is named but not described, leaving the agent to guess its meaning. The description adds no value beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all interactions on a node' uses a specific verb ('Get') and resource ('interactions') with a clear scope ('on a node'). It distinguishes itself from sibling tools like figma_create_interaction and figma_remove_interactions by indicating a read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as figma_get_flows or figma_get_annotations. It lacks context about typical use cases (e.g., retrieving interactions before editing) and does not mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It states the operation is a 'find' (implying read-only) but provides no details on output format, whether variables are included, or any side effects. The mention of 'components/styles' narrows the result scope but leaves ambiguity about what 'items' covers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no redundant wording. It front-loads the action and resource, making it scannable and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) but has no annotations and no output schema, so the description is the only context. It conveys the core purpose but omits critical details like return format, whether variables/effects are included, and any edge cases or limitations. For an agent to invoke this correctly, more behavioral context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explicitly explain the fileKey parameter. The phrase 'in a file' loosely maps to fileKey, but there is no direct statement that fileKey identifies the file to examine, and no additional context like expected format or constraints. The description adds minimal value beyond the schema's type/name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Find') and the resource ('external library components/styles used in a file'), making the tool's purpose immediately understandable. It doesn't explicitly name sibling tools for differentiation, but the focus on external library usage in a file is distinct from other library-related tools like get_library_collections or get_styles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It implies a read-only analysis use case but does not mention any exclusions, prerequisites, or compare with get_library_collections/get_styles, leaving the agent to guess the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action without mentioning side effects like removal from the old parent, index semantics, or required permissions. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words, and the action is front-loaded. However, it is so brief that it sacrifices necessary detail, though conciseness itself is well-handled.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, no output schema, and three undocumented parameters, the description only captures the high-level operation. It fails to explain the parameters or any behavioral nuances, leaving the agent poorly equipped for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention any parameter. The meanings of nodeId, newParentId, and index are left entirely unspecified, forcing the agent to guess.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Move' with a clear resource 'node to a different parent', immediately conveying the core action. It distinguishes itself from sibling tools like figma_move_node by explicitly focusing on hierarchy change rather than spatial movement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as figma_move_node or figma_group_nodes. The description lacks any context about scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only states the basic action without mentioning side effects, overwriting behavior, or permission requirements. This is inadequate for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler words. It is front-loaded and easy to parse, though it could benefit from additional structured context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the one-sentence description is insufficient. It does not explain return values, batch versus single usage, or any constraints, leaving significant gaps for an agent to operate correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
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. However, it does not explain any of the four parameters (label, nodeId, annotations, labelMarkdown) or the relationship between singular and batch annotation inputs, leaving the schema ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Set' and clearly identifies the resource 'annotation(s)' and target 'node(s)'. It is distinct from sibling tools like figma_get_annotations, making the purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as figma_get_annotations or other mutation tools. There are no mentions of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without disclosing side effects, whether it modifies the frame, requires authentication, or returns anything.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence, no fluff, front-loaded with the action. It is concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a 3-param schema with no parameter descriptions, no output schema, and minimal description, making it under-specified for safe invocation in the context of prototyping flows.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage and the description does not explain the meaning of nodeId, name, or description parameters. The phrase 'on a frame' vaguely hints at nodeId but is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Create') and the resource ('prototype flow starting point') and scopes it to a frame, distinguishing it from sibling tools like figma_create_interaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool instead of alternatives like figma_create_interaction or figma_remove_flow, nor any prerequisites such as needing a frame selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the action 'post' without revealing side effects, permission requirements, or the meaning of the optional x/y coordinates. It also doesn't explain how the comment relates to existing comments or what response to expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no filler words, and it is front-loaded with the primary action. However, it is under-specified in content, which is a trade-off, but for pure conciseness and structure it earns a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and no output schema, the description is incomplete. It fails to specify coordinate semantics, message expectations, or response format. This bare-minimum description leaves significant gaps for an agent to navigate a non-trivial operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema property descriptions are entirely absent (0% coverage), and the description only hints that fileKey and nodeId distinguish file-level vs. node-level comments. It does not explain the x and y coordinates or the required message field, leaving the agent to rely solely on parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'post' and identifies the resource as 'a comment on a file or node', clearly distinguishing this from sibling tools like figma_get_comments (read) and figma_set_annotation (annotation). The scope maps directly to the fileKey and nodeId parameters, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to choose this tool over alternatives (e.g., figma_get_comments) or any prerequisites such as authentication. There is no context about typical scenarios or when posting to a file vs. a node is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'chunking' as a behavior, but does not explain how chunking works, whether the operation is read-only, what happens with large result sets, or what the response contains. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded with the verb and resource. However, it is under-specified, which prevents a perfect score for conciseness since it skips essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no annotations, and no output schema, so the description must provide substantial context. It only states the basic purpose and mentions chunking, but does not describe return values, pagination mechanics, or the role of parentNodeId. This is inadequate for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. 'Chunking' hints at the purpose of chunkSize and chunkIndex, but parentNodeId is left unexplained. The description does not provide enough meaning for the parameters to be used correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Scan') and the target resource ('text nodes'), and mentions a distinguishing feature ('chunking for large pages'). This differentiates it from sibling tools like figma_scan_nodes_by_types, though the exact output or return value is not specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for large pages' implies a use case but does not explicitly state when to use this tool instead of alternatives or provide exclusions. No sibling tools are referenced, so guidance is only implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention that the stroke settings will be replaced, whether alpha is supported, or any side effects. The description only states a basic action, leaving the agent unaware of important behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded and easily parsed. However, it is arguably too sparse, but conciseness rewards efficiency, and this is maximally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with 5 parameters, no annotations, and no output schema. The one-sentence description fails to provide essential context such as default values, behavior when applied to unsupported nodes, or how existing stroke properties are affected. The description is incomplete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, so the description should compensate by explaining key parameters. However, the description mentions no parameters at all. It does not clarify that color is required, nor the meanings of weight, dashPattern, or strokeAlign, beyond what the raw schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set stroke (border) of a node' is a precise verb+resource statement. It clearly identifies the action (setting) and the target (stroke/border), and this inherently distinguishes it from sibling tools like figma_set_fill or figma_set_corner_radius.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of prerequisites, node types that support stroke, or cases where other tools might be more appropriate. The description simply states the function without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. However, 'Show or hide a node' merely restates the tool's name and the boolean parameter, without mentioning side effects, undo behavior, or impact on child nodes. It does not contradict annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is appropriately front-loaded and for a simple tool, brevity is acceptable. However, it is borderline under-specification, which keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is minimal but lacks critical context: no mention of the boolean semantics, how to target the node, or any behavioral expectations. With no annotations or output schema, and 0% parameter coverage, the description is insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. It does not explain that 'visible' is a boolean controlling visibility, nor how 'nodeId' is specified (e.g., path, ID, selection). The parameter names are somewhat self-explanatory but lack explicit detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Show or hide a node' uses a specific verb ('show/hide') and a clear resource ('node'), which precisely states the tool's function. It distinguishes itself from sibling tools like figma_set_opacity or figma_resize_node, which handle different properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. No context is provided about relationships to sibling tools such as figma_set_opacity or figma_set_fill.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 says 'Get existing dev resources,' which implies a read-only operation, but it does not explicitly state that it has no side effects, what permissions are required, or what happens if no dev resources exist. The description adds no details beyond the basic verb and object, failing to disclose important behavioral traits like response format or filtering behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that front-loads the action and resource. There is no fluff, repetition, or unnecessary clauses. It is concise and well-structured for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description needs to supply more context for complete understanding. It does not explain return values, permissions, pagination, or how to interpret 'code links.' The tool's moderate complexity (optional filter) and lack of structured metadata make this description insufficient for an agent to invoke it correctly without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%, so the description should compensate for undocumented parameters. The schema already describes nodeId as a filter, but fileKey has no description. The tool description does not explain either parameter; it only mentions 'attached to nodes in a Figma file,' which weakly maps to fileKey and nodeId but adds no syntactic or semantic detail. This leaves the agent under-informed about required fileKey format or how nodeId interacts with the retrieval.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get existing dev resources (code links) attached to nodes in a Figma file.' It uses a specific verb ('Get'), names the resource (dev resources/code links), and scopes it to nodes in a Figma file. Though it does not explicitly distinguish from siblings like figma_publish_dev_resources, the phrase 'existing' implies a read-only retrieve operation, providing some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: you would call this tool when you need to retrieve code links or dev resources for nodes. However, there is no explicit guidance on when to use this tool versus alternatives (e.g., figma_publish_dev_resources for creating resources), nor any exclusions or prerequisites. The lack of contextual guidance keeps it at a minimum viable level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only reveals that 'text' and 'content' are accepted aliases. It does not mention side effects, defaults, required parent context, or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two sentences front-loaded with the core action. Every word earns its place; there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 18-parameter creation tool with no output schema and no annotations, this description is grossly inadequate. It lacks information about positioning, defaults, return values, and node hierarchy, making it hard for an agent to invoke the tool correctly without additional external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 28%, so the description needed to compensate for undocumented parameters. It adds value by clarifying the 'text'/'content' alias, but it leaves the other 16 parameters entirely unexplained in natural language.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create' and the resource 'text node', which distinguishes it from sibling create tools like figma_create_rectangle or figma_create_line. It is concise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as figma_set_text_content or other create node tools. The usage context is entirely implied by the name and short description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose one key behavioral trait: 'Uses REST API — no plugin required.' This is useful context for the agent. However, it omits other important traits like side effects (it is a create operation), potential failure modes (e.g., duplicate names), or required permissions. The note adds some value but lacks comprehensive behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with two clear parts: the purpose and the note about using REST API. Both elements earn their place, and there is no wasted text. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and lacks critical context. There is no output schema, no annotations, and the description does not explain return values, error conditions, or the semantics of the 'modes' parameter. It provides only the core purpose and one implementation detail, leaving the agent under-informed for execution.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only fileKey has a description). The tool description provides no additional meaning for parameters like 'name' or 'modes'. Given the low coverage, the description was expected to compensate but does not, leaving the agent without sufficient semantic understanding of the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('variable collection') with context ('for design tokens'). It distinguishes from sibling tools like figma_create_variable, which creates an individual variable, by specifying the collection level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description only notes that it uses the REST API and doesn't require a plugin, which is an implementation detail rather than a usage guideline. No exclusions or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only adds 'Uses REST API — no plugin required.' It does not disclose that deletion is likely irreversible, whether contained variables are also deleted, or any permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the primary purpose. The additional REST API note is brief and adds relevant context without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation with no annotations and no output schema, the description is too sparse. It lacks caveats about cascade effects, reversibility, and response behavior, making it incomplete for safe autonomous invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 50%; 'fileKey' has a schema description, but 'collectionId' is undocumented. The description adds no further meaning, such as how to obtain the collection ID or how it differs from a variable ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and object: 'Delete a variable collection.' This distinguishes it from sibling tools like 'figma_delete_variable' and 'figma_create_variable_collection' by specifying the collection-level scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention prerequisites, the relationship to 'delete_variable', or any context for choosing this REST-based tool over a plugin-based operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility. It does not disclose whether the operation is read-only, what the output format is (e.g., JSON string, file), or how it behaves when tokens are missing. It only states the inherent transformation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single well-structured sentence, front-loaded with the action. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 should detail return values, parameter semantics, and usage context. It only provides a high-level statement, omitting critical operational details for a 5-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Parameter schema has 0% description coverage, and the description does not mention any of the five parameters. While names like includeColors are self-explanatory, the description adds no semantic detail about how fileKey relates to design tokens or what each include flag controls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool generates a Tailwind config from Figma design tokens, with specific verb 'Generate' and resource 'Tailwind config', distinguishing it from sibling generation tools like figma_generate_css and figma_generate_tokens.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description lacks any context on prerequisites, such as whether design tokens must be defined in the file or which token types are supported.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Extract' implies a read operation but does not disclose what exactly is returned, whether it is scoped to a file/team, or any permissions needed. Minimal behavioral detail beyond the verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that is front-loaded with the action verb and contains no redundant wording. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a no-param tool, the description does not specify output contents, scope, or what 'rules' encompasses. With no output schema to fall back on, the description is insufficient to fully understand the tool's capabilities, especially given the large number of sibling tools with overlapping functions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is trivially 100%. Per the rubric, 0 params earns a baseline of 4; the description adds nothing about parameters, but none exist to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Extract' with resource 'design system rules' and gives examples (colors, typography, spacing), making the core purpose clear. However, it does not differentiate this tool from sibling tools like figma_get_styles or figma_get_variables, which also retrieve design system elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It only states a general action, leaving the agent unsure whether to pick this over more specific retrieval tools (e.g., figma_get_styles, figma_get_variables) or when a broader 'rules' view is intended.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not describe error handling, node type expectations, or return format. The description is too minimal to provide meaningful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded with the action and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a sparse description, the tool lacks essential context. It does not explain what overrides are, what the function returns, or any prerequisites, making it insufficient for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the tool description does not explain the nodeId parameter. The parameter name is somewhat self-explanatory, but the description adds no semantic value beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with a clear resource 'override properties from a component instance'. It distinguishes itself from the sibling tool 'figma_set_instance_overrides' by clearly indicating a read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that it complements figma_set_instance_overrides or that it is the read counterpart. Usage is only implied by the verb 'Get'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 only states the basic action without disclosing any behavioral traits such as pagination, rate limits, authentication requirements, or whether archived projects are included. As a read operation, safety is implied but not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear, front-loaded sentence. It avoids unnecessary words and precisely conveys the tool's primary function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, no output schema, and no annotations. The description does not mention return format, error scenarios, or any pagination behavior. For a tool that returns a list, the lack of output semantics is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and only describes teamId as a string. The description mentions 'in a team' which implies teamId identifies the team, but it does not explain how to obtain the team ID, its format, or any additional constraints. The description adds minimal meaning beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('projects in a team'), clearly distinguishing from sibling tools like figma_get_team_components or figma_get_project_files. The 'all' qualifier accurately conveys the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as figma_get_project_files or figma_get_team_styles. There is no stated context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 it scrolls, but does not explain whether the selection is replaced, how empty nodeIds are handled, or any side effects on the current viewport or underlying state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and contains no redundant wording. It is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and zero param documentation, the description is too sparse. It omits return behavior, edge cases, and any further context needed to invoke it correctly beyond the basic purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explicitly name or explain the parameters. 'multiple nodes' vaguely maps to nodeIds and 'scroll to show them' to scrollToView, but lacks details like defaults, types, or required status.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Select') and resource ('multiple nodes'), and adds the scrolling behavior, clearly distinguishing this setter from sibling 'get_selection'. It is concise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'figma_get_selection' or 'figma_set_focus'. The description does not mention exclusions, prerequisites, or comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does disclose the key override rule: 'Any explicit property overrides the preset.' However, it does not mention the operation's mutating nature, possible error conditions, or what happens when only nodeId is provided without any style properties. Thus, it adds some value but not comprehensive transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action. The presets list and examples are directly useful, though the presets list duplicates the schema enum. Overall, every sentence earns its place with minimal redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 11 parameters, no annotations, and no output schema, yet the description is thin on broader context. It does not mention that the node must be a text node, what the tool returns on success, or error behaviors. The examples are helpful but insufficient for fully understanding the tool's behavior in all usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 18% (preset and fillColor have descriptions). The description compensates somewhat by explaining the preset-override interaction and providing examples for fontSize and fontWeight. However, it does not clarify units or allowed values for custom properties like fontSize or lineHeight, leaving many parameters underdocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'Set text style with presets or custom values.' It includes a list of presets and usage examples that clarify the intended functionality. However, it does not explicitly distinguish from sibling tools like figma_set_text_content, which would make the differentiation even stronger.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It implies it is for setting text style, but does not mention exclusions or refer to siblings such as figma_set_text_content for content changes. Given the large sibling list, the lack of usage direction is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the burden. It discloses the optional switch behavior, but lacks details on permissions, side effects, defaults (e.g., switchTo defaults to true), or behavior when the page name already exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no wasted words, front-loaded with the core action. It is appropriately sized for a simple tool, though it omits parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no output schema, the description lacks essential parameter semantics and default behavior. The agent is left to infer from the schema property names, but the description does not assist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not mention parameters. The 'Optionally switch to it' hint relates to switchTo but gives no parameter names, defaults, or meaning for 'name'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Create a new page' with a specific verb and resource, and the optional switch behavior distinguishes it from sibling tools like figma_switch_page.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs. alternatives; the description relies on implied usage from the name and the optional switch note. No exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 batch capability ('one or more') but does not mention that deletion is likely permanent, does not discuss impact on child nodes, undo behavior, or any permissions needed. The description is minimal and lacks safety context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short, unambiguous sentence with no filler or redundancy. It earns its place by stating the core purpose effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations, no output schema, and only two simple parameters, the description is under-specified. It does not mention the destructive nature, return value, or any side effects. For a mutation 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds the meaning that the operation supports one or more nodes, implying that nodeId is for a single node and nodeIds for multiple. However, it does not clarify the exact relationship between the two parameters, whether they are mutually exclusive, or if at least one is required. Schema coverage is 0%, so the description partially compensates but remains vague.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('nodes'), and explicitly notes that it supports 'one or more', which distinguishes it from single-node deletion tools. The verb is specific and the resource is unambiguous, making the purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, whether it affects the current file or selection, or any exclusion criteria. There is no comparison with sibling tools like rename_node or move_node.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Generate CSS from a node's styles' and does not state whether the operation is read-only, what output format is returned, whether it creates files, or any side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no waste or fluff, and the core action is front-loaded. However, given the four-parameter schema and absence of other contextual details, it may be too terse to be fully effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has four parameters, no output schema, and no annotations, yet the description adds minimal contextual information beyond the core action. It doesn't explain how parameters affect output, what the return value looks like, or when this tool is preferable to sibling generators.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not compensate. 'A node's styles' weakly implies the role of nodeId, but the remaining parameters (useVariables, classNamePrefix, includeChildren) are completely unexplained, leaving their semantics entirely to the schema's bare type names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Generate CSS') and a specific resource ('a node's styles'). It clearly distinguishes this tool from sibling code-generation tools like figma_generate_html, figma_generate_react, and figma_generate_tailwind_config by its output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when CSS output is desired, but it provides no explicit guidance about when to choose it over alternatives, no exclusions, and no mention of prerequisites. It is serviceable but leaves the comparison to siblings implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic retrieval action and scope, but does not disclose return format, pagination, potential errors, or whether annotations include metadata or comments. This is minimal transparency for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that wastes no words. It clearly communicates the tool's purpose and scope without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description is minimally adequate. It explains the primary use case and parameter semantics, but lacks details on return value structure, error behavior, or edge cases. For a retrieval tool with no output schema, the description should provide more information about what the caller receives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter, nodeId, with no description (0% coverage). The description compensates by explaining that annotations can be retrieved for a specific node or, by omitting nodeId, the whole document. This adds meaningful context about the parameter's optionality and effect, though it does not specify the expected ID format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('annotations'), and specifies the scope ('on a node or the whole document'). This distinguishes it from sibling tools like figma_set_annotation, which performs the opposite operation. However, it does not explicitly differentiate from figma_get_comments, which could be a similar retrieval function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It implies use for retrieving annotations, but does not mention exclusions, prerequisites, or when to prefer figma_get_comments or figma_set_annotation. The scope statement ('on a node or the whole document') gives some context, but no direct comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the operation ('list all files') but provides no details on return format, pagination, error behavior, or auth requirements. This is insufficient for a tool without schema or annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It is appropriately sized for the simplicity of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema and minimal description, the agent cannot know what 'files' includes (e.g., file IDs, names, types) or whether results are paginated. A more complete description would mention return structure or limits, especially given the large sibling toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter projectId is self-explanatory from the schema and tool name, but the description adds no additional meaning (e.g., format or usage context). Since schema coverage is 0%, the description does not compensate, but the parameter's purpose is clear enough to warrant a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all files in a project' uses a specific verb 'List' and clearly identifies the resource (files) and scope (project). It distinguishes from siblings like figma_get_file (single file) and figma_get_team_projects (list projects), making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention relationships to related tools such as figma_get_file or figma_get_team_projects, or any prerequisites 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It conveys that only 'published' styles are returned and that they are scoped to a team, but it omits details such as pagination behavior, return format, or whether unpublished/team-private styles are excluded beyond the 'published' qualifier.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, deliberately worded sentence with no filler. It is front-loaded with the action and object, and every word adds meaning. While it is terse, this dimension rewards appropriate minimalism without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 2 parameters, no output schema, and no annotations, yet the description provides only a high-level phrase. It lacks usage guidance, parameter semantics, and any indication of what the returned styles look like or how pagination works. This is inadequate for an agent to select and invoke the tool confidently, especially given many sibling style-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not compensate. It does not mention 'teamId' or 'pageSize', nor explain that pageSize controls pagination. The only implicit clue is 'from a team' hinting at teamId, but this is insufficient given two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('published styles from a team'), clearly indicating the tool's scope. It distinguishes itself from sibling tools like figma_get_styles by specifying 'from a team', though it does not explicitly contrast with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'from a team' implies the tool is for team-level style retrieval, providing context on when to use it. However, it does not explicitly state when not to use it or mention alternatives such as file-level get_styles, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention that removing all interactions is destructive, whether it is reversible, if it affects connected flows/prototypes, or if any permissions are required. The word 'Remove' implies mutation, but safety-related context is entirely absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. It is appropriately concise for a simple tool with one parameter, communicating the core action immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is minimally viable: it states the action and target. However, it omits any caveats about destructive side effects, reversibility, or relationship to other interaction-related tools, leaving the agent without important operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema lists a single parameter `nodeId` with no description, and the tool description does not explain it either. With schema description coverage at 0%, the description fails to compensate by clarifying what `nodeId` refers to or how it should be formatted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Remove') and resource ('all interactions from a node'), clearly distinguishing it from sibling tools like `figma_create_interaction` or `figma_get_interactions`. It unambiguously states the scope (all interactions) and target (a node).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. While the purpose is clear, the agent is left to infer context (e.g., when a node has interactions to remove).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It mentions the prerequisite of a plugin connection and the two input modes, but it does not disclose the mutation side effects (e.g., replacing or merging styles), failure behavior, or any permissions needed. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and followed by brief usage instructions. Every sentence imparts useful information with no filler, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description covers the main usage pattern but omits important contextual details such as what constitutes a successful operation, error handling, or behavior when both styleId and styleName are provided. It is adequate as a minimum viable description but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so most parameters already have descriptive schema entries. The description adds value by clarifying the mutual exclusivity of styleId and styleName, but it does not elaborate on the required property parameter when using styleId. The schema already handles this, so the extra semantic contribution is limited.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Apply a style to a node by ID or by name.' This identifies the specific verb ('apply') and resource ('style to a node'). However, it does not explicitly distinguish this tool from siblings like figma_set_fill or figma_set_stroke, though the concept of applying a whole style is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage context by explaining the two mechanisms ('Provide styleId to apply by ID, or styleName to apply by name') and notes a prerequisite ('Requires plugin connection'). It does not mention when to avoid this tool in favor of alternatives or any exclusions, so the guidance 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of disclosing behavioral traits. It only mentions that the request is batched, but offers no details about read-only safety, potential request limits, response behavior, or other side effects. This is minimal beyond the name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences that are front-loaded with the core purpose. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is incomplete. It doesn't mention return values, node limits, or parameter details. While the tool is conceptually simple, the sparse description leaves too many gaps for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description provides no explanation of the parameters (fileKey, nodeIds, depth). With such low schema coverage, the description must compensate, but it offers nothing, leaving parameter semantics entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Get multiple nodes in one request', clearly identifying the action and resource. It also distinguishes itself from the sibling tool figma_get_node by calling itself a 'Batch alternative', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Batch alternative to get_node' gives clear context that this tool is for fetching multiple nodes in a single request, implying the alternative is to call get_node repeatedly. However, it lacks explicit exclusions or when-not-to-use guidance, so it doesn't fully reach a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. 'Get' implies read-only, and 'published style' adds a resource constraint. However, it doesn't disclose return format, error behavior, or any permissions. It's minimally transparent but not full.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word adds value: 'Get', 'published', 'style', 'by key'. It's appropriately concise for a simple read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter, the description is adequate, but there is no output schema, no annotations, and no context about return values or distinctions from sibling tools. It leaves significant gaps for an agent to infer behavior, especially compared to related tools like figma_get_styles.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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. It tells the agent that the style is fetched by a key, which maps to the styleKey parameter, but it doesn't explain the key's format, how to obtain it, or constraints. The parameter name itself carries most of the meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), a clear resource ('published style'), and a qualifier ('by key'). It distinguishes from siblings like figma_get_styles (plural) and figma_import_style_by_key (imports vs gets).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as figma_get_styles or figma_import_style_by_key. The only implication is from the singular/plural naming, which isn't in the description. There are no exclusions or contextual cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden of behavioral disclosure. It adds that only 'published' components are returned and that a premium plan is required. However, it omits pagination behavior, return format, and any other side effects or limitations, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence plus a plan requirement, with zero fluff. It is front-loaded and every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple 2-parameter tool, the description is underspecified. It does not explain what the response contains, how pagination works, or provide any usage context beyond the plan requirement. Sibling tools with similar scopes likely have richer descriptions, so this one lacks completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the description does not explain teamId or pageSize. There is no mention of ID formats, defaults, or how pageSize affects results. The description adds no meaning beyond the parameter names themselves.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get published components from a team' clearly states the action (get), resource (published components), and scope (team), which distinguishes it from sibling tools like figma_get_components (file/global) and figma_get_team_styles (styles). It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite ('Requires Organization or Enterprise plan') but provides no explicit guidance on when to use this tool versus alternatives like figma_get_components or figma_get_team_styles. The plan requirement implies premium-only contexts, but there is no direct comparison or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. 'Remove a flow starting point' indicates mutation, but it does not explain side effects, idempotency, or what happens if the flow starting point does not exist. The description adds minimal behavioral context beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the tool's purpose. It is appropriately sized and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations, no output schema, and an unexplained parameter, the description is too sparse. It does not clarify what constitutes a 'flow starting point', how nodeId should be determined, or what the result of the removal is, making it insufficient for an agent to reliably invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, nodeId, with no description, and the description provides no additional meaning. It is unclear whether nodeId refers to the frame containing the flow or the flow starting point node itself. With 0% schema description coverage, the description fails to compensate, leaving the parameter ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Remove'), the resource ('flow starting point'), and the location ('from a frame'). This distinguishes it from sibling tools like figma_create_flow and figma_get_flows, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: it should be used when a flow starting point needs to be removed from a frame. However, it provides no explicit guidance on when not to use it or how it differs from related tools like figma_remove_interactions or figma_delete_node.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for disclosing side effects. It mentions 'select' (implying selection changes) but omits behavior around zoomLevel, error handling, validation of nodeId, or whether the viewport scroll is animated. The lack of any context about side effects or prerequisites is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded and directly states the action. This is an example of efficient, minimal prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool, the description covers the primary action, but it omits the zoomLevel parameter entirely and provides no usage context or prerequisites. With no annotations and no output schema, the description leaves too much unanswered for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate. It references 'a node' but does not explain that nodeId identifies the node or what zoomLevel does. The parameter names are self-descriptive to some extent, but no additional meaning is added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs 'select' and 'scroll viewport' to identify the action and target. It clearly distinguishes from sibling tools like figma_set_selections (which only selects) and figma_get_viewport (which only reads the viewport).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case—when you need to bring a node into view and select it—but provides no explicit guidance on when to prefer this over alternatives like figma_set_selections or figma_get_viewport. No exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states that scrolling is configured, without detailing side effects, dependencies (e.g., frame must be in a prototype), or whether changes are reversible. This is a minimal disclosure for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It efficiently states the tool's purpose in eight words, earning a top score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four parameters, including a nested scrollOffset object, no output schema, and no annotations, the description is too brief. It omits details about scrollDirection, scrollOffset, required parameters, or expected behavior, leaving significant gaps for an agent trying to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description does not explain any of the four parameters. While the phrase 'scrolling for a frame' hints that nodeId refers to a frame and scrollBehavior is central, it adds little semantic value beyond the schema's enums and property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Configure') and a clear resource ('scrolling for a frame in prototypes'), which clearly conveys what the tool does. It also distinguishes itself from sibling tools like figma_set_default_transition or figma_setup_overlay by focusing specifically on scroll behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when scrolling needs to be configured for a prototype frame, but it does not explicitly state when to use it over alternatives or mention any prerequisites or exclusions. Usage context is clear but not fully elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It does not mention side effects such as viewport changes, selection impact, or error behavior when a page is not found. Only the basic action is stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-front-loaded sentence with no unnecessary words, making it maximally concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple, the description lacks usage context, parameter interaction rules, and behavioral details. For a tool with three optional parameters and no annotations or output schema, this minimal explanation is adequate but leaves ambiguities that could affect correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description maps the parameters to 'name, ID, or index', which aligns with the schema property names and gives basic semantics. However, it does not clarify precedence when multiple parameters are supplied, whether they are mutually exclusive, or constraints on the index value, which is a gap given the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'switch' with the resource 'page' and clearly lists the three identification methods (name, ID, or index), making the tool's purpose unambiguous and distinct from sibling tools like create_page or get_viewport.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It is a bare statement without contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. 'Delete' clearly signals destructive action, but there is no disclosure of permanence, permissions, or side effects on bound variables. Minimal beyond the verb itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action. The extra note about REST API/no plugin is useful and non-redundant, every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter delete tool, the description covers the basic action and execution mode. However, it omits parameter semantics for variableId and any warning about irreversibility, leaving minor but notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: fileKey is described but variableId is not. The description adds no parameter details, leaving the agent to guess the expected format or source of variableId. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Delete' and resource 'variable', clearly distinguishing it from sibling tools like delete_variable_collection or update_variable. The action and target are unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Delete a variable' implies when to use it, and 'Uses REST API — no plugin required' gives context about execution environment. However, there is no explicit guidance on when not to use it or how it differs from related delete/update variable tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds useful detail about batch support and aliases, but it does not disclose whether the entire text is replaced, what happens with multiple updates, whether special permissions are needed, or any error/edge-case behavior. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, with the main purpose front-loaded. It conveys key information (single vs. batch, alias handling) without any filler, earning its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 must explain behavior, return values, and parameter relationships. It fails to clarify that nodeId is technically optional at the top level (for single updates) but required inside each updates item, nor does it state what the tool returns or how batches behave on partial failure. The description is adequate only for a very simple mental model, leaving important gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with text and content having descriptions, but nodeId and updates having none. The description compensates somewhat by explaining the 'text'/'content' alias and noting that batch updates are via the updates array, but it does not clarify nodeId's role or the structure of updates beyond the schema. The added value moves it above baseline but not enough to fully cover the missing schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Update text content.' The verb 'update' plus the resource 'text content' makes the action specific. It also distinguishes itself from siblings like figma_set_text_style and figma_create_text by focusing on content modification, and mentions batch capability via the updates array.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to set text on an existing node, and mentions batch support, but it does not explicitly compare to alternatives like figma_set_text_style or state when not to use this tool. There is no 'when-to-use' or 'use instead of' guidance, relying on the reader to infer from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral details. It only mentions the transport method (REST API, no plugin) and omits important aspects like whether the update merges with existing properties, permission requirements, or side effects. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy. It efficiently conveys the main action and a key implementation detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and low schema coverage, this description is too sparse. It does not mention return values, error conditions, or operational constraints, which an agent would need for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 20% (fileKey has a description); the description adds meaning for three parameters by listing 'name, description, scopes'. However, it does not explain the scopes array contents or the variableId parameter, leaving required fields under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Update'), target ('variable'), and affected properties ('name, description, scopes'), distinguishing it from variable creation or value-setting tools like figma_create_variable and figma_set_variable_value. The REST API note adds useful context about how the operation is performed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies usage when updating variable metadata but does not explicitly state when to prefer this over sibling tools such as figma_set_variable_value. The description lacks alternative guidance or exclusions, leaving the agent to infer from the property list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions support for SVG elements and gradients, but omits critical behaviors such as how width/height resizing affects aspect ratio, error handling for invalid SVG, return values, and relationship to parentId. This is similar to the update_drive example, which scored 2 for lacking permissions, reversibility, and response details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: purpose, use case, and supported features. There is no fluff, redundancy, or repetition of schema details, making it appropriately concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no annotations, and no output schema, the description is underequipped. It provides the core purpose and use case but omits essential operational context like how x/y position the node, how width/height interplay with aspect ratio, and what happens when parentId is absent. The agent must infer too much to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 43%, and the description adds no additional meaning for the undocumented parameters. The svg parameter is already described with an example in the schema, but x, y, name, and parentId lack elaboration. The description doesn't compensate for the coverage gap, leaving the agent to rely solely on defaults and field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('vector node from raw SVG markup') to clearly state what the tool does. It explicitly distinguishes from simple shape tools by mentioning charts, icons, curves, and shapes that can't be made with rectangles/ellipses/lines, aligning with sibling tools like figma_create_rectangle and figma_create_ellipse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use this for charts, icons, curves, and any complex shapes that can't be made with rectangles/ellipses/lines,' providing clear when-to-use context and an exclusion criterion. It doesn't explicitly name alternative tools for simple shapes, but the contrast is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but only says 'Get,' implying a read operation. It does not clarify what 'enabled' means, whether the operation is scoped to a specific library or file, or what the returned collections contain. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the verb and resource. Every word earns its place; no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless getter, the description is minimally viable but lacks context about what a 'library variable collection' is, what 'enabled' means, or the shape of the output. Without an output schema, the description should offer more detail to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description adds no parameter details, but none are needed; the resource is fully specified by the tool name and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and identifies a distinct resource: 'enabled library variable collections.' This clearly distinguishes it from sibling tools like figma_get_library_variables (which returns variables, not collections) and figma_get_variables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as figma_get_library_variables or figma_get_variables. The description implies a use case but does not state exclusions or propose alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers minimal behavioral disclosure beyond the read action. It mentions token usage reduction but does not describe pagination, auth requirements, or error behavior, leaving the agent to infer operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundancy; the first states the core function, the second offers practical filter advice. Every word earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple read operation, but with no annotations and no output schema, the description should cover return format or pagination. It only hints at token usage reduction and does not explain what the response looks like, so it is adequate but not fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents limit, namePattern, and resolvedType with descriptions (75% coverage). The description adds the rationale for filtering to reduce token usage, which is useful, but it does not clarify collectionKey further or add formatting details beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves variables from a library collection by key, using the specific verb 'Get' and the resource 'variables from a library collection by key'. This distinguishes it from sibling tools like figma_get_variables or figma_get_library_collections.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a collection key and want to filter variables, with the added note about reducing token usage. However, it does not explicitly compare to alternatives such as figma_get_variables or explain when not to use this tool, so guidance is present but not fully developed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It mentions 'Uses REST API' as a technical detail but does not disclose whether the operation overwrites existing values, requires specific permissions, or is reversible. A mutation tool with zero annotation coverage should provide more context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action, and every sentence adds useful information. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations, no output schema, and a critical undocumented parameter ('value'), the description is insufficient. It does not explain return values, error handling, or the format of the value to set, leaving a significant gap in operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (modeId, fileKey, variableId have descriptions), but the 'value' parameter—the core of the operation—lacks both schema and description-level explanation. The description helps with modeId by pointing to figma_get_variables, but leaves 'value' semantics unresolved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set variable value') and the specific scope ('for a mode'), making it distinct from sibling tools like figma_update_variable or figma_bind_variable. The wording is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: 'Uses REST API — no plugin required' tells the agent when this tool is appropriate (when plugining is not wanted), and 'Use mode ID (get from figma_get_variables)' gives a prerequisite. However, it does not explicitly list alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states what is checked but does not disclose whether the operation is read-only (likely but not explicit), what response format to expect, or any potential side effects. The minimal wording adds little beyond a high-level action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates the core function without any superfluous words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no inputs, no output schema), and the description covers the essential action. However, it does not describe what the response contains or how statuses are represented, so there is a small gap in completeness for an agent needing to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty schema, so the description cannot add parameter-level meaning. The baseline of 4 for 0-parameter tools applies, as there is nothing to explain that the schema doesn't already cover.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Check' and names three concrete resources: server, bridge, and REST API status. This clearly distinguishes it from sibling tools that perform Figma document operations, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus any alternative, nor are any prerequisites or exclusions mentioned. The description implies a diagnostic role but does not explicitly state contexts where this should be invoked.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses the plugin bridge mechanism, REST API fallback, and the fact that it writes to a local path, but it omits potential failure modes (e.g., when neither plugin connection nor fileKey is available), file overwrite behavior, and return semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose sentence, followed by concise supporting details (formats, plugin bridge/REST behavior) and helpful examples. It is slightly longer due to examples, but every sentence adds useful implementation context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description plus schema supports basic invocation: required params are clear, optional params are exemplified, and plugin/REST behavior is stated. However, with no annotations and no output schema, it leaves out return values, failure conditions, and a fully explicit precondition for when the plugin bridge vs REST path applies, making it minimally viable rather than complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 60%, and the description partially compensates with an explicit format list and examples showing format and scale usage. However, it does not explain the meaning of scale beyond schema constraints and does not demonstrate fileKey usage, leaving some gaps beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it exports a Figma node as an image file saved to a local path, names a specific verb and resource, and lists supported formats (PNG, JPG, SVG, PDF). This distinguishes it from sibling tools like figma_export_png and figma_export_svg by emphasizing local file output and multi-format support.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context about plugin bridge vs REST API fallback and when fileKey is needed, but it does not explicitly compare this tool with alternatives such as figma_export_png or figma_export_svg. It implies usage for file-based exports but lacks clear when-not or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It discloses key behavioral traits: it returns step-by-step instructions rather than directly creating annotations, and it requires a plugin connection for creating annotation nodes. However, it does not clarify whether the operation is read-only, what the instruction format looks like, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences, front-loads the purpose, and each sentence adds useful information (purpose, sections, plugin requirement). There is minimal redundancy, though the line break after the first sentence slightly interrupts flow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters and no output schema, the description explains the core behavior and prerequisites. However, it leaves gaps around the exact format of the returned instructions, how to handle invalid node IDs, and any limitations or error cases, making it moderately complete but not fully robust.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers both parameters with clear descriptions and 100% coverage. The description enumerates the available sections, but this duplicates the schema enum without adding new semantic meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Generate a visual design handoff spec annotation in Figma', which clearly states the verb (generate) and resource (handoff spec annotation). This distinguishes it from sibling tools like figma_generate_css and figma_set_annotation by focusing on the handoff spec use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating it returns step-by-step instructions to follow, and lists available sections. However, it does not explicitly state when to use this tool versus alternatives, such as when code generation is needed, and no exclusions are given beyond the plugin requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool can consume tokens and that filtering reduces usage, which is a useful behavioral hint. However, it omits other behavioral details such as pagination limits, whether includeValues defaults to true, and the lack of side effects. This is minimal but non-tautological.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and immediately front-loads the core purpose. Every sentence adds value: the first states what it does, the second advises on usage. There is no wasted words or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 parameters, no output schema, and no annotations, the description is too sparse. It explains the basic purpose and token-saving filter, but does not cover important context like the relationship between variables and collections, default behavior of includeValues, or how it differs from library-related siblings. The mention of 'design tokens' helps, but overall it is incomplete for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 80% of parameters with descriptions. The description adds a link between filtering and token reduction, which adds meaning beyond the raw parameter names. However, it does not mention the 'limit' or 'includeValues' parameters, leaving some context to the schema. Given the high schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the primary function: 'Get local variables and collections (design tokens).' The verb 'Get' with the specific resource 'local variables and collections' is unambiguous, and the qualifier 'local' distinguishes it from sibling tools like figma_get_library_variables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction to 'Filter by type or name to reduce token usage' provides useful context for using filters but does not explicitly mention when to prefer this tool over alternatives or any exclusions. The concept of 'local' is implied but not compared to sibling library-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only provides input examples. It omits critical behavior such as whether calling this replaces existing fills on the node, any required permissions, or potential side effects. The 'set' verb implies replacement but this is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear opening statement followed by four short example snippets. Each line serves a purpose, and the format makes it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema and no annotations, the description leaves out important context: it does not state what response to expect (e.g., success/failure), whether existing fills are replaced, or any prerequisites (e.g., node must be a frame). The examples cover input shapes but not the full context needed for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, leaving some parameters under-documented. The description compensates with concrete examples for solid, gradient, and image fills, clarifying complex structures like gradientStops and imageUrl. It also explicitly mentions that the fills array can contain multiple items.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set fill of a node' and lists supported fill types (solid, gradients, images). This specific verb+resource combination distinguishes it from sibling tools like figma_set_stroke and figma_set_opacity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Examples imply usage for setting fills on nodes, and differentiate from other set_* tools by focusing on fill. However, there is no explicit when-to-use guidance, when-not-to-use, or mention of alternatives beyond the existence of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the plugin requirement and REST unavailability, but does not mention side effects, permissions, reversibility, or failure behavior. For a mutation tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action followed by a necessary prerequisite. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is brief and provides the essential action and a key constraint, but lacks details about return values, the meaning of 'property', and any side effects. Given no output schema and no annotations, the description alone may not fully prepare an agent for invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-level information. Schema coverage is 75% (three of four properties documented), so baseline is 3. However, the required 'property' parameter is undocumented in both schema and description, leaving a notable semantic gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Bind a variable to a node property' with a specific verb and resource. It distinguishes itself from sibling tools like figma_set_variable_value by focusing on binding rather than setting values. The plugin connection requirement further clarifies its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the prerequisite: 'Requires plugin connection' and excludes REST usage ('no REST endpoint for this'). This provides clear context for when the tool can be used, though it does not name alternative tools or explicit when-not scenarios beyond the REST exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It adds meaningful context by explaining what each source returns and the environment (REST vs. plugin), but it doesn't disclose output shape, required parameters like fileKey for source=file, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core action and efficiently packs the three source variants. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with no output schema, the source semantics are well-covered, but the fileKey parameter is omitted and there is no indication of what return data looks like. Additional detail on required fields per source would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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. It does explain each enum value for 'source' effectively, but 'fileKey' is entirely undocumented, leaving a gap in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb+resource ('Get components') and then elaborates on three distinct source modes, making the tool's scope clear. While it doesn't explicitly contrast with siblings like figma_get_team_components, the source breakdown provides enough differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete usage contexts for each source: file for REST published components, local for the current page in a plugin, and library for discovered instances on canvas. This tells the agent when to select a particular source mode, though it omits explicit alternatives or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
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 key behavioral difference between REST file styles and plugin local styles, which is valuable. However, it does not mention read-only nature, return format, or potential errors, leaving notable transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: 'Get styles. fileKey→REST file styles, omit→plugin local styles.' It front-loads the purpose and communicates parameter behavior in a compact, scannable format with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool, the description covers the essential behavioral distinction and gives sufficient context for invocation. It does not explain return values, but the name 'get_styles' implies a list, and there is no output schema to fill that gap. Overall, it is reasonably complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
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. It clearly explains the meaning and effect of the fileKey parameter: providing it fetches REST file styles, omitting it returns plugin local styles. This adds meaningful semantic content beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'get' and resource 'styles', and clarifies two modes based on fileKey, which helps distinguish from siblings like get_style and get_team_styles. However, 'styles' is somewhat ambiguous without specifying paint/text/effect styles, so it's not fully clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context on parameter behavior (fileKey→REST file styles, omit→plugin local styles), but does not explicitly state when to use this tool over alternatives like get_style or get_team_styles. Usage is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It indicates mutation ('become available locally') and batch support, but does not mention potential side effects, permission requirements, reversibility, or return behavior. For an import tool that modifies local state, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the core purpose. Each sentence contributes unique information (what/why, prerequisite, batch support, follow-up action). No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple (2 params, no output schema, no annotations), and the description covers the workflow well. However, it omits any information about return values or error conditions, which is important for a tool that modifies local state. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema: it mentions batch support via styleKeys, but the schema already describes that parameter as 'Array of style keys to import (batch)'. It also suggests a method for finding keys, but this is more contextual than parameter-specific.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Import library styles by key'), the resource (library styles), and the resulting state ('become available locally'). It distinguishes itself from sibling tools like figma_get_styles (read-only) and figma_apply_style (applies styles), and from figma_import_component_by_key by focusing specifically on styles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 import styles by key, with a prerequisite step (find keys using figma_get_styles) and a follow-up step (apply with figma_apply_style). It does not explicitly state when not to use it or mention alternatives, but the workflow context is strong enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions support for straight lines and smooth Catmull-Rom curves, and examples illustrate closure and colors, but it does not disclose details about node creation context, return values, or side effects beyond the obvious 'Create' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: the first sentence states purpose, the second provides comparison, and the examples add practical context. It is concise enough for the tool's complexity without unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 10 parameters and no output schema or annotations, the description provides a good starting point with examples but omits return value information and leaves several parameters unexplained (e.g., parentId, name, strokeWeight). It is adequate but not comprehensive for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 50% of parameters, and the description adds meaning through concrete examples showing how to use points, curveType, closed, fillColor, and strokeColor. However, it does not explain parameters like name, parentId, strokeWeight, or the top-level x/y, relying on the schema partially.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a vector path from points, with a specific verb ('Create') and resource ('vector path from points'). It distinguishes itself from sibling 'create_from_svg' by noting it is 'Much simpler for charts, curves, and shapes,' providing clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context that this tool is preferable to create_from_svg for charts, curves, and shapes, guiding the agent on when to choose it. However, it does not explicitly state when to use create_from_svg instead, so it lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden for behavioral disclosure. It discloses the default depth behavior and that it returns a tree, but it does not mention authentication requirements, whether it is a read-only operation, or any response characteristics. This is acceptable for a 'get' tool but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the primary purpose. Every phrase contributes meaning: the default depth, the option for deeper traversal, and the sibling alternative. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and depth parameter, but the presence of a nodeId parameter is unexplained, creating ambiguity about whether this tool can already target subtrees. There is no output schema, so the return format ('tree') is described only at a high level. Adequate for a simple get operation but with notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only depth is described). The description adds some context for depth but mostly restates schema information. It does not explain the nodeId parameter, which is critical given the tool's relationship to figma_get_node, nor does it clarify fileKey beyond its name. The description fails to compensate for the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a file document tree, with a specific default depth. It also distinguishes itself from the sibling figma_get_node by directing users there for specific subtrees, making its scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on depth usage ('Defaults to depth=2... Set higher depth') and explicitly names an alternative (figma_get_node) for subtree traversal. It stops short of saying when not to use this tool under other conditions, but the coverage is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses dependencies (plugin connection, codebase path), the fuzzy matching algorithm, and a warning to review results. However, it does not state whether the operation is read-only, describe any side effects, or outline error conditions. This gives some insight but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences that front-load the purpose, state prerequisites, and summarize the output and a safety caveat. Every sentence adds meaningful information with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, no output schema), the description covers the core aspects: what it does, required dependencies, and the main output (mapping with confidence scores). Minor gaps remain, such as not specifying the structure of the mapping or behavior when no matches are found, but it is largely complete for an AI agent to understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for 3 of 4 parameters (fileKey, codebasePath, minConfidence), giving 75% coverage. The description adds no parameter-specific details beyond what the schema provides, such as how frameworks or minConfidence influence the matching. It mentions codebasePath and plugin connection, but these are already in the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Match Figma components to codebase components using fuzzy name matching.' This is a specific verb (match), resource (Figma components to codebase components), and method (fuzzy name matching). It distinguishes from sibling tools like figma_scan_codebase or figma_get_components by focusing on the matching capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides prerequisites: 'Requires plugin connection for Figma scanning, and a codebase path for code scanning.' It also advises 'Review before publishing.' However, it does not explicitly state when to use this tool over alternatives or mention any exclusions, so usage guidance is only 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. The verb 'Get' signals a read operation, but the description does not explicitly state that it is non-destructive, what it returns (e.g., node objects vs. IDs), or behavior when nothing is selected. It provides minimal but not rich 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It states the action and target clearly, earning its place entirely. This is appropriately sized for a zero-parameter read tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description is largely complete. It could add a note about return format or empty selection behavior, but for a straightforward getter, the current text is sufficient. Sibling tools are numerous, but the name and description are self-explanatory.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema has 100% coverage trivially. Per the calibration baseline for 0 params, the score is 4. There are no parameter semantics to explain, and the description adds no misleading information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get currently selected nodes' uses a specific verb ('Get') and clearly identifies the resource ('currently selected nodes'). It distinguishes itself from siblings like figma_get_node (fetches by ID) and figma_get_nodes (fetches multiple by ID) by referencing the live selection context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the current selection is needed but provides no explicit guidance on when to use this tool versus alternatives like figma_get_node or figma_get_viewport. There are no exclusions or alternative tool references, so the usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The verb 'Get' implies a read-only operation with no side effects, but the description does not explicitly confirm non-mutating behavior or mention any prerequisites (e.g., an open file) or return format details beyond the listed attributes. It is minimally adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single, front-loaded sentence that conveys all necessary information about the tool's function. No wasted words, perfectly structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is reasonably complete for a simple getter. It lists the output attributes, but it does not explain the coordinate system or units for position/visible bounds, nor does it clarify that 'viewport' refers to the active view in the editor. Slight ambiguity prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters, so the baseline score is 4 per the rubric. The description adds value by specifying what the tool returns (position, zoom, visible bounds), which provides meaningful context beyond the empty schema, even though there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource 'viewport' plus the exact data returned (position, zoom, visible bounds). This clearly distinguishes it from other getter tools like get_selection or get_node, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need the current viewport state, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. For a simple getter, the implied usage is adequate but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral burden. It discloses the side effect: 'Attaches code file URLs to component nodes' and 'links will appear in Figma's Dev Mode panel.' However, it does not mention whether existing links are overwritten, what permissions are required, or what the tool returns, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences cover the core action, the prerequisite workflow, and the observable result. There is no fluff or redundant repetition of schema details. Front-loaded with the main verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no nested objects, no output schema), and the description covers purpose, usage order, and visible effect. It could mention error/overwrite behavior or read-back confirmation, but given the low complexity and rich schema, it is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters and their fields. The description adds context that the resources are 'code file URLs' attached to component nodes and that they correspond to 'selected matches' from figma_match_components, but it does not add significant new semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Publish dev resource links to Figma Dev Mode') and the resource affected ('Attaches code file URLs to component nodes'). It distinguishes itself from siblings like figma_get_dev_resources and figma_match_components by describing the publishing/attach action and the prerequisite workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs the correct sequence: 'Run figma_match_components first to generate the mapping, then publish selected matches.' This provides clear context for when to use the tool. It does not explicitly state when not to use it or name alternatives, but the workflow guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It reveals the output format (base64 images) and the plugin dependency for fileKey, but lacks details on side effects, rate limits, or error handling. This is adequate but leaves gaps for a mutation-free tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences that front-load the core purpose and then provide targeted usage guidance. There is no fluff or repetition of schema fields; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five optional parameters and no output schema, the description covers the essential operational context: what it does, how to select nodes, and a plugin condition. It lacks explicit alternative differentiation and edge-case behavior, but is sufficient for straightforward screenshot use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 40%, and the description compensates by clarifying the nodeId/nodeIds relationship and fileKey optionality. However, it does not explain scale or format behavior beyond the schema defaults and enum, leaving fileKey partially under-documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Screenshot' with a clear resource 'one or more nodes' and specifies the output format 'base64 images'. This distinguishes it from sibling export tools like figma_export_png and figma_export_svg by emphasizing multiple node selection and base64 output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use nodeId vs nodeIds ('Use nodeId for a single node, or nodeIds for multiple nodes in one call') and a conditional clarification for fileKey. However, it does not mention when this tool should be preferred over alternatives like figma_export_png or figma_export_svg.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses a critical limitation (same team library only), the source of keys, and the alternative workflow. It doesn't mention permissions, reversibility, or return value, but the import/instance creation behavior is clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, front-loaded with the core action, then source, then limitation/alternative, then check step. No redundancy and each sentence contributes essential guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, key sourcing, and edge cases. However, with no output schema and no annotations, it omits where the instance is created (parentId behavior), parameter defaults, and return value, leaving an agent to infer invocation details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 20%, and the description adds meaning for componentKey (source via figma_get_components) but doesn't explain x, y, name, or parentId. The parameter names are suggestive but not sufficient for a tool that creates an instance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
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: 'Import a published component by its library key and create an instance.' It distinguishes from figma_clone_node for external libraries, but does not explicitly differentiate from the similarly named figma_create_instance sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: works only for same-team-library components, and explicitly instructs to use figma_clone_node for external/linked libraries. Also tells the user to run figma_get_components with source='library' first and source='file' for keys.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It explains the two operational modes (REST vs plugin bridge), enumerates the checks performed, and specifies the output format (WCAG criterion, severity, actionable fix). It does not explicitly state that the tool is read-only/non-destructive, but 'audit' strongly implies it. This is robust context beyond a simple one-liner.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then organizes additional detail into three compact paragraphs: execution mode, checklist, and output format. Every sentence adds unique value, and the WCAG references are grouped logically. Despite its length, it remains scannable and dense with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex, with no output schema, so the description appropriately covers the issue format (criterion, severity, fix). It also covers the main execution modes and the exact WCAG checks. It could mention defaults (level AA, categories all) or potential limitations, but those are already implied by the schema, so the description is sufficiently complete for an agent to invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter already has a meaningful description (e.g., level enum with default, nodeId for scoping, fileKey to enable REST, categories list). The tool description adds only slight clarification that 'fileKey' enables the REST mode, which is already in the schema. Per the rubric, with high schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource+scope: 'Comprehensive WCAG 2.1 accessibility audit'. It enumerates the exact WCAG criteria checked, which clearly distinguishes this tool from all sibling Figma tools (which are for editing, exporting, retrieval, etc.). This is a unique and unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear situational context: 'Works via REST API (no plugin needed) when fileKey is provided, or via plugin bridge for the live canvas.' This tells the agent how to choose the execution mode based on whether a fileKey is available. However, it does not explicitly mention when not to use this tool or name alternative audit tools, so it falls 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing REST-only behavior, no plugin requirement, and a detailed list of return values. It implies a safe read operation but does not explicitly state side effects, rate limits, or error behavior, so it is not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a front-loaded purpose statement followed by a concise bullet list of return items. Every sentence adds value, and the 'LLM should use this data' note directly guides the agent. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description does a good job explaining return values (image URLs, screenshot, metadata). However, the 'compact tree' format is left vague—properties, nesting, and exact schema of the tree are not specified—so the LLM might need additional context to interpret it fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 tool description does not add parameter-specific meaning beyond what the schema already provides (e.g., maxDepth, screenshotScale are explained in the schema). Thus, it meets the baseline but does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a clear resource ('complete design-to-code bundle'), and it distinguishes this tool from siblings by emphasizing 'single call' and 'REST-only, no plugin needed'. It also enumerates the main returned components, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when a full design-to-code bundle is needed in one call, and explicitly instructs the LLM to use this data to generate code directly. It does not, however, mention specific alternative tools or when not to use it, which would make it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of implying behavioral traits. 'Get all' indicates a read-only operation, but the description does not disclose return format, handling of empty results, or whether any state changes occur. It is acceptable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It front-loads the action and resource, making it immediately understandable and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless read operation, the description adequately specifies the resource and scope. It does not explain what 'flows' are or how results are returned, but the lack of an output schema and the straightforward nature of the tool make this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines zero parameters, so there are no parameter semantics to explain. Per the rubric, a zero-parameter tool gets a baseline of 4, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('all prototype flows') with a clear scope ('in the current page'). It distinguishes itself from related siblings like figma_create_flow and figma_remove_flow by focusing on retrieval rather than mutation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates the tool retrieves prototype flows scoped to the current page, giving the agent context for when to invoke it. However, it does not explicitly mention alternatives or when not to use it, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool scans a local directory and returns a list, implying a read-only operation. The supported frameworks are enumerated, giving a clear scope. It does not explicitly state 'does not modify files' or discuss performance implications, but the term 'scan' reasonably implies non-destructive behavior and the return type is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary action, followed by return value and usage context. Every sentence earns its place with no redundancy or fluff. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex (multiple frameworks, optional parameters) but the description covers the main purpose, input scope, output format, and when to use it. Since there is no output schema, explaining the return list is valuable and done effectively. Minor gaps exist around edge cases (e.g., default behavior for deeply nested directories), but the schema covers maxDepth. Overall, sufficient for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
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 does not add significant detail beyond the schema; it repeats the framework list that is already in the 'frameworks' enum. The directory and maxDepth parameters are well described in the schema. No special meaning is added by the tool description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Scan a local codebase directory for UI components' and lists the supported frameworks. It also explicitly differentiates from figma_match_components by indicating this is the precursor step. The return value (list of components with file paths and frameworks) is clearly specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use this before figma_match_components to find code-to-design mappings.' This tells the agent when to invoke this tool in a workflow. However, it does not mention alternatives for other scanning tasks (e.g., scanning Figma nodes instead of a local codebase), so it lacks full when-not/exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides important behavioral details: cache auto-expires after 5 minutes and it lists which tools are cached. This goes beyond the schema. It could also mention that 'clear' is destructive and irreversible, but the phrase 'clear all' implies this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence, but it front-loads the purpose and packs in actions, expiration, and affected tools. It is efficient without being bloated, though breaking it into a short bulleted list could improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description covers essential aspects: actions, expiration, cached tools, and an example. It omits the exact return format of 'stats' and any error handling, but for a cache management tool, the information is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the prefix parameter with a description and the action enum, but the action parameter has no description. The tool description adds meaning to the action values with concrete examples (e.g., 'invalidate' with prefix 'get_components'), compensating for the schema's limited coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages library/component/style cache and enumerates the three actions. It distinguishes itself from all sibling tools, which focus on actual Figma operations, making the resource and verb unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains each action (stats, clear, invalidate) with a brief purpose, giving clear context for when to use each. It does not explicitly mention exclusions or alternatives, but since there are no caching-related sibling tools, this level of guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It discloses max operation count, node reference syntax, parent type restrictions, and supported command list. It also notes parameter aliases and batch variants. However, it does not mention error handling, atomicity, or partial success behavior, which would be valuable for a mutation-heavy batch tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but dense and well-structured. It front-loads the critical advantages (batch, max 200 ops, prefer over loops), then lists commands, followed by parameter signature details and an IMPORTANT parent-node caveat. Every sentence provides actionable information; there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (44+ commands), minimal schema, and no output schema, the description covers a lot: command list, key aliases, batch vs. single patterns, parent constraints, and $ref syntax. However, parameter semantics for many commands (e.g., set_fill, set_effects) are not individually documented, relying on 'param names must match plugin function signatures exactly' as a catch-all. This leaves gaps for less common commands.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is minimal (only 'operations' with free-form command/params), and schema description coverage is 0%. The description compensates extensively by enumerating all valid commands and detailing parameter names, aliases, and specific signatures for many operations (e.g., create_text accepts 'content' or 'text', clone_node accepts offsetX/offsetY/newName). This is essential guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: batching multiple create, modify, and variable operations in one round-trip, with a max of 200 ops. It distinguishes itself from the many individual sibling tools by explicitly stating 'ALWAYS prefer this over calling individual tools in a loop.' The verb 'batch' plus resource scope makes the purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: always prefer this tool over looping individual tools, use create_frame instead of create_rectangle when children are needed, and notes only FRAME, GROUP, COMPONENT, and PAGE nodes can be parents. It also provides command-specific batch patterns (e.g., set_text_content updates array) which guide correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![figma-unified-mcp MCP server](https://glama.ai/mcp/servers/sso-ss/figma-unified-mcp/badges/card.svg)](https://glama.ai/mcp/servers/sso-ss/figma-unified-mcp)

Score Badge

Copy to your README.md:

[![figma-unified-mcp MCP server](https://glama.ai/mcp/servers/sso-ss/figma-unified-mcp/badges/score.svg)](https://glama.ai/mcp/servers/sso-ss/figma-unified-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/sso-ss/figma-unified-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server