Handle Figma MCP

Server Quality Checklist

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

Latest release: v0.4.13
Disambiguation3/5
Several tools have overlapping purposes, notably get_selection and read_my_design both retrieve selection details, and scan_text_nodes overlaps with scan_nodes_by_types. However, most tools target distinct actions or resources, and descriptions generally clarify usage, though some ambiguity remains.
Naming Consistency4/5
The vast majority of tools follow a consistent verb_noun snake_case pattern (e.g., create_rectangle, set_fill_color). Minor deviations like read_my_design and join_channel break the pattern, but the overall convention is clear and predictable.
Tool Count2/5
With 48 tools, the server is heavily over-scoped, exceeding the 25-tool threshold for 'too many.' Many tools are singular/plural variants (e.g., create_paint_style vs. create_multiple_paint_styles), which could be consolidated. This large count likely overwhelms agents.
Completeness3/5
The server covers a broad range of Figma operations: node CRUD, styling, layout, components, annotations, and prototyping. However, obvious gaps exist, such as text formatting (font, size, weight), stroke weight/dash, node grouping, and deletion of styles/variables. Core workflows are present, but several common design tasks are unsupported.
Average 3.5/5 across 48 of 48 tools scored. Lowest: 2.8/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
- No stable releases found
- 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

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 'parallelly' but does not explain batch semantics, such as whether existing annotations are replaced or merged, atomicity, side effects, or error handling. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that directly states the purpose, making it concise. However, 'parallelly' is an awkward choice, and the extreme brevity omits valuable context. It is not wasteful, but it is 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 the moderate complexity of the nested annotations array and the absence of both annotations and an output schema, the description is incomplete. It does not mention return values, error behavior, or how the batch operation interacts with existing annotations, leaving the agent without a full picture.
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 provides 100% description coverage for all parameters, including the nested annotation objects, so the baseline is 3. The description adds no additional parameter context, but the schema already documents the meaning of nodeId, annotations, and inner 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 identifies the action ('set') and resource ('annotations'), and 'multiple'/'parallelly' conveys that this is a batch operation, distinguishing it from the singular 'set_annotation' sibling. However, 'parallelly' is non-standard phrasing and the distinction is not explicitly stated.
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 about when to use this tool versus set_annotation or other annotation tools. There are no explicit alternatives, prerequisites, or contextual cues, 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.
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 states the basic action without mentioning side effects, default placement, or requirements beyond parameters, so it fails to disclose important 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 single sentence is succinct and gets straight to the point with no wasted words, 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.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a complex 20-parameter schema with nested objects and enums, the description provides no high-level context about how the frame is created, where it appears, or what the result is, leaving the agent under-informed about the tool's overall behavior.
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 description is not required to explain parameters, but it also adds no additional semantics beyond 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 uses the specific verb 'create' with the resource 'frame' and clarifies the context 'in Figma', making its purpose clear and distinguishing it from sibling tools like create_rectangle or create_text.
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 like create_rectangle or create_text, and no mention of prerequisites or context, leaving the agent without usage direction.
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 says 'Get all annotations' without disclosing return format, pagination, category handling, or behavior when no annotations exist. The phrase 'current document' conflicts with the required nodeId property, creating ambiguity about whether nodeId can be omitted or special.
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 wasteful wording. It efficiently states the core action but lacks structure to convey additional context, such as usage scenarios or return 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?
Given the tool has no annotations, no output schema, and only two parameters, the description should provide more context about expected return values and behavior when categories are excluded. The current description is minimal and leaves the agent with significant unknowns, especially the ambiguous 'current document' scope.
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% with descriptions for both parameters. The description adds the concept of 'current document' to nodeId, which is not in the schema, but it doesn't clarify includeCategories beyond its schema default and description. Baseline 3 is appropriate since schema already documents the 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 verb 'Get' and resource 'annotations', with scope 'current document or specific node'. It distinguishes from write siblings like set_annotation, but doesn't explicitly differentiate from similar read tools like get_reactions.
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. There is no mention of set_annotation for creating or get_reactions for reactions, and no exclusions or prerequisites are provided. The only context is the scope phrase, which is too vague to serve as usage direction.
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 it only states 'Get detailed information' without disclosing what information is returned, whether the operation is read-only, or any side effects. It fails to reveal behavioral traits beyond the basic 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 concise sentence with no redundant or ambiguous wording. It is appropriately sized and directly communicates the tool's core purpose, earning every word.
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 too thin for a tool with one parameter and no output schema. It does not explain what 'detailed information' includes, how the result is structured, or when this tool is preferable to related tools, leaving significant gaps for the 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 input schema already documents nodeId with a clear description, and parameter coverage is 100%. The description's mention of 'a specific node' adds minimal semantic context beyond the schema, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get detailed information about a specific node in Figma' clearly states a specific verb (get) and resource (node), with 'specific node' distinguishing it from sibling tools like get_nodes_info (plural). It is clear and functional, though it does not explicitly reference 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 alternatives such as get_nodes_info or get_selection. The description is purely declarative and does not provide 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. It does not state whether the operation is read-only, what it returns, whether it recursively scans all descendants, or any side effects. 'Scan' could be interpreted as listing, counting, or extracting, leaving the behavior opaque.
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 redundancies or irrelevant information. Every word earns its place, and the key information (action, resource, scope) is 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?
While the tool is simple with only one parameter, the absence of an output schema means the description should clarify what 'scan' returns (e.g., a list of text nodes, their contents, or IDs). It also fails to mention recursion depth or whether the operation only considers the node itself or its subtree. Given these gaps, the description is not complete enough for an agent to reliably predict the tool's behavior.
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 100% of the parameter (nodeId), so the baseline is 3. The description adds 'selected' to describe the node, which is a minor semantic clarification but also introduces potential ambiguity. It does not provide extra details like the expected format (e.g., Figma node ID string) beyond the 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 ('Scan') and resource ('text nodes') with a scope ('in the selected Figma node'), which clearly distinguishes it from broader sibling tools like scan_nodes_by_types. The term 'selected' is slightly ambiguous (could imply current UI selection rather than the nodeId parameter), but the core purpose is 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?
There is no guidance on when to use this tool versus alternatives such as scan_nodes_by_types or get_nodes_info. No exclusions or prerequisites are mentioned. The description implies a general scanning action but provides no explicit 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?
With no annotations provided, the description must convey behavioral details. It merely states 'create or update' without explaining the distinction between creating and updating, how annotationId determines the operation, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that states the action with no extraneous words. It is front-loaded 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 is a mutation with no annotations or output schema, and the description does not provide necessary context such as return behavior, idempotency, or use cases. The terse description is inadequate 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all five parameters, so the baseline is 3. The description adds no additional parameter semantics beyond the schema, so it remains at baseline.
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 as creating or updating an annotation, using a specific verb and resource. However, it does not explicitly distinguish it from sibling tools like set_multiple_annotations, though the singular 'an annotation' implies a single annotation.
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 set_multiple_annotations. It lacks any context about scenarios or prerequisites.
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 potential side effects (e.g., changing the previous default), whether the operation is destructive or reversible, or what the return value is. This is a significant gap for a mutation-like 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 filler, but it is arguably too brief and could benefit from including supplementary context. It is front-loaded and readable.
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 simple nature (one parameter), the description provides the basic purpose, but it lacks critical information about side effects, prerequisites, and return behavior. Since there is no output schema and no annotations, the description is not complete enough for an agent to invoke the tool safely and confidently.
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 provides a clear description for connectorId, and the tool description reinforces the notion of a 'copied connector node'. However, the parameter is not marked as required (required: 0), and the description does not clarify whether omitting it is valid or what happens if it is omitted, creating slight ambiguity.
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 'copied connector node' as the default connector, making the purpose specific and distinguishable from sibling tools. It could be more explicit about what 'default connector' means, but the core action is 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?
There is no guidance on when to use this tool versus alternatives, no mention of prerequisites (e.g., having a copied connector node), and no exclusions. The description simply states what it does, leaving the user to infer 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 says 'Move a node', but does not mention whether the move is absolute or relative, whether it affects child nodes or connections, or what the return value is. The mutation implications are left implicit.
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 text. It earns its place but is minimal, and could be slightly richer 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?
For a simple mutation tool with no output schema or annotations, the description is insufficient. It does not explain coordinate semantics, side effects, or expected return behavior, leaving gaps for an agent that needs to 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?
The input schema has 100% parameter description coverage (x, y, nodeId). The tool description adds no additional meaning beyond the schema, 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 clearly states the verb 'Move' and the resource 'node', along with the scope 'to a new position in Figma'. It distinguishes this tool from sibling tools like resize_node or clone_node by focusing on relocation.
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 simply states the action without any context about preferred 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?
With no annotations, the description carries full burden. It only says 'Clone', implying a mutating action, but does not disclose critical behaviors such as clone placement, whether children are copied, or effects on document 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, front-loaded sentence with no filler words. Every word earns its place, making it highly 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 no annotations or output schema, yet the description reveals little about the clone's behavior (position, naming, children, return value). The description is too sparse for an agent to predict consequences.
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 provides 100% parameter coverage with descriptions for x, y, and nodeId. The tool description itself adds no parameter-specific meaning, so the baseline score of 3 applies.
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 'Clone' and resource 'existing node', clearly indicating its function. It is distinct from sibling tools like create_rectangle or move_node, and no other tool duplicates nodes.
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 cloning versus creating new nodes or other alternatives. It lacks any mention of use cases, preconditions, 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 must disclose behavioral traits. It only states the action and the style, without revealing whether existing connections are affected, what happens on invalid input, or any side effects. This is insufficient for 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, front-loaded sentence of nine words. It contains no redundant information and is 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 no annotations and no output schema, so the description carries the full burden. It fails to mention prerequisites like setting the default connector style, error conditions, or the nature of the return value, making it 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 fully documents the 'connections' array and its nested properties with descriptions, giving 100% coverage. The description adds no parameter-specific semantics beyond the schema, only the behavioral note about default style, 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 uses the specific verb 'create' with the resource 'connections between nodes', clearly distinguishing it from sibling tools like create_rectangle or create_text. The qualifier 'using the default connector style' adds context about the connector style, 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?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention any preconditions, such as setting the default connector style first with set_default_connector, or when not to use it.
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 transparency. It only states that a new polygon is created, with no mention of effects on the document, return values, permissions, or error conditions.
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, direct sentence with no filler. It is front-loaded and every word earns its place, efficiently communicating the core 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?
Despite the schema covering parameters, the description is inadequate for a complex tool with 11 parameters and no output schema. It fails to explain what the tool returns or any contextual setup, leaving the agent without essential implementation 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 description coverage is 100%, with detailed descriptions for all 11 parameters. The description adds no additional parameter semantics beyond what the schema already provides, so it meets the baseline.
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 and resource: 'create a new polygon (regular polygon) in Figma'. It clearly identifies the exact object being created and distinguishes it from sibling tools like create_rectangle and create_frame.
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 create_rectangle or create_frame. It only states the action without any context, exclusions, or references to other 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 full burden, but it only states the action without disclosing side effects, return behavior, coordinate system, or prerequisites. This is less transparent than update_drive, which at least listed updatable fields.
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 sentence, front-loaded, and zero filler. Every word contributes to identifying 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?
With six parameters, no output schema, and no annotations, the description leaves out critical context such as return value, units, parent behavior, and default placement. It is minimally viable but substantially incomplete.
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 descriptions cover 100% of parameters with clear meanings, so baseline is 3. The description text adds no parameter details 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?
Description uses specific verb+resource: 'Create a new rectangle in Figma'. It clearly states the tool's function and differentiates from siblings like create_polygon, create_frame, and create_text.
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 alternatives. It does not mention coordinate context, document state, or when create_frame/create_polygon might be preferable.
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 only states the core creation action. It does not mention side effects, required parent/position context, mutation implications, return values, or default behaviors, leaving significant behavioral ambiguity.
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 immediately states the tool's purpose without 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?
Despite having 8 parameters and no output schema, the description provides almost no operational context. It omits required coordinates, parent behavior, return value, and how this creation integrates with other Figma operations. The schema covers parameters but does not compensate for the lack of higher-level usage context.
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 all parameters including the nested fontColor object and defaults like fontSize. The description adds no additional parameter meaning, so the baseline score of 3 applies.
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 specifies the exact verb ('Create') and resource ('text element') along with the platform ('Figma'), clearly distinguishing it from sibling tools like create_rectangle or set_text_content. 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?
The description gives no guidance on when to use this tool versus alternatives such as set_text_content (for editing existing text) or create_frame (for creating frames). There is no mention of prerequisites or selection context, so the agent receives no decision support.
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. While 'rename' implies a mutation, the description does not disclose potential side effects (e.g., whether references to the style are updated), reversibility, permissions, or return value. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence of four words, perfectly concise and front-loaded. No filler or redundant information is present. It earns its place by stating the tool's core purpose.
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 with only two params, both fully documented in the schema, and no output schema. However, with no annotations and no contextual guidance (e.g., how rename relates to create/swap, effects on existing usages), the description is insufficient for an agent to fully understand the tool's behavior. Minimal viable but with clear gaps.
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 the schema already describes both parameters clearly ('The new name for the style' and 'The ID of the style to rename'). The description adds no additional meaning beyond what the schema provides, so 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 uses a specific verb ('rename') and a specific resource ('paint style'), clearly distinguishing it from sibling tools like create_paint_style or swap_style. The purpose is immediately clear 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that create_paint_style is for new styles or that swap_style is for swapping style properties. No prerequisites or exclusions 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, the description carries the full burden but only states the action. It discloses no behavioral traits such as whether the operation is destructive, preserves node children, or affects constraints. 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 filler. It is appropriately concise for a simple operation, earning every word.
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, this description is incomplete. It does not explain return behavior, error cases, or side effects, leaving the agent without sufficient context to invoke it safely and understand the outcome.
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 fully describes all three parameters (nodeId, width, height) with types and descriptions (100% coverage). The description adds no additional parameter meaning, so the 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 uses a specific verb 'Resize' and a resource 'node in Figma', clearly distinguishing it from sibling tools like move_node or clone_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?
No usage guidance is provided. The description does not mention when to use this tool versus other node manipulation tools, nor any prerequisites, 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 only says 'Delete' without noting permanence, effects on child nodes, permission requirements, or reversibility, leaving the destructive nature only partially implicit.
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 filler or redundancy. It is maximally concise for the simple operation it describes.
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 with one fully documented parameter and no output schema, so the description does not need much. However, for a destructive action it omits important caveats like irreversibility and does not mention the bulk-delete sibling, leaving minor but relevant gaps.
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 fully documents nodeId as 'The ID of the node to delete' with 100% coverage, so the description adds no additional parameter semantics beyond the structured definition. The baseline of 3 is appropriate because the schema does the heavy lifting.
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 ('a node from Figma'), clearly distinguishing this singular deletion tool from sibling tools like delete_multiple_nodes. It is immediately obvious what the tool does.
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 such as delete_multiple_nodes, nor any context about prerequisites or selection requirements. The description states the action but gives no usage direction.
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 bear the full burden. It only states that the tool sets a corner radius, but fails to disclose that the corners parameter can selectively round specific corners, whether the mutation is destructive or reversible, or what the tool returns. This is significant 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 unnecessary words. It conveys the essential purpose efficiently, and 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 relatively simple with 3 parameters and a comprehensive schema, but there is no output schema and no annotations. The description does not mention the optional corners behavior or what happens after execution, leaving the context incomplete but minimally viable.
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 has 100% coverage for all parameters, including detailed descriptions for nodeId, radius, and the corners array. Since the schema already provides the necessary semantics, the description adds no additional parameter information, which aligns with the baseline of 3.
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 (set) on a specific resource (the corner radius of a node in Figma). It distinguishes this from sibling tools like set_fill_color or resize_node by naming the exact property being modified.
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 for when to use this tool versus alternatives, such as when a node type may not support corner radius or if there are prerequisites. The intended use is only implied by the 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 provided, the description carries the full burden of behavioral disclosure. It lacks any mention of side effects, requirements (e.g., node must be a frame), or potential issues when changing layout mode or wrap behavior. The mutation is implied but not elaborated.
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 immediately states the tool's purpose without any redundant or 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 tool is relatively simple and the schema covers parameters well. The description gives the core purpose but omits potential nuances like interaction between layoutMode and layoutWrap or requirements such as 'frame must support auto-layout'. This is adequate 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 100%, with each parameter already documented. The tool description adds no additional meaning beyond the schema, so the 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 action ('Set') and the target ('layout mode and wrap behavior of a frame in Figma'), making it distinct from sibling layout tools like set_padding or set_axis_align. It precisely conveys what property is being modified.
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 does it mention prerequisites or exclusions. The intended usage is only implied by the tool name and schema, so the agent receives no explicit decision support.
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 merely states the operation with no detail about side effects, destructive nature, or interaction with the optional weight parameter. 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?
A single sentence, front-loaded with the verb and object, with no unnecessary words or content. It earns its place entirely.
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 mutation tool with complete schema descriptions, this meets the minimum viable threshold. However, it lacks usage context and behavioral transparency, and has no output schema, so it is not more complete. A 3 reflects the adequacy with clear gaps.
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 provides descriptions for all 6 parameters with 100% coverage, so the description does not need to add parameter-level detail. Baseline 3 is appropriate because the schema handles the semantics adequately.
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+resource structure: 'Set the stroke color of a node in Figma'. This clearly identifies the action and target, distinguishing it from siblings like set_fill_color and apply_paint_style.
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 such as set_fill_color or apply_paint_style. There is no mention of exclusions, prerequisites, or when an alternative 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 full responsibility for behavioral disclosure. It only states the basic action ('Create an instance') but does not reveal side effects (e.g., whether the new instance gets selected, what coordinate system x/y refers to, or what happens if componentKey is invalid). 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, concise sentence that immediately states the tool's purpose. It contains no filler or redundancy, earning full marks for efficiency.
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 low complexity (3 simple parameters, no output schema), the description lacks important contextual information. It does not mention the need for a componentKey from a valid component, the coordinate system for x/y, or what the tool returns after creation. Since annotations are absent, the description should carry more weight, but it remains too thin to be considered 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?
The input schema provides full coverage (100%) with descriptions for all three parameters, so the baseline is 3. The description adds no extra parameter semantics beyond what the schema already states. The parameter descriptions are adequate but minimal, and the tool description does not enrich them further.
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 specific resource ('an instance of a component'), with context ('in Figma'). This distinguishes it from sibling tools like create_rectangle or create_frame, which target different object types.
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 its usage situation—when you need to instantiate a component—but does not explicitly mention when to prefer this over other creation tools, nor does it note any prerequisites such as obtaining a valid componentKey from get_local_components. No alternatives are named, so guidance is implicit 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?
Annotations are absent, so the description carries the full burden. It only states the action and provides no details on recursive deletion of child nodes, failure behavior for invalid IDs, atomicity, or undoability. For a destructive tool, this is a notable 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 a single, front-loaded sentence with no redundancy. 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?
For a mutation tool with no annotations and no output schema, the description is too sparse. It omits critical behavioral context such as recursive deletion, partial-failure semantics, and whether the operation is reversible, making the description inadequate for the risk involved.
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 describes nodeIds as 'Array of node IDs to delete' (100% coverage). The description adds no parameter-level meaning beyond the schema, so the 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 'Delete multiple nodes from Figma at once' — a specific verb and resource, with 'multiple' distinguishing it from the sibling delete_node tool. It is immediately clear what the tool does.
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 this is for batch deletion when you have multiple node IDs, but it does not explicitly contrast with delete_node or mention when not to use it. There are no stated prerequisites or conditions.
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 must disclose behavior. It does not mention output format (e.g., base64, binary, URL), potential side effects (none expected), or authentication requirements. This leaves the agent uncertain about the invocation result.
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 is front-loaded with the core 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?
Given no annotations and no output schema, the description should clarify return semantics and operational constraints. It fails to mention what the agent receives after export (e.g., image data, URL) and whether any node types are unsupported. This is a significant gap for successful 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 schema provides descriptions for all three parameters (scale, format, nodeId) with enum for format, achieving 100% coverage. The description adds no extra semantic meaning beyond the schema, so the 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 action (export), object (node), and result (image). It is distinct from sibling tools, which focus on creation, modification, or deletion, not export.
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 when-to-use guidance or alternative comparisons are provided. Since there is no sibling export tool, the usage context is implied by the tool's unique purpose, but the description could still mention typical scenarios (e.g., generating assets for a design).
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 carry the full burden of behavioral disclosure. 'Get information' implies read-only, but it doesn't specify the return format, behavior with an empty selection, or any other edge cases. This is minimal for a tool with no 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 well-structured sentence, front-loaded with the verb and subject, and contains no extraneous words. It is as concise as possible while conveying the core purpose.
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 the lack of output schema and the vagueness of 'information' leaves significant gaps. The description does not explain what the returned data looks like, how to handle an empty selection, or any prerequisites, making it incomplete for an agent to fully rely on.
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 effectively 100%. The description adds no parameter semantics, but with no parameters the baseline of 4 is appropriate; there is nothing to explain.
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 the resource 'current selection' in Figma, clearly distinguishing it from sibling tools like set_selections (which sets selection) and get_node_info (which targets specific nodes). 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention exclusions or alternatives, leaving the agent to infer usage context from sibling names rather than explicit direction.
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 clarify whether the scan is recursive, whether it returns the matching nodes, or whether it is a read-only operation. The phrase 'selected Figma node' is ambiguous given the nodeId parameter. This lack of behavioral detail leaves significant gaps for an agent.
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 with no superfluous words. It directly states the action, target, and scope, earning a perfect score for conciseness and 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?
The tool has no output schema and no annotations, so the description must explain the tool's behavior and return value. It does not mention what the scan returns, whether it is recursive, or any edge cases. For a simple scanning tool, the description is incomplete and leaves important context missing.
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 fully describes both parameters (nodeId and types) with clear descriptions, so the schema provides the heavy lifting. The tool description only adds a redundant phrase 'selected Figma node' which does not meaningfully enhance parameter understanding. Thus, the 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 uses a specific verb 'Scan for' and specifies the resource 'child nodes' with a focus on 'specific types' in a 'Figma node'. This clearly distinguishes it from siblings like scan_text_nodes and get_node_info, 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 for finding child nodes by type but does not explicitly mention when to use this tool versus alternatives like scan_text_nodes or get_nodes_info. There is no guidance on exclusions or prerequisites, so the usage context is only implied.
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 states the action without mentioning side effects, requirements (e.g., node must be an auto-layout frame), invalid input behavior, or whether the operation is reversible. This is a mutation tool with no safety hints.
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 11-word sentence that directly communicates the tool's purpose with zero fluff. It is well-structured and front-loaded with the key action and resource.
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 annotations or output schema, and while the schema covers parameters, the description lacks additional context such as preconditions, error behavior, or return value. For a mutation tool with no safety annotations, this is insufficient.
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 provides 100% coverage with detailed descriptions for all three parameters, including enum meanings and the note about SPACE_BETWEEN ignoring itemSpacing. The description adds no additional parameter information beyond what the schema already offers, so the baseline of 3 applies.
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 sets primary and counter axis alignment on an auto-layout frame, identifying a specific verb, resource, and scope. This distinguishes it from sibling tools like set_layout_mode and set_padding, which handle different layout properties.
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 specifying the target as an auto-layout frame, providing some context. However, it does not explicitly state when to use this tool instead of alternatives, nor does it mention any prerequisites or exclusions beyond the auto-layout requirement.
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 behavioral burden. It explains the folder notation for grouping but does not disclose what happens on name collision, whether styles are local or library-level, or any side effects. Creation behavior is implied but under-specified.
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 sentences, front-loaded with the core action, and no fluff. The folder notation example is practical and 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 description covers purpose and naming organization, but for a tool with no annotations and no output schema, it misses behavioral context like duplicate handling and relationships to sibling tools. Adequate for a simple creation tool but with clear gaps.
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% with all parameters described, including the folder notation for 'name'. The description repeats the same example without adding new parameter meaning. Baseline 3 applies because the schema carries the heavy lifting.
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 identifies the resource as 'color style (paint style) in Figma', clearly distinguishing it from sibling tools like apply_paint_style or create_color_variable. The naming convention example further clarifies the tool's purpose.
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: create a single paint style. However, it does not explicitly state when to use this tool versus alternatives like create_multiple_paint_styles or create_color_variable, nor does it mention exclusions. The folder notation tip is helpful but not about 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 explaining behavior. It only states the action and purpose but does not disclose side effects, prerequisites, idempotency, or what 'communicate' entails. This leaves significant behavioral ambiguity for a mutating/stateful 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 with no filler or redundant content. It is front-loaded with the verb and immediately states the resource and purpose, making it 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?
This is a very simple tool with one optional parameter and no output schema. The description covers the core purpose but omits context such as whether joining is required before using other Figma tools, whether the channel must exist, or what the result of joining is. For a minimal viable description it is adequate, but there are clear gaps.
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 fully documents the 'channel' parameter with a default value and description, achieving 100% coverage. The tool description adds no additional parameter meaning beyond restating 'a specific channel', so the 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 uses the specific verb 'join' with the resource 'a specific channel' and states the purpose 'to communicate with Figma'. This clearly distinguishes the tool from sibling design-operation tools, as no other sibling addresses channel communication.
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 one needs to communicate with Figma via a channel, but it does not explicitly state when to use it over alternatives or provide exclusions. Since no sibling tool has similar functionality, the context is somewhat clear, but the guidance remains implicit 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 carries the full burden of disclosing behavior. It mentions 'parallelly', indicating execution in parallel, but it does not state whether the operation overwrites existing content, requires specific permissions, or is atomic. 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 a single sentence with no waste, clearly stating the action and scope. It is front-loaded and effectively conveys the core purpose in a concise manner.
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 has a simple schema with full parameter coverage, but the description lacks context about the container node's relationship to the text nodes, and there is no output schema or annotations to enrich understanding. It is adequate for a straightforward batch operation but leaves gaps in behavioral context.
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 provides 100% coverage with descriptions for both parameters (nodeId and text). The description adds no extra meaning beyond that, so the 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 tool's purpose: to set multiple text contents. The verb 'set' is specific, and the resource is 'multiple text contents' with a scope of 'in a node'. It distinguishes itself from the sibling tool set_text_content by explicitly indicating it handles multiple items.
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 through the plural 'multiple', suggesting it is meant for batch operations, but no explicit guidance or alternatives are mentioned. The description does not state when to use this versus set_text_content, nor does it provide any exclusions or prerequisites.
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 states a mutation action ('Set padding values') but does not describe side effects, partial update behavior (which padding values are changed if only some are provided), or what happens if the node is not an auto-layout frame. This lack of transparency 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: 'Set padding values for an auto-layout frame in Figma.' Every word earns its place, and there is no redundancy or unnecessary detail. It is concise and immediately understandable.
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 and full schema coverage, the description is reasonably complete but lacks operational context. It does not mention that only nodeId is required, that unspecified paddings may retain existing values, or any error conditions. The absence of an output schema is fine, but behavioral notes would improve completeness.
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%, with all five parameters described individually. The description itself adds no extra meaning beyond saying 'padding values', so it does not compensate for or enrich the schema. Baseline score of 3 is appropriate since the schema does the heavy lifting.
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 padding values for an auto-layout frame in Figma' uses a specific verb (Set), identifies the resource (padding values), and scopes it to auto-layout frames. This clearly distinguishes it from sibling tools like set_item_spacing or set_layout_mode, which target 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear usage context: 'for an auto-layout frame' indicates it applies only to auto-layout frames. However, it does not explicitly mention when to use this tool instead of alternatives (e.g., set_item_spacing for spacing) or provide any exclusion criteria, so guidance is implicit 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It merely says 'get detailed information' without stating what details are included, whether any authentication is needed, or any side effects (though it is clearly a read operation). It adds very little beyond the tool name and gives no specifics about return behavior or limitations.
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 directly states the tool's purpose with no unnecessary words. It is front-loaded with the verb and resource and is appropriately concise for the tool's simplicity.
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 low complexity (one parameter, no output schema, no annotations), the description is reasonably complete. It clearly identifies the operation and the resource, and the schema covers the parameter. However, it does not describe what 'detailed information' includes, which would be helpful since there is no output schema.
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 has 100% description coverage for the single parameter 'nodeIds', which is documented as 'Array of node IDs to get information about'. The description adds no additional parameter information, but since schema coverage is high, 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 'Get detailed information about multiple nodes in Figma' has a specific verb ('get'), a clear resource ('nodes'), and explicitly scopes to 'multiple nodes'. This not only states what the tool does but also distinguishes it from the singular sibling 'get_node_info'.
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 multiple nodes need information, but does not explicitly mention alternatives or when to prefer this over the singular 'get_node_info'. The context is clear from the word 'multiple', but there is no explicit guidance 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?
No annotations are provided, so the description carries the full burden. It discloses the supported node types but does not describe behavior for unsupported types, whether it replaces existing fills, the default alpha when 'a' is omitted, or any error handling. 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 sentence with no unnecessary words. The phrasing 'in Figma can be TextNode or FrameNode' is grammatically awkward, but it is concise and to the point.
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?
This is a simple tool with 5 parameters and no output schema. The description covers the basic purpose and node type restriction, but it does not address edge cases such as unsupported node types, default alpha behavior, or return values. It is adequate but has clear gaps.
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 100%, so the baseline is 3. The description adds a constraint on nodeId by specifying the node must be a TextNode or FrameNode, which goes beyond the schema's generic description of 'nodeId'. This extra meaning justifies a 4.
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 sets the fill color of a node and specifies that the node can be a TextNode or FrameNode. It uses a specific verb and resource, and the 'fill color' scope distinguishes it from sibling tools like set_stroke_color.
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 does not explicitly say when to use this tool versus alternatives, but the 'fill color' wording implies it is for modifying fill rather than stroke. No alternatives or exclusions are mentioned, so usage guidance is only implied.
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 discloses almost nothing beyond the basic mutation. It does not mention what happens if the frame is not auto-layout, whether existing spacing is overwritten, or any edge cases. The schema carries the caveats, but the description itself offers no behavioral insight.
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 that gets straight to the point with no wasted words. However, it is so terse that it omits useful details that could have been included without bloat.
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 setter with a well-documented schema, the description is mostly adequate. Yet it lacks any mention of prerequisites, failure modes, or behavior when constraints are violated, leaving some gaps for a mutation tool with no output schema.
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%, and the schema already explains each parameter thoroughly, including the SPACE_BETWEEN and WRAP caveats. The description adds no meaning beyond what the schema provides, so the baseline score of 3 applies.
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 ('set'), the resource ('item spacing'), and the specific context ('children in an auto-layout frame'). This distinguishes it from sibling tools like set_padding or set_layout_mode, which target 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by limiting the tool to auto-layout frames, but it does not explicitly state when not to use it or mention alternatives. The context is implied rather than fully spelled out.
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 the tool does but does not disclose any side effects, error conditions (e.g., non-existent node, invalid type), permission requirements, or return behavior. This is minimal 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, concise sentence that immediately conveys the tool's purpose. It uses no filler words and is perfectly sized for the simple operation it describes.
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 two-parameter setter, the description combined with the schema is nearly complete. It does not mention return values or error handling, but given the low complexity and absent output schema, this is a minor gap rather than a critical omission.
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 provides 100% coverage of both parameters (nodeId and text) with clear descriptions. The tool description adds no additional parameter semantics beyond what the schema provides, 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 clearly states the action ('Set the text content') on a specific resource ('an existing text node in Figma'). This distinguishes it from likely siblings like create_text (which creates new nodes) and set_multiple_text_contents (which handles multiple nodes).
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 'existing text node' implies the tool is for modifying an already-created text node, but no explicit guidance is given on when to choose this over alternatives like set_multiple_text_contents or create_text. Usage context is only implied, not clearly articulated.
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 behavior. It only states 'get detailed information', which implies a read, but does not explain what details are returned, permissions needed, or any limitations. This is under-informative for an agent.
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 concise, front-loaded sentence with no unnecessary words. Every word contributes to the purpose.
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, but with no output schema or annotations, the description should clarify what 'detailed information' includes. The current text is vague and leaves the agent guessing about the response structure. It is minimally acceptable but not 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 tool has zero parameters, so schema coverage is trivially 100%. The description does not need to add parameter semantics, and the baseline of 4 applies.
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?
Uses a specific verb ('get') and resource ('document') with scope ('current Figma document'). Clearly distinguishes from siblings like get_node_info and get_selection.
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?
Implies usage for document-level information through the description, but does not explicitly mention when to use it versus alternatives such as get_node_info or read_my_design. No exclusions or contextual guidance provided.
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 of disclosing behavioral traits. It does disclose the key side effect: target instances are swapped to the source component and all copied overrides are applied. However, it doesn't mention reversibility, whether existing overrides are overwritten, 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 sentences, front-loaded with the core action, no redundant words. Every sentence 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 has no output schema and no annotations. The description states the core behavior and effect, but lacks information on preconditions (e.g., having copied overrides) and potential side effects beyond the swap. It is adequate but could be more complete for a mutation operation.
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 the description adds no additional meaning beyond what the schema already provides for sourceInstanceId and targetNodeIds. Baseline 3 applies because the schema is doing the heavy lifting.
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 ('Apply') and resource ('previously copied overrides to selected component instances'), and further clarifies the effect by stating target instances will be swapped to the source component. This clearly distinguishes it from sibling tools like get_instance_overrides or create_component_instance.
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 a prerequisite (previously copied overrides) and target selection, but it does not explicitly state when to use this tool over alternatives like apply_paint_style or swap_style, nor does it mention exclusions. Usage is implied rather than clearly 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 carries the full burden of behavioral disclosure. While it states the replacement action, it does not mention whether the change is persisted immediately, whether it can be undone, or if any permissions are required. This is a significant gap for a mutation tool, as the agent cannot infer the side effects or reversibility.
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 front-loads the primary action and resource. Every word earns its place, with no filler or repetition of schema 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?
This is a simple 2-parameter tool with no output schema, so the description does not need to detail return values. However, it lacks behavioral context such as scope (e.g., whether all usages across the entire document or just the current page) and potential safety implications. It is minimally sufficient but leaves room for more guidance.
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 100% of parameters with clear descriptions, so the baseline is 3. The description adds the context of 'usages' (implying global scope) but does not provide additional syntax or format details beyond what the schema already offers. It does not compensate for any missing parameter explanation, but none is needed.
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 ('find all usages and replace') with a clear resource ('paint style'), immediately conveying the global find-and-replace capability. This distinguishes it from sibling tools like 'apply_paint_style' (which likely applies a style to a selection) and 'get_styles' (which lists 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 clearly establishes the context: use when you need to replace all occurrences of one paint style with another. However, it does not explicitly state when not to use it or mention alternatives, such as 'apply_paint_style' for targeted changes. It provides clear context but 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 provided, the description bears full responsibility for disclosing behavior. It states the scope ('local components' and 'from the Figma document') but does not describe return format, pagination, or what constitutes 'local' versus imported components.
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 irrelevant details, making it highly efficient.
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 zero-parameter getter with no output schema, the description is largely adequate, specifying the resource and scope. However, it omits any detail about the return value or whether components from all pages are included, though 'from the Figma document' implies full document scope.
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, so the input schema is empty. The description appropriately avoids parameter explanation; per the baseline for zero-parameter tools, a score of 4 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 retrieves all local components from the Figma document. The verb 'get' and specific resource 'local components' distinguish it from sibling tools like get_styles or get_document_info.
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 offers no guidance on when to use this tool versus alternatives like get_styles or create_component_instance. There is no mention of prerequisites, intended 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It merely states the action without noting constraints, side effects, or failure modes, such as what happens if the target node is not an auto-layout frame or if an invalid sizing mode is supplied. This is a mutation tool, so more transparency is expected.
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 directly states the action and target. Every word earns its place with no redundant information, making it optimally concise.
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 (3 params, no output schema) and the description defines its scope clearly. It could optionally mention that the node must already be an auto-layout frame, but this is implied by the phrase 'auto-layout frame'. Given the simplicity and strong schema coverage, the description is sufficiently 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?
The schema covers 100% of parameters with descriptions, including enum constraints and usage notes like 'HUG for frames/text only, FILL for auto-layout children only'. The description adds no additional parameter semantics beyond what the schema already provides, so the 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 uses the specific verb 'set' with a clear resource: 'horizontal and vertical sizing modes for an auto-layout frame in Figma'. This immediately distinguishes it from sibling tools like set_layout_mode (which sets overall layout direction) and set_padding, making the tool's function 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?
It clearly indicates the tool applies to auto-layout frames, which narrows usage context. However, it does not explicitly state when to prefer this over alternatives or mention exclusions (e.g., when the node is not an auto-layout frame), stopping short of full 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without revealing whether the existing fill is replaced or layered, any permission requirements, or whether the operation is reversible. This minimal disclosure is insufficient for a mutation tool affecting a node's appearance.
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 exactly two sentences: the first states the operation and target, the second provides a key usage prerequisite. There is no filler, redundancy, or unexplained jargon—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 with two fully-documented parameters and no output schema, so the description's core content is adequate. However, the lack of annotations and omission of behavioral outcomes (e.g., whether the fill is overwritten, node type constraints) leaves some gaps for a mutate operation. It's functional but not fully comprehensive.
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 already documents both parameters with 100% coverage, providing clear definitions for nodeId and styleId. The description adds value by telling the agent to use get_styles to obtain styleId, which enriches the semantic understanding of that parameter beyond the schema's 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 clearly states the verb 'Apply' and the resource 'existing color style to a node's fill', specifying the tool's scope precisely. It distinguishes itself from related tools like set_fill_color by focusing on applying a named style, and even mentions the prerequisite get_styles, which reinforces its unique role.
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 agent to use get_styles to find style IDs first, providing a clear prerequisite and naming the relevant alternative tool. It doesn't explicitly contrast with direct fill setters like set_fill_color, but the 'existing style' phrasing implies this tool is for named styles rather than arbitrary colors.
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 itself must convey behavior. It implies a read-only operation via 'Get', but it does not disclose what constitutes a 'style' (e.g., paint vs text styles) or any error conditions. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the action and resource. 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.
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 and the description captures the core action, it omits details about the output format or whether library styles are included. Given no output schema, a bit more context would improve completeness, but the low complexity prevents a lower 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?
The input schema is empty, so there are no parameters to explain. The description correctly focuses on the tool's action, and with zero parameters, no further semantic detail is necessary.
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 verb 'Get' and the resource 'all styles' scoped to 'the current Figma document', which distinguishes it from sibling tools that create, apply, or rename styles. There is no ambiguity about what the tool does.
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 no explicit guidance on when to choose this tool over alternatives like create_paint_style or apply_paint_style. The usage is implied by the name and semantics, but there is no mention of prerequisites or exclusions, so the agent must infer.
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. The name and verb 'Get' imply a read-only operation, but the description does not disclose what happens when there is no selection, whether multiple nodes are returned, or the exact structure of the returned 'node details'. It remains somewhat vague about the tool's behavior beyond the basic read 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 immediately states the action and subject. It is concise with no wasted words or redundant phrasing.
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 has no parameters and no output schema, so the description is the only source for return expectations. It says 'detailed information' and 'all node details' but does not enumerate the details or mention edge cases like empty selection. While the tool is simple, the description could be more precise about the returned content and error behavior.
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 is empty with zero parameters, so there are no parameter semantics to explain. The description does not need to compensate for undocumented parameters, and the baseline for 0 parameters is 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 clearly states the verb 'Get' and the resource 'detailed information about the current selection in Figma', and adds 'including all node details' which specifies the scope. This distinguishes it from sibling tools like 'get_selection' which likely returns only the selection IDs, and 'get_node_info' which targets specific nodes rather than the current selection.
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's details are needed, but it does not explicitly state when to use it versus alternatives like 'get_selection' or 'get_node_info'. There is no exclusionary guidance or mention of alternatives, so the usage context is only implied.
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 of behavioral disclosure. It reveals the key upsert behavior: 'If the variable exists, its value for the default mode is updated.' This is a critical behavioral trait beyond simple create/update. However, it does not disclose details about collection creation or potential side effects on other modes, so it's 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 two sentences, front-loaded with the core action, and contains no redundant information. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters and no output schema, the description is adequate: it states the core function, the update behavior, and the scope (default mode). The schema covers parameter details. However, it misses explicit guidance on when to use this over sibling tools, and does not mention collection creation behavior, which is only in the schema. Still, it is reasonably complete for a simple 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?
Schema description coverage is 100%, with each parameter (r, g, b, a, name, collectionName) already documented in the input schema. The description adds no parameter-specific meaning beyond implying color values affect the default mode. Per the baseline rule, a score of 3 is appropriate when the schema already provides full parameter documentation.
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: 'Create or update a single Figma color variable.' This is a specific verb-resource combination, and the word 'single' distinguishes it from sibling tools like create_multiple_color_variables. It also adds the update behavior for existing variables, which is 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 for single color variable creation/update, but it does not explicitly mention when to prefer this over alternatives like create_multiple_color_variables or create_paint_style. There is no explicit context for when-not-to-use or alternative tool names, so the guidance is only implied.
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 discloses that the operation creates multiple styles atomically ('at once') and that slash notation enables folder grouping. However, it does not mention potential side effects like overwriting existing styles, error handling, or return behavior. This partial disclosure merits a moderate score.
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—two short sentences that front-load the core purpose first and then provide a practical usage tip. Every word earns its place, with no redundancy or 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?
Given the tool's simplicity (one array parameter, fully described in the schema) and the absence of an output schema, the description adequately covers the essential context: what it does (creates multiple styles at once) and how to use naming for grouping. It does not explain return values or failure modes, but for a batch creation with no outputs specified, this is a reasonable level of completeness.
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 covers all parameters with descriptions, but the description adds semantic value beyond the schema by explicitly explaining that '/' in names creates folder grouping. This directly enriches the meaning of the 'name' parameter, going beyond the baseline set by the schema's example (which includes a slash but does not explain its grouping function).
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: 'Create multiple color styles (paint styles) in Figma at once.' The verb 'Create' with a specific resource ('multiple color styles') and the qualifier 'at once' distinguish it from the singular `create_paint_style` and other sibling tools like `apply_paint_style` 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a specific usage tip: 'Use folder notation with '/' in names for grouping.' However, it does not explicitly state when to choose this tool over `create_paint_style` or other alternatives. The 'at once' implies batch usage, but the guidance is implied rather than explicit, warranting a mid-range score.
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 must convey safety. The verb 'Get' implies a read-only operation, but the description doesn't explicitly state that no modifications occur. It adds useful context about the lifecycle of overrides, but falls short of disclosing error behavior, return format, or side-effect guarantees.
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 sentences, front-loaded with the action ('Get all override properties'), and no filler words. The second sentence provides valuable context about usage without 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?
For a simple getter with one optional parameter and no output schema, the description adequately conveys the tool's purpose and the meaning of 'overrides'. However, it doesn't detail the exact structure of the returned override properties, which would be helpful for agents, so it loses one point.
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% (the only parameter 'nodeId' is fully described). The description's phrase 'selected component instance' adds no new meaning beyond the schema. Since the schema already documents the parameter well, 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 uses a specific verb ('Get') and resource ('override properties from a selected component instance'), clearly distinguishing it from the sibling tool 'set_instance_overrides'. It also explains the broader purpose of applying overrides to other instances, adding context beyond the name.
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 usage context: 'These overrides can be applied to other instances' implies when you'd want to use this tool (to copy overrides). However, it doesn't explicitly mention when not to use it or name the alternative tool 'set_instance_overrides', so it lacks 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 provided, the description carries the full burden for behavioral transparency. It discloses the critical post-processing requirement, but it does not explicitly state that the tool is read-only or describe the return format. The 'Get' verb implies a read operation, but additional detail would improve 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 compact, with two impactful sentences. The first states the purpose, and the second adds critical actionable guidance without unnecessary fluff. Every sentence earns its place.
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 tool with one parameter and no output schema, the description provides essential context, especially the downstream processing requirement. It does not describe the output shape, but the guidance to use the 'reaction_to_connector_strategy' prompt compensates by telling the agent exactly what to do next.
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 fully documents the single 'nodeIds' parameter, so the description adds no additional parameter semantics. The baseline score of 3 applies because schema coverage is 100% and the description does not conflict with it.
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 action ('Get'), the resource ('Figma Prototyping Reactions'), and the scope ('from multiple nodes'). It distinguishes itself from sibling tools by focusing specifically on reactions and explicitly connecting to create_connections.
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 downstream instructions: the output must be processed by the 'reaction_to_connector_strategy' prompt and used with 'create_connections'. This is strong usage guidance, though it does not explicitly state when not to use this tool or mention alternatives.
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?
The description discloses that the tool both selects the node and scrolls the viewport, which are key behavioral side effects. With no annotations, this is useful context, though it doesn't mention error cases or permissions.
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, efficient sentence that immediately conveys the purpose and mechanism with no superfluous 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 tool, the description adequately explains the action and its effect. While there is no output schema or mention of return values, the behavior is simple enough that the agent can infer the outcome without further detail.
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 fully documents nodeId as 'The ID of the node to focus on' (100% coverage), and the description does not add additional parameter-specific details beyond the schema. Baseline 3 applies.
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 action ('Set focus on a specific node in Figma') and its mechanism ('selecting it and scrolling viewport to it'), distinguishing it from sibling tools like get_selection or set_selections.
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 you need to focus on a specific node, but it does not explicitly contrast it with alternatives like set_selections or get_selection. No exclusions or conditions are stated.
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 does disclose two behaviors: setting the selection and scrolling the viewport. However, it does not state whether the selection replaces an existing one, what happens if nodeIds are invalid, or any permission requirements. These are moderate gaps 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 that clearly communicates the core action and the side-effect. It contains no unnecessary words and earns every word's place.
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 one parameter, no output schema, and no annotations, the description adequately covers the main purpose and the viewport scroll. It is complete enough for an agent to understand how to invoke it, though it could optionally note whether the selection replaces any existing one or if there are constraints on the node IDs.
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 fully describes the single parameter nodeIds as an array of node IDs. The description adds the context that multiple nodes are selected and that the viewport scrolls, but does not add format or semantic details beyond what the schema already provides. Baseline 3 is appropriate given 100% schema 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 a specific verb ('Set selection') and clearly names the resource ('multiple nodes in Figma'). It also mentions the secondary behavior of scrolling the viewport, which adds clarity. This clearly distinguishes it from the sibling tool 'get_selection'.
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 usage context is clear: this tool changes the current selection in Figma, and the viewport scroll is a helpful side-effect. There are no explicit alternatives mentioned, but the purpose is self-evident. It lacks explicit when-not conditions, but for a simple setter tool, the context is sufficient.
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 discloses that the tool can both create and update, and that '/' creates groups, which adds value beyond the schema. However, it omits important behaviors such as whether updates overwrite existing variables, what happens if the collection does not exist, and any error or return 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 extremely concise, consisting of two short sentences. The main action is front-loaded, and each sentence provides distinct value with no filler 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 batch operation with a nested parameter array and no output schema, the description covers the essential action and grouping behavior. However, it lacks details about update semantics, collection creation/selection, and return values, making it minimally adequate but not comprehensive.
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 description coverage is 100%, so the baseline is 3. The description adds a clear grouping convention ('/' in names) that goes slightly beyond the schema's example ('primary/50'), enhancing the meaning of the 'name' parameter. Thus, a slight improvement to 4 is warranted.
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 or updates multiple Figma color variables, using the specific verb 'create or update' and resource 'Figma color variables'. It distinguishes itself from the sibling tool 'create_color_variable' by emphasizing 'multiple' and 'at once', and adds a useful naming convention with '/'.
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 'at once' and inclusion of 'multiple' imply this is for batch operations, offering clear context for when to use it. However, it does not explicitly mention when not to use it (e.g., for a single variable, use create_color_variable) or name alternatives, so it falls short of the full 5.
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

cursor-talk-to-figma-mcp-local MCP server

Copy to your README.md:

[![cursor-talk-to-figma-mcp-local MCP server](https://glama.ai/mcp/servers/GEON1999/cursor-talk-to-figma-mcp-local/badges/card.svg)](https://glama.ai/mcp/servers/GEON1999/cursor-talk-to-figma-mcp-local)

Score Badge

Copy to your README.md:

[![cursor-talk-to-figma-mcp-local MCP server](https://glama.ai/mcp/servers/GEON1999/cursor-talk-to-figma-mcp-local/badges/score.svg)](https://glama.ai/mcp/servers/GEON1999/cursor-talk-to-figma-mcp-local)

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/GEON1999/cursor-talk-to-figma-mcp-local'

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