TalkToFigma

by Takeaki0817

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v0.3.5
Disambiguation4/5
Most tools map to distinct resource-action pairs, reducing ambiguity. However, 'read_my_design' overlaps heavily with 'get_selection', and 'scan_text_nodes' vs 'scan_nodes_by_types' share boundaries. Descriptions help clarify, but a few tools could be confused.
Naming Consistency4/5
The vast majority follow a clear snake_case verb_noun pattern (get_, set_, create_). The outliers are 'read_my_design' (uses 'read' instead of 'get') and 'join_channel' (a non-design operation), but overall the convention is predictable.
Tool Count2/5
At 50 tools, the server far exceeds the typical coherent range. Many tools are extremely specific (e.g., set_layout_sizing, set_item_spacing) and could be consolidated with related set* operations without sacrificing functionality. The count feels bloated and increases selection difficulty.
Completeness4/5
The toolset provides comprehensive coverage for Figma's core workflows: CRUD on nodes, styling, layout, components, variables, annotations, and export. Minor gaps exist (e.g., no vector/shape creation beyond rectangles, no direct text retrieval), but these are workable for most design automation tasks.
Average 3.5/5 across 50 of 50 tools scored. Lowest: 2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 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

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 action without mentioning any side effects (e.g., impact on child nodes), constraints (e.g., non-destructive behavior), or error conditions (e.g., invalid nodeId).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is under-specified rather than concisely informative. The single sentence merely restates the tool name, providing no additional value, which is closer to a placeholder than a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a mutation tool with no annotations and no output schema, the description is too sparse. It does not clarify whether width/height are absolute values, whether proportions are preserved, or what happens to child nodes. The 100% schema coverage helps but does not compensate for the lack of 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 covers 100% of parameters with meaningful descriptions ('New width', 'New height', 'The ID of the node to resize'). The description adds no parameter information, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Resize a node in Figma' is essentially a grammatical restatement of the tool name 'resize_node'. It adds only the context 'in Figma' but does not differentiate from sibling tools or provide any scope or specifics 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like move_node or set_layout_sizing. The description offers no context about appropriate 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.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits beyond the tool name. It merely restates the name and adds 'position', but does not mention side effects, reversibility, coordinate context, or any requirements. This is essentially a tautology and provides no additional value.
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 redundant words. It is front-loaded with the verb and resource, and every word earns its place. No extraneous details are present.
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 simple parameters, the description lacks critical context: it doesn't specify whether coordinates are absolute or relative to a parent, whether it operates on the current document, or what the resulting behavior is on child nodes. No annotations or output schema exist to fill these gaps, making the description incomplete for a mutation 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%: x, y, and nodeId each have descriptive text. The description adds no extra meaning beyond saying 'new position', which maps to x/y but does not elaborate on format or coordinate space. Baseline of 3 is appropriate since the schema carries the full burden.
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 'Move a node to a new position in Figma' clearly states the action (move) and target (node), with 'position' implying x/y coordinates later confirmed by the schema. It distinguishes the tool from siblings like resize_node and clone_node, though it doesn't explicitly differentiate from set_parent or reorder_children, which also involve moving in a hierarchical sense.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, coordinate system, or exclusions. The only implied usage is for moving a node spatially, but the description does not state this explicitly or address alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Create a new frame' without mentioning side effects, required permissions, or return behavior, leaving significant transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, achieving maximal conciseness. It is appropriately front-loaded and to the point.
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 high complexity (20 parameters, nested objects, no output schema) and lack of annotations, the one-line description is insufficient. It fails to provide context about frame creation defaults, auto-layout behavior, or what happens after creation.
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 all parameters, including nested objects and enums, so the schema fully documents parameter semantics. The description adds no extra parameter information, making the baseline score of 3 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 clearly states the action ('create') and the resource ('frame'), which distinguishes it from sibling tools like create_rectangle and create_text. However, it lacks any scope or context (e.g., where the frame is created), so it is clear but not highly specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions, prerequisites, or contextual cues. It simply states the action without any usage instructions.
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 'create', which implies mutation but doesn't disclose side effects like where the node is placed, whether it requires a current page, how parentId affects behavior, or any default styling. This is insufficient for a tool with 8 parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no filler words or redundancy. It is concise and front-loaded, stating exactly the action and object. There is no unnecessary elaboration, which is ideal for a simple tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, nested objects, no output schema, no annotations), the description is far too minimal. It doesn't explain coordinate system, default font size, how parentId works, or what the tool returns. The description alone is inadequate for an agent to successfully invoke the tool in varied contexts.
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 (e.g., 'X position', 'Y position', 'Text content'). The description adds no parameter-level meaning, but per the rubric, with high schema coverage, a baseline of 3 is appropriate. The description doesn't compensate for any gaps but doesn't need to given the schema's coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new text element in Figma' clearly states the action (create) and resource (text element), which is specific enough to convey the tool's basic purpose. However, it doesn't distinguish from sibling tools like create_rectangle or set_text_content, only implying a difference through the word '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. It doesn't mention scenarios where create_rectangle or set_text_content would be preferred, nor does it explain prerequisites like needing a parent node or document context. The description simply states what it does, leaving usage entirely 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that joining occurs, but does not reveal side effects (e.g., subscribing to updates, changing current state), authentication needs, what happens if the channel does not exist, or what the return value is. This lack of transparency is significant for a state-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler words. It is front-loaded with the verb and resource. While brief, it is not so long as to be wasteful, and the structure is easy to parse. It earns its place by conveying the core purpose, though it could be expanded with more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's single parameter, lack of output schema, and no annotations, the description is expected to provide clear context about the operation's behavior and use case. It fails to explain what joining a channel achieves, whether it is a prerequisite for other operations, or any expected outcomes. This incompleteness makes it difficult for an agent to use the tool correctly without additional assumptions.
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 a description for the 'channel' parameter ('The name of the channel to join'), and schema description coverage is 100%, so the baseline is 3. The description text adds no additional meaning or context beyond what the schema already states, so it does not elevate the score.
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 (join) and resource (a specific channel), with a stated intent ('to communicate with Figma'). It distinguishes itself from the majority of sibling tools, which are design manipulation tools, by focusing on channel joining. However, the phrase 'communicate with Figma' is somewhat vague and could be more explicit about what joining a channel entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or the consequences of joining a channel. There is no reference to other tools, and no indication of whether joining is required for certain operations, which leaves the agent without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'scan' without disclosing whether this is read-only, whether it recurses through all descendants, or what the output shape is. This lack of behavioral detail 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 compact sentence with no wasted words, but it is under-specified; it does not explain recursive scope or return value, so it is concise but not fully informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and only one parameter, the description should explain what 'scan' produces and its scope. It fails to mention whether it returns text contents or merely node references, making it incomplete for an agent to predict tool 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 covers 100% of the single parameter 'nodeId' with description 'ID of the node to scan'. The tool description's 'selected Figma node' loosely maps to nodeId but adds no new semantic detail 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 clearly states the action ('scan') and the resource ('all text nodes') with a scope ('in the selected Figma node'). However, it does not explicitly differentiate from sibling tool 'scan_nodes_by_types' or describe what 'scan' returns, so it stops short of a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'scan_nodes_by_types' or 'get_node_info'. No mention of intended use cases or exclusion scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure, but it only states the action without explaining side effects, idempotency, whether an existing annotation is overwritten, or any required permissions. This is minimal and not much more than the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loading the essential action in a single phrase. It contains no fluff, though it could arguably include a bit more context without losing 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?
For a tool that can create or update with optional properties, the description is underspecified. It lacks information about required fields, behavior toward existing annotations, return values, and edge cases, and there is no output schema to compensate.
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 five parameters. The description adds no further semantic detail beyond the schema, hence the baseline 3 applies.
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 clear verb-resource structure ('Create or update an annotation') and implies the update capability via annotationId. It distinguishes itself from read-only siblings like get_annotations and batch set_multiple_annotations, though it doesn't explicitly name them.
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 such as set_multiple_annotations for bulk operations. There are no stated prerequisites, edge cases, or conditions that would make this tool the preferred choice.
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 bears the full burden of disclosing behavioral traits. It only mentions 'parallelly' (implying concurrency) but does not state whether replacements are atomic, what happens on partial failure, or any requirements about the node structure. This is insufficient for a mutating 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, short sentence and gets to the point quickly. However, 'parallelly' is a non-standard word that adds little and could confuse; otherwise the structure is clean and efficient.
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 absence of an output schema and annotations, the description is somewhat thin. It communicates the batch aspect and scope, but does not elaborate on the replacement behavior, error handling, or what response to expect. For a tool of moderate complexity, it is minimally viable but lacks depth.
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 descriptive text for both parameters (nodeId and text). The description adds no additional meaning 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.
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'), the resource ('multiple text contents'), and the scope ('in a node'). It distinguishes itself from the sibling tool 'set_text_content' (singular) by indicating multiple, though the adverb 'parallelly' is slightly awkward.
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 explicit guidance is provided on when to use this tool versus alternatives such as 'set_text_content' for single updates. There are no conditions, exclusions, or references to sibling tools, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is terse and provides no behavioral details beyond the word 'delete'. Since no annotations are present, the description carries the full burden of disclosing that this is a destructive, likely irreversible operation that may also delete child nodes. No such context is provided.
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 wasted words. It immediately conveys the core action and resource, making it an appropriately sized and concise description for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is minimally viable. However, it lacks any mention of the destructive and permanent nature of the operation, which is arguably essential context for a delete tool. It is adequate but has clear gaps in behavioral disclosure.
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 full coverage for the single parameter 'nodeId' with a clear description. The tool description adds no additional parameter semantics, so it earns the baseline score of 3 without enhancing or reducing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('delete') and the resource ('a node'), and it specifically targets a single node, which distinguishes it from the sibling tool 'delete_multiple_nodes' by implication. However, it doesn't explicitly name the sibling or clarify the single-vs-multiple distinction, so it stops slightly short of full distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'delete_multiple_nodes'. The description is purely definitional and does not offer any context about appropriate scenarios, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing side effects. It only states 'Clone an existing node' without mentioning default position, parent, selection, depth of clone, or return value. This is minimal behavioral disclosure for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant wording. It is front-loaded and contains only the necessary information to convey the tool's 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?
Despite adequate schema coverage, the tool is a mutation that creates a new node and has no output schema. The description fails to mention what the tool returns (e.g., new node ID), default placement behavior, or parent context. This incomplete guidance could leave an agent uncertain about post-clone actions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all three parameters (nodeId, x, y) with 100% coverage, so the description adds no additional parameter semantics. Baseline 3 applies as the structure 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 the specific verb 'clone' with the resource 'node', clearly distinguishing from sibling tools like create_rectangle, delete_node, and move_node. It unambiguously states the core action of duplicating a node in Figma.
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 clone_node versus alternatives such as create_rectangle or create_component_instance. There is no mention of prerequisites, use cases, or exclusions, leaving the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for behavioral disclosure. It only states 'create' with no details about side effects, required permissions, return values, or failure behavior. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no extraneous words. It efficiently communicates the core purpose without wasted text.
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?
Although the parameter schema is complete, the description provides no information about the return value, default parent behavior, or any constraints. Without an output schema, the description should clarify what the tool returns, but it doesn't, leaving the tool underspecified for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all parameters, achieving 100% coverage. The 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 a specific verb ('Create') and resource ('rectangle') within Figma, distinguishing it from sibling tools like create_frame and create_text. It provides a straightforward and unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites, conditions, or exclusions mentioned. The sibling tools exist but the description offers no comparative 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?
The description suggests annotations can be retrieved for the entire document or a specific node, but the input schema requires nodeId, implying only node-specific retrieval. This is misleading. No additional behavior is disclosed, such as return format, pagination, or error conditions. With no annotations provided, the description carries full transparency burden and fails to provide accurate details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence and is efficient. However, the phrasing 'current document or specific node' introduces ambiguity that could have been avoided, making it slightly less precise but still 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?
With no annotations, no output schema, and a simple parameter list, the description should be more complete. The misleading scope ('current document') and lack of any detail about return values or edge cases leave significant gaps. The tool is not adequately specified for an agent to use confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. However, the description adds confusion about the required nodeId by mentioning 'current document' as an option, which contradicts the schema's required field. It also does not clarify the includeCategories parameter, providing no additional value.
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 gets annotations, with a specific verb ('Get'), resource ('annotations'), and scope ('current document or specific node'). It distinguishes itself from sibling tools like set_annotation and set_multiple_annotations, which are write operations.
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 intended use is implied: use this tool to retrieve annotations. No explicit guidance is given about when to use this versus other get tools (e.g., get_node_info) or set tools. There is no mention of exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It indicates a read operation ('Get') but does not mention what happens if nothing is selected, whether errors can occur, or what 'detailed information' includes in terms of return structure. This is insufficient for a tool with no annotation safety signals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy. It efficiently communicates the core purpose without wasting words, earning full marks for conciseness.
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 read tool with no parameters and no output schema, the description gives the essential context of operating on the current selection. However, 'detailed information' and 'all node details' are vague, and the lack of an output schema means the agent has no idea of the return shape. It is minimally viable but leaves gaps in expectations.
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 baseline for zero-parameter tools is 4, and the description does not need to add parameter-level detail. It stays out of the way, making the tool easy to invoke with no arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get detailed information') and the resource ('current selection in Figma'), and adds scope ('including all node details'). It is distinguishable from siblings like get_selection (which likely returns only selection IDs) and get_node_info (which targets a specific node), but it doesn't explicitly name alternatives, so it loses a point for not fully differentiating.
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 get_selection or get_node_info. There are no explicit use cases, exclusions, or references to sibling tools, leaving the agent without contextual direction on 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 full responsibility for behavioral disclosure. It only states the action and target but does not clarify whether the scan is recursive, what the return value looks like, or any side effects (likely none). The absence of such details leaves the agent uncertain about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's function without unnecessary words or filler. It is front-loaded and easily scannable.
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 compensate. It fails to explain the result format, traversal depth, or any edge cases. The description is too minimal to fully contextualize the tool's behavior, especially for a scanning operation that could return multiple matches.
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 descriptions for both parameters are complete and explicit, covering 100% of the parameter semantics. The description adds no additional meaning beyond what the schema already provides, so a 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 'scan' and the resource 'child nodes with specific types', making the tool's purpose immediately understandable. It distinguishes itself from the sibling tool 'scan_text_nodes' by being generic about node types, implying this covers any node type rather than only text 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 this tool compared to alternatives like 'scan_text_nodes' or 'get_node_info'. There is no mention of suitable scenarios, limitations, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Set', implying mutation, but does not state whether the operation is reversible, how the optional 'corners' array affects behavior (e.g., whether all corners are rounded by default), or whether any node type is valid. 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 concise sentence with no unnecessary words. It's front-loaded with the action and object. Perfectly sized for a simple setter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool modifies a node, but the description lacks context about the optional 'corners' behavior, default values, or return value. Since there is no output schema and no annotations, the description should clarify these details. The single sentence leaves the agent uncertain about edge cases, making it incomplete for a tool with a nuanced optional parameter.
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 explains nodeId, radius, and corners. The description adds no additional meaning beyond the tool name. Baseline for high coverage is 3, which is appropriate here since the description doesn't clarify parameter interactions (e.g., what happens if corners is omitted).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set the corner radius of a node in Figma', using a specific verb ('set') and resource ('corner radius of a node'). This distinguishes it from sibling tools that set other properties like fill color or stroke color. While it doesn't mention the optional corners parameter, the core purpose 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 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 vs alternatives, no prerequisites (e.g., node must be a frame or have a radius property), and no exclusions. It only states what it does, leaving the agent to infer context from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It implies a mutation ('Set') but does not explain the effect on existing defaults, reversibility, or side effects. The qualifier 'copied' adds a constraint but does not clarify why a copy is required or what happens to the original.
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 words. It efficiently conveys the core action and the key constraint, earning a top score for conciseness.
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 simplicity (1 parameter, no output schema, no annotations), the description covers the basic action and parameter but lacks sufficient context about the meaning of 'default connector' and the significance of 'copied.' It is adequate but has clear gaps that could confuse an agent.
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 'connectorId' as 'The ID of the connector node to set as default' (100% coverage). The description adds the crucial constraint that the node must be a 'copied' connector node, which is not in the schema, thus providing additional semantic meaning for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Set a copied connector node as the default connector.' It uses a specific verb and resource, and the phrase 'default connector' distinguishes it from other set_* tools. However, it does not elaborate on what 'default' means or explicitly differentiate it from potential alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., must the node be copied first?), context where this is appropriate, or exclusions. The description simply states the function 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?
No annotations are provided, so the description carries the full burden. It only says 'get detailed information' without disclosing behavior such as read-only guarantees, batch size limits, potential latency, or what 'detailed' includes. There's no mention of return format or 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, front-loaded sentence with no fluff or repetition. It earns its place by stating the core action and object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple read operation with one parameter and no output schema. The description adequately conveys the purpose and the fact that it handles multiple nodes, but it omits any details about the response format or limitations. Given the lack of annotations and output schema, this is a minimally viable but not rich description.
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 nodeIds described as 'Array of node IDs to get information about'. The description adds the word 'multiple' but doesn't provide further semantics beyond what the schema already states. Baseline 3 is appropriate when the schema handles the 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 states a specific verb ('get') and resource ('nodes in Figma'), and explicitly says 'multiple' to distinguish from the sibling tool get_node_info. It clearly conveys 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 on when to use this tool versus alternatives such as get_node_info or get_document_info. The description does not mention any context, prerequisites, or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full burden of behavioral disclosure. It only mentions that the node can be TextNode or FrameNode, but fails to disclose what happens for other node types, whether this replaces existing fills, or how the optional alpha parameter affects behavior. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous words, and it front-loads the action. The sentence structure is slightly awkward ('can be TextNode or FrameNode'), but it remains concise and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five parameters, no annotations, and no output schema, the description is too minimal. It omits information about return values, error handling, whether the operation is destructive, and how it interacts with existing fills. The schema covers parameters but not the broader context needed for safe 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 full descriptions (100% coverage) for all five parameters, so the baseline is 3. The description adds no additional parameter meaning beyond restating 'fill color', which is already implied by the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Set the fill color of a node in Figma' and specifies the resource types it applies to ('TextNode or FrameNode'). This distinguishes it from the sibling set_stroke_color tool, which deals with stroke color instead.
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 when to use the tool: whenever you need to set the fill color on a text or frame node. However, it provides no explicit guidance on alternatives, exclusions, or when not to use it, leaving the context to be inferred.
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 simply states 'Set' but does not disclose behavioral traits such as whether wrap is ignored when layoutMode is NONE, if child positions are recalculated, or any permissions/side effects. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no wasted words, front-loaded with the action and target. It 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.
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 no output schema and no annotations, the description is minimal but lacks important behavioral context. It does not explain return behavior or edge cases, and the absence of alternative guidance makes it only partially complete for selecting among many set_* siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description redundantly mentions 'layout mode and wrap behavior' which maps directly to layoutMode and layoutWrap, but adds no deeper meaning beyond the schema's own property descriptions.
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') with a clear resource ('a frame') and scope ('layout mode and wrap behavior'). It distinguishes itself from sibling tools like set_layout_sizing or set_item_spacing by naming the exact properties it modifies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the many sibling set_* tools (e.g., set_padding, set_axis_align). It also lacks exclusions or alternative tool mentions, leaving the agent to infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only adds 'parallelly' as a vague timing hint and fails to explain whether annotations are added, replaced, or updated, what permissions are needed, or any side effects. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that gets to the point. However, the word 'parallelly' is awkward and 'in a node' is somewhat vague, so it is not as polished as it could be, but it remains compact.
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 sets multiple annotations, which involves a batched operation with nested parameters, but the description gives no context on how the operation behaves (e.g., whether existing annotations are overwritten, if atomicity is guaranteed, or what 'parallelly' means in practice). No output schema exists, so the description should clarify return behavior but does not, making it 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 description coverage is 100%, so the baseline is 3. The description itself adds no parameter semantics beyond what the schema already provides, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Set' and resource 'multiple annotations' in a node. It clearly distinguishes from the sibling 'set_annotation' by emphasizing 'multiple' and 'parallelly', making its 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 mention of 'multiple' and 'parallelly' implies this is for batch operations, but there is no explicit guidance on when to prefer this over 'set_annotation' or any alternative, or when not to use it. 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only restates the operation and gives no details about return format (binary, URL, base64), permissions/exportability constraints, or how omitted optional parameters behave. This leaves the agent with significant uncertainty about the tool's actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential verb and object without unnecessary elaboration. The phrase 'from Figma' is slightly redundant but not distracting, and the overall structure is clean and immediately scannable.
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, and the description does not explain what is returned, what happens when optional parameters are omitted, or whether certain node types are exportable. The schema covers parameter names and enums, but key contextual details required for correct invocation are 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?
All three parameters are fully described in the input schema (100% coverage), so the description does not need to add much. It also adds no additional parameter meaning beyond what the schema already 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 operation (export), the resource (a node), and the result (an image). It distinguishes itself from sibling tools that read metadata or edit the document; no other sibling focuses on exporting a node as an image.
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 intended use is implied by the verb 'export' — use it when you need an image representation of a node. However, there is no explicit when/when-not guidance or mention of alternative tools, so the usage context remains implicit rather than fully 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. It does not disclose behavioral traits such as whether the node must already be an auto-layout frame, whether unspecified padding values remain unchanged, or what happens on error. 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, front-loaded sentence with no filler. It conveys the essential purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has five parameters and no output schema, and the description is minimal. It does not explain prerequisites (auto-layout frame), behavior for partial input, or potential errors. The schema helps but the description remains incomplete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with meaningful descriptions, so the description does not need to add much. It simply refers to 'padding values' without elaborating on units, defaults, or behavior when individual paddings are omitted. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the target ('padding values for an auto-layout frame in Figma'). It is specific and distinguishes from sibling tools like set_item_spacing or set_layout_mode.
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 auto-layout frames, which gives context, but it does not explicitly state when not to use it or mention alternatives. It lacks clear exclusionary guidance, so it falls between implied usage and clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries a full burden for behavioral disclosure. It mentions a prerequisite (node cannot already be a component, set, instance, or nested inside one) and states the return (new component ID), but it does not disclose whether the operation mutates the node, is reversible, requires special permissions, or what error conditions may arise. 'Convert' implies mutation but leaves the effect on the original node ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the primary action. It efficiently covers purpose, constraints, and return value without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter conversion tool, the description covers purpose, eligibility constraints, and return value, which is minimally viable. However, since it is a mutation with no annotations or output schema, it should also address permissions, reversibility, and potential error conditions to be fully complete. This is a clear gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents nodeId with full clarity ('The ID of the node to convert into a component'), and the description adds no additional parameter meaning. With 100% schema coverage, a baseline of 3 is appropriate; the description does not need to elaborate 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 a specific action ('Convert an existing node into a component') and resource, with a scoping constraint on node eligibility. It distinguishes itself from sibling tools like 'create_component' by emphasizing conversion of an existing node rather than creation from scratch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: use this when you have an existing node to convert into a component. However, it does not explicitly compare with alternatives like 'create_component' or 'create_component_instance', nor provide guidelines on when to prefer this tool. The constraints about node types are preconditions, not usage selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only restates the tool's purpose and does not explain side effects, whether existing connections are overwritten, error handling, or the fact that the default style can be configured via set_default_connector. The behavioral transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. It efficiently communicates the action, target, and a key qualifier without wasting space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is adequate for basic invocation, but it omits relevant context such as how the default connector style is determined and whether the tool validates node existence. The lack of an output schema and annotations increases the burden, so gaps remain.
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 the input schema already providing descriptions for connections, startNodeId, endNodeId, and text. The description adds no parameter-specific meaning, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Create connections between nodes') and includes a qualifying detail ('using the default connector style') that distinguishes it from style-related siblings like set_default_connector. It clearly states 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 phrase 'using the default connector style' implies this is the go-to tool for default-styled connections, but it does not explicitly state when to use it versus alternatives, nor does it mention when not to use it. There is no mention of prerequisites or exclusions, leaving usage context mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'detailed information' without elaborating on what is included, the return format, potential side effects, or failure modes. The vagueness limits transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. Every word is useful, and there is no unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimally viable for a simple parameterless getter, but 'detailed information' is vague. Without an output schema, the agent is left guessing what fields or structure the response will have, leaving a clear gap.
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 schema coverage is trivially 100%. There is nothing to explain about parameters; the description adds the scope ('current document'), which is sufficient for a parameterless call.
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', the resource 'current Figma document', and the scope 'current' to distinguish it from node-level siblings like get_node_info or get_selection. It is specific and immediately clear what the tool operates on.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or preferred scenarios, leaving the agent without explicit context for selection among many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Get detailed information' without specifying what information is returned, whether the operation is read-only, or any error behavior or permissions. This is minimal disclosure for a getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. It contains no filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, but the description does not clarify what 'detailed information' includes. This leaves some ambiguity about the return payload, though it is adequate for a basic getter.
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 nodeId ('The ID of the node to get information about') with 100% coverage. The description adds no additional meaning beyond the schema, 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 uses a specific verb 'Get' and identifies the resource as 'a specific node in Figma', making it clear that this tool retrieves information for a single node. This distinguishes it from siblings like get_nodes_info (plural) and 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the phrase 'specific node', suggesting it is for single-node lookups. However, no explicit when-to-use or alternatives are mentioned, such as using get_nodes_info for multiple nodes or get_document_info for the whole document.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'set' without detailing side effects, such as whether existing alignment values are overwritten, what happens if the frame is not auto-layout, or any permission requirements. The SPACE_BETWEEN note is in the schema but not in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is appropriately concise and front-loaded with the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but sufficient for a simple setter given the complete schema. However, it lacks behavioral transparency and explicit usage guidance, and with no output schema it does not mention return values. The overall context is adequate but not rich.
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 parameters are well-documented. The description adds no extra parameter semantics beyond what the schema already provides, but it does not need to because the schema is thorough.
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: setting both primary and counter axis alignment on an auto-layout frame. It uses a specific verb ('set') and identifies the target resource ('auto-layout frame'), distinguishing it from sibling tools like set_item_spacing or set_layout_mode.
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 for auto-layout frames ('for an auto-layout frame'), but it does not explicitly state when to use it over alternatives, nor does it mention prerequisites or exclusions. No mention of alternatives like set_layout_mode.
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 disclosing behavioral traits. It only states 'Set the stroke color', which implies mutation, but does not disclose whether the operation overwrites existing stroke settings, requires specific node types, or is reversible. No side effects or permissions are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded with the action and target. Every word is necessary and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema fully documents parameters, the description lacks contextual details such as the optional weight parameter (not mentioned), effects on existing stroke properties, or any prerequisites. For a simple mutation tool, the description is adequate but leaves some gaps that could impact correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all six parameters (nodeId, r, g, b, a, weight), giving 100% coverage. The description itself adds no parameter-specific meaning beyond what the schema already offers, 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 'Set' with a clear resource ('stroke color') and object ('node in Figma'), immediately distinguishing it from sibling tools like set_fill_color. It fully communicates the tool's primary function.
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 stroke color needs to be changed, but provides no explicit guidance on when to use this tool versus alternatives such as set_fill_color or set_corner_radius. There are no usage exclusions or context hints.
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 exist, so the description must fully disclose behavior. It only restates the tool's name and scope, without mentioning return format, limitations (e.g., whether library styles are included), or any characteristics beyond the read-only nature implied by 'get'.
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 wasted words. It conveys exactly what the tool does in the most efficient form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description adequately covers the core function. It would benefit from clarifying what constitutes 'styles' (e.g., text, color, effect) but is sufficient for a straightforward get-list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description adds meaningful scope by specifying 'from the current Figma document'. This provides context that the schema (with no properties) cannot, earning the baseline 4 for parameterless tools.
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 'styles', specifying 'all styles' and 'from the current Figma document'. This distinguishes it from sibling tools like get_local_components or get_variables, as no other tool targets styles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no context about which scenarios call for it. It is a bare statement of function without 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, the description carries the full burden. It mentions the mechanism (moving to a new index) but does not disclose side effects (e.g., index shifting), error behavior for out-of-bounds indices, 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?
The description is a single, concise sentence that clearly communicates the operation without waste. It is front-loaded with the main purpose.
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 reorder operation with fully documented parameters, the description is largely complete. The main gaps are usage guidance and behavioral details, which are partially captured by other dimensions, but the overall context is adequate.
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 each parameter described, so the description adds little beyond what the schema already provides. It does not clarify index bounds or relationships beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action (reorder), the resource (child node), and the scope (within its parent's children array), which distinguishes it from siblings like move_node that likely move nodes across parents.
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 context implies reordering within the same parent, but there is no explicit guidance on when to use this tool versus alternatives like move_node, nor 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 must carry the full burden. It only says 'Set...sizing modes' and does not disclose any side effects, prerequisites beyond the auto-layout frame mention, or failure behavior. For a mutation tool with no annotation coverage, 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 that front-loads the action and object, with no redundant or filler text. It is highly concise and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool modifies design state (mutation) with no annotations or output schema, yet the description provides only the bare action. It omits important context like the meaning of HUG/FILL, edge cases, or what happens if the node is not an auto-layout frame. This sparse coverage makes the tool underspecified for correct invocation in complex scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides comprehensive descriptions for all three parameters, including enum value constraints, so the description need not explain them. The description adds no additional parameter-level meaning, so it rests at the baseline 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 the tool sets both horizontal and vertical sizing modes on an auto-layout frame, identifying the specific resource and action. It distinguishes from siblings like set_layout_mode which controls layout direction, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description identifies the target context (auto-layout frame) which gives clear context for when to use this tool. However, it does not explicitly name alternatives or exclusions, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose side effects. It only states the action, with no warning about irreversibility, partial failures, or permissions. This is insufficient for a destructive 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?
One sentence, clearly front-loaded with the action and resource. No fluff.
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 it's a destructive batch operation with no annotations or output schema, the description should at least mention whether the deletion is atomic or any prerequisites. It doesn't, so it's minimally viable but not 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 fully documents the nodeIds parameter with description 'Array of node IDs to delete'. The description adds nothing beyond the schema, 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 clearly states the action (delete), the resource (nodes in Figma), and the scope (multiple at once). It distinguishes from sibling delete_node by emphasizing 'multiple' and 'at once'.
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 implies this is for deleting multiple nodes in a single call, which is a clear usage context. However, it doesn't explicitly contrast with delete_node for single-node deletions, so there is no exclusion 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 full responsibility for behavioral disclosure. It only states the basic action and does not describe what information is returned, behavior when no selection exists, or whether it is read-only (beyond the 'get' verb). This is a significant gap 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, front-loaded sentence with no filler. Every word contributes to the meaning.
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 low complexity, the description is minimal but vague, using the generic term 'information' without specifying the return structure or edge cases. Since there is no output schema, the description should provide more detail about what the selection information includes.
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 there is nothing to explain. The baseline score of 4 is appropriate since no parameter semantics are 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 clearly states the tool's action ('Get information') and resource ('current selection') within the context of Figma. This distinguishes it from sibling tools like get_document_info and get_node_info, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives, nor any mentioned exclusions or prerequisites. The usage is implied by the tool's name and description, but no comparative guidance is provided despite many similar getter tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states that the tool sets text content on an existing node, but does not disclose permission requirements, error behavior for non-text or missing nodes, or reversibility. This is a mutation tool and should provide more context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently states the tool's 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?
For a simple two-parameter mutation, the description covers the basic action and the existing-node precondition. However, it lacks details on failure modes (e.g., invalid nodeId, wrong node type) and any effects on styling or other properties, leaving some 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 description coverage is 100%, so both nodeId and text are already documented. The description adds minimal semantic value beyond the schema, e.g., 'text content' echoes the parameter descriptions. 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 is specific: 'Set the text content of an existing text node in Figma' uses a clear verb+resource pattern. It distinguishes itself from siblings like set_text_style (different property) and create_text (creates a new node), and from set_multiple_text_contents (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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing text node' clearly implies this tool is for modifying an existing node rather than creating one. However, it does not explicitly mention alternatives or when-not-to-use, such as pointing to set_multiple_text_contents for batch operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It states the action but does not disclose prerequisites (frame must be auto-layout), side effects (children repositioned), or error behavior if conditions are not met. The schema notes about ignored values are helpful but exist outside the description, so the description itself lacks 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, focused sentence that is front-loaded with the verb and resource. No wasted words, easily scannable, and appropriately sized for a simple setter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation with 3 well-documented parameters and no output schema, the description plus schema is largely complete. It could mention what happens if the frame is not auto-layout or return value expectations, but the current information is sufficient for basic usage.
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 each parameter has a detailed description including conditional notes (itemSpacing ignored with SPACE_BETWEEN, counterAxisSpacing works only with WRAP). The tool description adds no additional parameter-level 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 'Set distance between children in an auto-layout frame' uses a specific verb ('Set') and resource ('distance between children') with a clear scope ('auto-layout frame'). It clearly distinguishes this tool from sibling set_* tools like set_padding or set_axis_align by focusing specifically on spacing.
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 'in an auto-layout frame' provides clear context for when this tool is applicable, implying it should be used only for auto-layout frames. However, it does not explicitly mention alternatives or exclusions, though the schema notes about SPACE_BETWEEN and WRAP add conditional guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does disclose the viewport-scrolling side effect, which is useful, but it does not state whether the selection replaces the current one, how invalid node IDs are handled, or other potential effects. This is moderate 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 with no redundant information. It efficiently conveys the main action and the key side effect.
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 with no output schema, the description covers the primary action and the main side effect. It does not address edge cases like replacing existing selection or error behavior, but given the tool's simplicity, it is fairly 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 fully describes the nodeIds parameter with a clear description, achieving 100% schema coverage. The tool description adds no additional parameter-specific details, so the 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 action (set selection) and the resource (multiple nodes in Figma), and also mentions the viewport scrolling side effect. This specific verb+resource combination differentiates it from sibling tools like 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?
The description implies the tool is for programmatically selecting nodes, which gives some context, but it does not provide explicit when-to-use guidance or mention alternatives/exclusions. There is no mention of prerequisites or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It does not mention that this is a mutation operation, any permission requirements, the return value, or what happens if the component is not found. It only notes the limitation that published components 'only work' when using componentKey, which is a partial disclosure. This is insufficient for a tool that creates/modifies document structure.
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, both informative and directly relevant. The first sentence states the purpose, and the second provides the key distinction for parameter selection. No wasted words, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, 2 required, and no output schema or annotations, the description covers the main usage modes but omits important context such as what the tool returns (e.g., the created instance node), how placement works (x/y vs parentId), and any side effects. It is adequate for basic selection but not fully complete for an agent to understand the full consequences of invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying the distinction between the two component identifier parameters and reinforcing the correct usage for each. It supplements the schema descriptions by tying the two parameters together and providing a decision framework, which goes slightly beyond the structured fields.
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 an instance of a component in Figma.' It uses a specific verb and resource, and distinguishes between local and published library components, which differentiates it from sibling tools like create_rectangle or create_text. The two usage modes are explicitly described.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use componentId vs componentKey based on whether the component is local or from a published library. It also mentions the source fields (id vs publishedKey) from get_local_components. While it doesn't explicitly name alternative tools, the usage context is clear and actionable.
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 optional per-mode seeding and color format, but does not mention side effects, return value, permissions, or behavior if the variable already exists. For a mutating operation, this is insufficient 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?
Two concise sentences, front-loaded with the primary action and followed by essential parameter guidance. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Schema covers parameter semantics well, and the description provides necessary usage context. However, with no annotations and no output schema, the agent is left without information about return values or error conditions, making it moderately complete for a creation tool.
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 covers all parameters, so baseline is 3. The description adds value by explaining 'per-mode values' as the purpose of valuesByMode and directing the agent to get modeIds from specific tools, which is beyond the schema's generic 'Map of modeId -> value'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'Create a variable inside a collection'. It differentiates from sibling tools like create_variable_collection (which creates a collection) and get_variables (which retrieves modeIds).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context by instructing to get modeIds from get_variables or create_variable_collection, which is essential when using valuesByMode. It implies this is the tool for creating variables but does not explicitly contrast with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It correctly indicates a read-only 'get' operation and the 'local' scope, but it does not mention the return format, potential absence of components, or whether nested component structures are included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler or repetition. Every word adds meaning: 'all', 'local', 'components', and 'from the Figma document'.
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 zero-parameter getter, the description is fairly complete, but no output schema exists and the description does not explain what exactly is returned (e.g., an array of component nodes) or how local components are defined. It is adequate for selection but minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage. The description therefore needs no parameter details; the baseline score of 4 applies because there is nothing to clarify.
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 local components' scoped to 'the Figma document'. This distinguishes it from sibling tools like get_styles or get_variables, which target different entity 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 the tool is used when all local components in the current document are needed, but it provides no explicit guidance about when not to use it or which sibling tool to prefer as an alternative. The context is clear, but exclusion criteria are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool creates an empty component and returns its ID, which is useful, but it omits details like write permissions, document mutation side effects, failure behavior, and relationship to current selection. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the main purpose, and every sentence adds value. No fluff or repetition of structured fields.
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 large parameter set and no output schema, the description covers the core outcome (creation), return value (ID), and cross-tool parameter reference. It doesn't detail placement or parent handling, but the schema covers the parameters, and the description provides sufficient context for a create 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%, so the baseline is 3. The description adds a useful cross-reference to create_frame for Auto Layout parameters, but it does not explain parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('new empty component'), clearly distinguishing it from siblings like create_component_instance and create_component_from_node by emphasizing 'empty' and 'new'. This makes the tool's purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It clarifies usage by noting the same Auto Layout parameters as create_frame and the returned ID's utility as a parentId or for create_component_instance. However, it does not explicitly state when to prefer this tool over create_frame or create_component_from_node, nor does it provide 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?
No annotations are provided, so the description carries the full burden. It discloses the 'local' scope and the behavior of mode names (first renames default, rest added). However, it does not mention permissions, irreversibility, return values, or error conditions, which are relevant for a create tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the purpose, and the second explains the optional modes. Every sentence contributes meaningfully, with no unnecessary detail or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only 2 parameters and no output schema. The description covers the essential behaviors, including the subtle mode-handling logic. While it lacks mention of return values and safety implications, the description is adequate for a straightforward create 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% with descriptions for both 'name' and 'modes'. The description's statement about modes duplicates the schema's parameter description without adding new information. Thus, it provides no additional semantic value beyond what the schema already offers.
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 'Create a local variable collection' with a specific verb (create), resource (variable collection), and scope (local). It distinguishes from sibling tool create_variable by targeting a collection rather than a single variable. The additional detail about mode names reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool by naming the resource and explaining the optional modes behavior. However, it does not explicitly state alternatives or exclusions, such as 'use create_variable for individual variables'. Still, the purpose is specific enough to imply its usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It frames the tool as a read operation with 'Get all...' and the second sentence suggests data reuse, but it does not explicitly state that no mutations occur or describe edge cases (e.g., what if the instance has no overrides). The lack of an output schema also leaves the return format unspecified.
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 consists of two succinct sentences: the first states the primary function, and the second explains the practical value of the returned data. There is no filler or redundant detail, making it well-structured and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 covers the essential purpose and provides a usage context. It does not explicitly mention the return format or guarantee read-only behavior, but given the simplicity of the tool and the presence of set_instance_overrides as a counterpart, it is reasonably 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 has 100% description coverage for the single optional nodeId parameter, including the fallback to the current selection. The tool description does not add any parameter details beyond referring to 'a selected component instance,' so the schema already carries the semantic load.
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: 'Get all override properties from a selected component instance.' The verb 'Get' and the specific resource 'override properties' distinguish it from sibling tools like set_instance_overrides and other getter tools. The second sentence adds context about applying these overrides to other instances, which reinforces 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear use case: retrieve overrides from one instance so they can be applied to others ('These overrides can be applied to other instances...'). This provides clear contextual guidance but does not explicitly name alternatives like set_instance_overrides or state when not to use the tool. The contrast with the setting sibling is implicit but understandable.
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 takes on the transparency burden. It adds a key behavioral trait—the mandatory downstream processing step—and 'Get' implies a read-only operation, but it does not disclose return format, error behavior, rate limits, 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 two sentences, front-loaded with the core purpose and a critical follow-up instruction. Every sentence earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one required parameter) and the description gives both the purpose and a mandatory downstream workflow. It lacks an output schema or explicit return-value description, but the critical processing reference compensates for this simple getter.
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 nodeIds as an array of strings with 100% coverage, so the description adds little beyond restating the multi-node aspect. The baseline 3 applies because the schema fully captures the parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with a clear resource ('Figma Prototyping Reactions') and scope ('from multiple nodes'), distinguishing it from sibling tools like get_node_info or get_document_info. The purpose is immediately clear and specific to reactions.
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 explicitly instructs that the output must be immediately processed via the 'reaction_to_connector_strategy' prompt and then used by 'create_connections', providing strong contextual guidance. It does not mention alternative tools or scenarios where it should not be used, so it misses full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It successfully conveys a read-only operation ('List') and discloses the returned content (collections, modes, variables with specific fields and the optional filter). However, it doesn't mention any rate limits, required permissions, or what 'local' implies in contrast to other scopes, so it's slightly above baseline but not fully exhaustive.
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 entire description is one sentence that is front-loaded with the action and resource, then provides a compact list of return fields. Every phrase earns its place; there is no superfluous information or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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 (a single optional parameter, no output schema), the description is complete: it explains what is listed, the filter capability, and the specific fields returned. An agent can decide whether to invoke it and what to expect without additional 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 fully documents collectionId with 'Optional variable collection ID to filter results to', giving 100% schema coverage. The description reinforces this by saying 'Optionally filter to a single collection', but adds no new semantic detail beyond confirming the parameter's purpose. 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 opens with a specific verb, 'List', and clearly identifies the resource: 'local variable collections (with their modes) and variables'. It distinguishes itself from sibling tools like get_styles or get_local_components by explicitly scoping to variables and collections, and enumerates the returned fields (id, name, resolvedType, valuesByMode), leaving no ambiguity about its function.
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 via 'List' and 'Optionally filter to a single collection', but provides no explicit comparison to alternatives or when-to-use guidance. While it clearly indicates the action, it doesn't state when this tool is preferable over, say, get_styles or get_document_info, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the safety/behavior burden. It clearly states the mutation effect (instances swapped to source component and overrides applied), but it does not disclose reversibility, failure modes, or whether the source component is modified. This is moderate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action, and no redundant information. Every phrase 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?
Adequate for a simple 2-parameter mutation tool, but it lacks explicit information about prerequisites (e.g., how overrides were copied), return/result behavior, and edge cases like empty selections or invalid source IDs. The schema provides parameter context but does not cover these operational aspects.
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 descriptions for sourceInstanceId and targetNodeIds are basic (ID and array). The description adds semantic meaning by explaining that target instances are swapped to the source component and that copied override properties are applied, clarifying the relationship between the two parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Apply'), the resource ('previously copied overrides'), and the target ('selected component instances'). It also explains the effect (swapping to source component) which distinguishes it from sibling tools like get_instance_overrides (read-only) and create_component_instance (creation).
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 'previously copied overrides' implies a prerequisite (a copy operation must have happened) and 'selected component instances' indicates the tool acts on the current selection. This provides clear context for when to use it, though it does not explicitly name alternatives or exclusion cases.
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?
Despite no annotations, the description discloses the special behavior for 'fills'/'strokes' (binding the first solid paint's color) and the use of different underlying methods, plus the type matching requirement. It does not cover error handling or side effects, but it provides meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense paragraph that front-loads the purpose, then details special cases and constraints. No wasted words; each sentence contributes.
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 3-parameter tool with no output schema, the description covers the primary usage, supported properties, and a key constraint. It lacks explicit return-value or error information, but the operation is straightforward enough that the description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes all three parameters (100% coverage), so the baseline is 3. The description adds value by explaining which property values use which binding method and by listing the full set of supported properties, which clarifies the 'property' parameter's semantics.
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 'Bind a variable to a node property' and enumerates the specific property categories and the two distinct methods involved. This differentiates it from sibling tools that set static values or create variables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives; the description focuses on mechanics rather than decision criteria. The constraints like 'Variable type must match the property' are prerequisites but not usage recommendations.
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 burden of behavioral disclosure. It explicitly states the side effects: 'selecting it and scrolling viewport to it'. This is transparent about the tool's mutating behavior. It could add a bit more context (e.g., about errors or prerequisites), but for a simple tool this is adequate.
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 action and resource, followed by a concise explanation of how the action is performed. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 sufficiently covers what the tool does and its side effects. It lacks a few niceties (e.g., whether the node must exist or if focus is purely visual), but these are not critical for a straightforward utility.
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 fully describes the sole parameter 'nodeId' as 'The ID of the node to focus on' (100% coverage). The description's phrase 'specific node' adds no meaningful semantics beyond the schema, so a 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 tool's purpose: 'Set focus on a specific node in Figma by selecting it and scrolling viewport to it'. It uses a specific verb ('set focus'), identifies the resource ('specific node in Figma'), and explains the mechanism (select + scroll), which effectively distinguishes it from siblings 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys when to use the tool by clarifying that it both selects a node and scrolls to it, which distinguishes it from selection-only tools like set_selections. However, it does not explicitly mention alternatives or when-not-to-use scenarios, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the underlying operations (appendChild/insertChild) and the keepPosition nuance for auto-layout parents, which is valuable. However, it does not mention side effects on the previous parent, potential errors (e.g., cycles, invalid parent), or whether other node properties are preserved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place. The main purpose is front-loaded, and the remaining sentences cover implementation details and special behaviors without redundancy or fluff.
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 no output schema and no annotations, the description covers the core operation, the role of the index parameter, and the keepPosition behavior. It falls short on edge cases like invalid parent relationships or error handling, but is otherwise sufficient for a reparent operation.
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 describes all four parameters with 100% coverage. The description adds meaning by explaining that index uses insertChild (vs append) and that keepPosition is ignored for auto-layout parents. This goes beyond the schema, which only lists the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Move a node so it becomes a child of another node (reparent).' This distinguishes it from sibling tools like move_node (which likely moves position) by focusing on the parent-child relationship. Implementation details (appendChild/insertChild) further clarify the behavior.
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 implies use for reparenting and mentions that an index triggers insertChild while keepPosition works differently with auto-layout parents. However, it does not explicitly mention when not to use it or compare it to alternatives like move_node or reorder_children, so no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses partial application behavior ('Only the provided fields are applied') and automatic font loading, offering meaningful behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 params and nested objects, the description covers the key behavioral aspects (partial update, font loading) despite no output schema; could mention error conditions but overall adequate.
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 covers 100% of parameters; the description reiterates the lineHeight/letterSpacing structure and the AUTO unit special case, adding no significant new semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') with a resource ('TEXT node') and scope ('detailed typography'), clearly differentiating it from sibling tools like set_text_content (content) and other styling tools.
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 implies use for applying multiple typography attributes in one call and clarifies partial updates, but does not explicitly name alternatives or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly discloses that effects are replaced wholesale, how to clear all effects, field differences between SHADOW and BLUR, and that failures are reported clearly. This covers key behavioral traits such as destructive overwrite and unsupported-node handling, though it doesn't mention permissions or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no filler. The main action is front-loaded, followed by a usage tip, a type-specific field note, and a failure mode note. Every sentence earns its place, and the format is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema and annotations, the description fully covers the tool's complexity: replacement semantics, clearing behavior, effect-type field requirements, and error behavior. For a setter tool with a well-defined input schema, this is complete enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds concise semantic guidance beyond the schema by summarizing which fields apply to SHADOW vs BLUR effects and the clearing behavior with effects:[]. This helps the agent construct valid effects objects without reading every nested schema property, adding real value.
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 begins with a specific verb 'Replace' and resource 'effects on a node', clearly distinguishing this from other sibling tools like set_fill_color or set_corner_radius. The additional note 'assigns node.effects' confirms the underlying behavior, leaving 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 implies usage by context (replacing effects) but does not explicitly state when to use it versus alternatives or when not to use it. It gives operational tips like passing an empty array to clear, but no explicit when-to-use or alternative guidance, putting it at 'implied usage'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![figma-local-bridge MCP server](https://glama.ai/mcp/servers/Takeaki0817/figma-local-bridge/badges/card.svg)](https://glama.ai/mcp/servers/Takeaki0817/figma-local-bridge)

Score Badge

Copy to your README.md:

[![figma-local-bridge MCP server](https://glama.ai/mcp/servers/Takeaki0817/figma-local-bridge/badges/score.svg)](https://glama.ai/mcp/servers/Takeaki0817/figma-local-bridge)

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/Takeaki0817/figma-local-bridge'

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