Talk to Figma MCP

Server Quality Checklist

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

Latest release: v0.3.3
Disambiguation2/5
Several tools have overlapping purposes: get_selection and read_my_design both return selection details; get_document_info, get_node_info, and get_nodes_info all fetch node/document information. This creates confusion about which tool to select for a given task.
Naming Consistency4/5
Tool names overwhelmingly follow a verb_noun snake_case pattern (e.g., create_rectangle, set_fill_color, delete_node). Minor deviations like read_my_design and the singular/plural variation between set_annotation and set_multiple_annotations are slight but do not undermine the overall consistency.
Tool Count2/5
With 41 tools, the server feels over-scoped for a design tool. While it offers a broad range of operations, the high count increases cognitive load and overlaps, making it difficult for an agent to efficiently choose the right tool. 25+ tools is beyond the comfortable range.
Completeness4/5
The tool set covers most core Figma workflows: node creation/deletion, editing properties, annotations, components, layout, and connections. Minor gaps exist (e.g., grouping, ungrouping, or advanced vector operations), but agents can accomplish typical design tasks without fundamental dead ends.
Average 3.3/5 across 41 of 41 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool joins a channel but does not disclose whether this is a persistent state change, whether it requires authentication, how to leave the channel, or what effects it has on other operations. The phrase 'to communicate with Figma' is too vague to convey meaningful behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded with the action and resource, making it easy to scan. The brevity is appropriate for a tool with minimal parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one optional parameter, no output schema), the description is still insufficiently complete. It does not explain what a 'channel' is, what 'communicate with Figma' entails, or what the expected outcome of joining a channel is. The agent would be uncertain about how to invoke the tool correctly, especially since the parameter is marked optional in the schema but the description implies a specific channel is needed.
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% for the single parameter 'channel', which is described as 'The name of the channel to join'. The tool description adds no further semantic detail beyond the schema. Since the schema fully documents the parameter, 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'join' and the resource 'specific channel', but the purpose 'to communicate with Figma' is vague and does not clarify what a 'channel' is in this context. It does not distinguish itself from sibling tools, though none of the siblings involve channels, so confusion is minimal. Overall, the intent is partially clear but lacks specificity.
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 consequences. There is no mention of when joining a channel is appropriate or what other tools might be relevant. This 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?
With no annotations, the description carries the full burden of behavioral disclosure. It implies mutation but doesn't disclose side effects, such as whether resizing preserves aspect ratio, moves the node, or affects child nodes or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, but it largely restates the tool name and adds little beyond the name. It's concise but not information-dense enough to earn a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations or output schema, the description is too sparse. It omits any mention of return values, error conditions, or behavioral constraints, leaving the agent to infer critical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents width, height, and nodeId. The description adds no parameter-level detail, but the schema already eases that burden, warranting the baseline 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 states the tool resizes a node in Figma, which is a specific verb+resource combination. It differentiates from siblings like move_node and delete_node, though it doesn't detail what resizing entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool versus alternatives, nor any prerequisites or exclusions beyond the implicit action of resizing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden, but it only states 'create' with no disclosure of side effects, required file context, whether the frame is appended to the current page, or behavior of optional fields like parentId. This is similar to a bare mutation statement without permission or reversibility hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It's appropriately short for stating the action, though it could be slightly more informative without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 20 parameters, nested objects, and various auto-layout options, this one-sentence description is insufficient to fully understand the tool's capabilities and defaults. The schema is rich, but the description provides no overall context, expected outcomes, or constraints beyond the required parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with descriptions for all 20 parameters, so the description doesn't need to explain individual fields. The description adds no additional semantic meaning beyond what the schema already gives, so it meets the baseline but nothing more.
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 names the action (create) and the resource (a frame in Figma), conveying the core function. However, it doesn't distinguish this from sibling creation tools like create_rectangle or create_text, so it's clear but not fully differentiated.
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 creating other node types or when to set auto-layout vs plain frame. There's no mention of prerequisites, like needing a document to exist or how parentId is used, and no exclusions for alternative 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 that a node is deleted, but does not mention whether the deletion is recursive, permanent/undoable, or restricted by node type or ownership.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that immediately states the action and target. There is no redundant or extraneous 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?
The tool is destructive, lacks annotations, and has no output schema, so the description needs to provide more context about effects and when to use it. It also fails to mention the alternative delete_multiple_nodes, making the description incomplete for decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter nodeId has 100% schema coverage with a clear description. The tool description adds no meaning beyond the schema, which is acceptable given the high schema 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 'Delete a node from Figma' uses a specific verb and resource, making the core purpose clear. It implicitly distinguishes from delete_multiple_nodes by focusing on a single node, but does not explicitly call out that 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 about when to use this tool versus alternatives such as delete_multiple_nodes. There is no mention of prerequisites, such as node existence or permissions.
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 implies a read operation via 'Get' but doesn't disclose what 'current document' means, whether it requires an open document, or the structure of the returned data. No behavioral traits beyond the basic read implication are shared.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and very concise, but it omits substantive details that could make it more structured or informative. It earns its place but is under-specified, lacking a clear outline of what 'detailed information' includes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description should explain what 'detailed information' includes, the return format, and how 'current document' is determined. It does none of this, leaving the tool's behavior underspecified.
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 of 4 applies because no parameter semantics are needed; the description does not add or omit essential parameter context.
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 'Get' and names the resource 'current Figma document,' distinguishing it from node-level tools like get_node_info and selection tools like get_selection. However, 'detailed information' is vague about the scope of details, so it does not fully specify what is returned.
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 siblings like read_my_design or get_node_info. There are no usage contexts, prerequisites, or exclusions, leaving the agent to guess when this is the right 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, the description carries full responsibility for disclosing behavior. 'Get detailed information' is vague—it does not specify what fields are returned, whether invalid node IDs cause errors, or if the operation is read-only. The tool is not destructive, but the description lacks meaningful behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It directly states the tool's function without redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and no output schema, so the description needs to explain return values or behavior. 'Detailed information' is too vague—there is no mention of what the response contains, how it differs from get_node_info, or any constraints (e.g., maximum node count). This is insufficient for an agent to fully understand the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (nodeIds is described as an array of node IDs). The description adds no extra parameter information beyond what the schema provides, so the baseline of 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 clearly states the tool fetches detailed information for multiple nodes in Figma. The plural 'nodes' distinguishes it from the sibling get_node_info, though it doesn't explicitly name the alternative.
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 get_node_info or other sibling tools. The plural 'nodes' implies a batch use case, but there is no explicit direction or exclusion, leaving the agent to infer.
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 adds no behavioral context beyond the bare action: no mention that it can update existing annotations (via annotationId), no detail on whether annotations are added or replaced, no concurrency semantics despite saying 'parallelly', and no side effects. The term 'parallelly' hints at execution behavior but is too vague to be informative.
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 fluff. It is front-loaded with the verb and resource. However, 'parallelly' is slightly awkward and could be replaced with a clearer adverb like 'in parallel', but overall it is efficient and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only two top-level parameters, the 'annotations' array is a nested structure with multiple properties and optional update semantics. The description does not explain that annotationId is for updating existing annotations, nor does it clarify the relationship between the container node and target nodes. With no output schema or annotations, the description leaves significant gaps for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, so baseline is 3. The description does not elaborate on the 'annotations' array structure or explain how the top-level nodeId differs from the per-item nodeId. It only adds 'parallelly', which weakly relates to the array parameter. The schema already provides adequate property descriptions, so the description adds minimal extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Set') and the resource ('multiple annotations'), and the phrase 'in a node' gives a scope. It distinguishes from the sibling 'set_annotation' by emphasizing 'multiple', so the agent can infer this is the batch variant. However, 'parallelly' is atypical phrasing and the exact relationship between the top-level node and the per-annotation nodeId could be clearer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus the singular 'set_annotation' or other annotation-related siblings. It does not state that this tool should be used when setting multiple annotations in a single call, nor does it mention any alternatives or exclusions. The phrase 'multiple' is the only implicit hint, but that is not enough 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 of behavioral disclosure. It only indicates a mutation ('Set') but does not disclose potential side effects, required node types, permissions, or reversibility. The minimal wording adds no transparency beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is succinct and front-loaded. It conveys the essential action and resource without unnecessary words or repetition, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, the description is insufficiently complete. It does not explain when to use the tool, what node types support strokes, or how the operation behaves (e.g., whether it overrides existing strokes). The one-sentence description leaves significant gaps 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 descriptions cover all 6 parameters (100% coverage), so the baseline is 3. The description itself does not add any extra semantic meaning; it just relies on the schema's existing parameter descriptions, which are adequate. No additional context is needed beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set the stroke color of a node in Figma' clearly states the action (set) and the resource (stroke color of a node). It is specific and unambiguous. However, it does not distinguish from sibling tools like set_fill_color, so it lacks sibling differentiation.
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 (e.g., set_fill_color) or any contextual requirements. There is no mention of prerequisites or exclusions, leaving usage entirely implied by the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden of disclosing behavioral traits. It only states the action and fails to mention side effects, required permissions, error behavior, or impact on the document. This is a significant transparency gap for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It conveys the core action efficiently and appropriately sized for a simple operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simple action, the description lacks contextual completeness because it does not explain when to use the tool, what the instance creation implies, or any behavioral caveats. With no annotations or output schema, the description is insufficient for an agent to fully understand the tool's behavior and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for all three parameters (x, y, componentKey). The tool description adds no additional parameter semantics, 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 ('Create') and resource ('an instance of a component') with the context 'in Figma', clearly distinguishing it from sibling tools like create_rectangle or create_frame. It unambiguously 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description only states the action without mentioning prerequisites, when it should be preferred, or when other creation tools should be used instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action ('get') without revealing side effects, read-only nature, permissions, or response format. Moreover, the description says 'current document' while the input schema requires 'nodeId', creating ambiguity about how document-level retrieval works, which is a transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the primary action and scope with no filler words. It is appropriately concise and earns its place, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and only two simple parameters, the description is still incomplete. It fails to explain the relationship between nodeId and document-level retrieval, leaves the behavior of includeCategories unmentioned, and does not indicate what the return value contains. The tool is simple, but the description leaves critical ambiguities unresolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters. The description attempts to add the 'current document or specific node' concept, but this conflicts with the schema's required 'nodeId'. It does not clarify how to request document-level annotations (e.g., a special nodeId value), and it says nothing about 'includeCategories', leaving parameter semantics less clear than the schema alone.
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 all annotations') and specifies the scope ('current document or specific node'), which distinguishes it from write tools like set_annotation. However, it does not explicitly differentiate from other getter tools (e.g., get_document_info, get_node_info), so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: you would use this when you need to retrieve annotations, either document-wide or for a specific node. However, it provides no explicit exclusions, alternatives, or conditions (e.g., when to use set_annotation instead), leaving the 'when vs. alternatives' guidance implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of transparency. It merely says 'detailed information' without specifying what fields are returned, whether the operation is read-only (though the name implies it), or any limitations or side effects. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is easy to read and front-loaded. However, it lacks specificity that could be included without much added length, such as what 'detailed information' entails.
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 parameters and no output schema, the description is the only source of context. It is too terse to fully convey what the tool returns, and it does not address how it differs from similar sibling tools. The low complexity is offset by the ambiguity created by overlapping siblings, making the description incomplete.
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 0 parameters, and the rubric sets a baseline of 4 for such cases. The description doesn't need to add parameter context because there are none to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets detailed information about the current selection in Figma, but it doesn't differentiate from sibling tools like get_selection or get_node_info. The phrase 'including all node details' adds some specificity, but the overlap with existing siblings creates ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_selection or get_node_info. It does not mention scenarios, prerequisites, or exclusions, leaving the agent to guess which tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behaviors such as return format, whether an empty selection returns an empty list, or any limitations. 'Get' implies read-only, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no extraneous information. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema, so the description should clarify what information is returned (e.g., selected node IDs, types, metadata). It does not, leaving the agent uncertain about the return value and edge cases like empty selections. The minimal description is insufficient for a plug-and-play 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?
The tool has zero parameters, so parameter semantics are trivial. The description correctly implies no arguments are needed, and the schema confirms this. Baseline 4 for zero-parameter tools 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 clearly identifies the tool as retrieving information about the current selection in Figma. It is distinct from sibling tools like set_selections (which modifies) and get_node_info (which targets specific nodes), though it doesn't explicitly differentiate 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 provided on when to use this tool versus alternatives such as get_node_info or get_document_info. The context of 'current selection' implies it is for user-selected elements, but this is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states the action, without disclosing coordinate semantics, effect on parent/children, return value, or error conditions. 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, concise sentence that states the core action without redundancy. It is front-loaded and appropriately sized for the 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?
For a 3-parameter tool with full schema coverage, the description is minimally adequate. However, it omits coordinate system context (relative vs. absolute) and return/error behavior, so it is not fully complete for an agent to understand consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers all three parameters with clear descriptions, so the baseline is 3. The description adds no additional parameter semantics, but it does not need to given the high schema 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 uses a specific verb ('move') and resource ('node') with a destination ('new position'), clearly identifying the action. It is distinguishable from siblings like resize_node or delete_node, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings such as resize_node or set_focus. It does not state prerequisites, coordinate system, or whether moving between parents is supported.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not explain side effects (e.g., whether existing fills are replaced), behavior when alpha is omitted, error conditions for unsupported node types, or reversibility. 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 and quickly conveys the core action, achieving conciseness. However, the grammar is awkward ('can be TextNode or FrameNode' lacks a relative pronoun), which slightly detracts from structure and readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, and the simple parameter schema, the description is still incomplete. It does not address important context such as what happens to existing fills, how alpha defaults, or what errors occur for invalid node IDs/types. The description only states the basic action, leaving gaps for an agent to infer 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 all parameters with descriptive text (100% coverage), so the description does not need to add parameter meaning. The description itself adds no parameter-specific context, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action (set fill color) and the resource (a node in Figma), and distinguishes from the sibling set_stroke_color by naming 'fill color.' However, the phrase 'can be TextNode or FrameNode' is awkwardly phrased and could be interpreted as a constraint or a capability statement, slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage guidance by indicating supported node types (TextNode or FrameNode), which implies when the tool is appropriate. However, it does not explicitly mention alternatives like set_stroke_color for stroke colors, nor does it state exclusions or prerequisites beyond node type.
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 what the tool does, without mentioning side effects, such as whether it replaces the entire text, what happens if the node is not found or is not a text node, or whether the operation is reversible. The 'existing' hint implies a precondition but does not explain failure modes, making it inadequate for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys the primary action without extraneous words. It is appropriately sized for the tool's simplicity and front-loads the core purpose. Every word earns its place, and there is no unnecessary repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, with two well-documented parameters and no output schema. However, the description lacks contextual guidance on when to use it among many related text-manipulation tools and does not disclose behavioral expectations such as error handling or whether the existing text is fully replaced. Given the low complexity, the description is marginally adequate but leaves notable gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage, with both parameters (nodeId and text) described meaningfully. The description adds no extra parameter semantics beyond the schema, so the baseline score of 3 is appropriate. The schema already explains that nodeId is the ID of the text node to modify and text is the new content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Set the text content of an existing text node'. The word 'existing' distinguishes it from create_text, and 'text content' indicates the specific mutation. However, it does not explicitly differentiate from the sibling tool set_multiple_text_contents, which also sets text content, though on 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention that it is for single nodes only, nor does it contrast with set_multiple_text_contents or create_text. The usage context is only implied by the tool name and description, providing no explicit 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?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only restates the core action. It does not mention whether children or styles are copied, where the clone appears if x/y are omitted, what the return value is, or any access 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 front-loaded sentence with no filler or redundant detail. It efficiently communicates the tool's purpose in minimal words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and an output schema, the description is too sparse to be fully actionable. An agent would not know the clone's default placement, whether it duplicates children, or what result to expect after 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?
Schema description coverage is 100%, with each parameter (nodeId, x, y) having a clear description. The description adds no further meaning about units, defaults, coordinate origin, or behavior when optional params are omitted, so it meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Clone' with the resource 'node in Figma', clearly conveying the action and object. This distinguishes it from sibling tools like move_node, delete_node, and create_rectangle, even without naming alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as create_component_instance or create_rectangle. There are no explicit contexts, exclusions, or conditions explaining when cloning is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral burden. It only states the action without disclosing side effects, permissions, return value, or default behavior when parentId is omitted.
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, front-loaded sentence that directly states the verb and object. No filler, perfectly concise for a simple creation action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is too minimal. It omits critical details like return value, behavior when parentId is not provided, and integration with current selection, leaving the agent to guess important invocation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself adds no extra parameter meaning beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'Create a new rectangle in Figma.' It is specific but does not explicitly distinguish itself from sibling tools like create_frame or create_text, though the 'rectangle' resource provides implicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this tool when you need a rectangle. However, no explicit guidance is given about when to prefer this over alternatives such as create_frame or create_component_instance, nor any context about parent/selection requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states the action without mentioning side effects, permission requirements, node positioning behavior, or whether the node is appended to the current page or requires a parentId.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no redundant words. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite complete schema coverage, the tool has 8 parameters, a nested object, and no output schema or annotations. The description lacks operational context such as where the text node is created, how parentId is used, or relationship to the current selection, making it insufficient for 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?
Schema description coverage is 100% (all 8 parameters have descriptions). The tool description adds no parameter information 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 clearly specifies the action ('Create') and the resource ('a new text element'), with the context 'in Figma'. This distinguishes it from siblings like create_rectangle or create_frame, and accurately reflects the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like set_text_content (for modifying existing text) or create_frame. No contextual or exclusionary instructions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only restates the name ('Delete multiple nodes at once') and adds the minor detail that the operation is a batch. It does not mention that deletion is destructive and potentially irreversible, how invalid node IDs are handled, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, immediately front-loaded with the verb 'Delete', and contains zero filler words. Every word contributes to conveying the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations and simple schema, the description is too thin to be fully contextually complete. It omits critical warnings about the irreversible nature of deletion and any necessary caveats, such as how nested or child nodes are handled or whether confirmation is required.
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 a clear description for the only parameter ('nodeIds' = 'Array of node IDs to delete'), achieving 100% coverage. The tool description adds no extra information about parameter format, constraints, or error cases, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete'), the resource ('multiple nodes from Figma'), and the batch nature ('at once'). It effectively distinguishes from the sibling tool 'delete_node' by explicitly indicating 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives like 'delete_node'. It does not mention prerequisites, batch limits, or situations where single deletion is preferred, leaving usage to be implied solely by 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?
No annotations are present, so the description must disclose behavioral traits. It merely states the intent but omits specifics like return format, error behavior, or permissions, leaving the agent without essential 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, clear sentence with no redundant words, making it concise and well-structured. It front-loads the purpose immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the absence of an output schema means the description should clarify what 'detailed information' includes. It does not describe return values, edge cases, or any additional context, leaving the description incomplete for an agent's decision-making.
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 nodeId described as 'The ID of the node to get information about'. The description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' and identifies the resource as 'detailed information about a specific node in Figma', clearly distinguishing it from sibling 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 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 get_nodes_info or get_selection. The description only states the 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?
No annotations are provided, so the description must disclose behavioral traits, but it only states the action. It does not mention that this is a mutating operation, potential irreversibility, permission requirements, or what happens if the node doesn't exist. The description adds no behavioral information beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys the tool's purpose with no filler or redundancy. It is appropriately sized for a simple rename operation and front-loads the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the simple two-parameter schema, this is a mutating tool with no annotations or output schema. The description fails to provide behavioral context, usage guidance, or edge-case handling, leaving the agent with insufficient information to fully understand the operation's implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for both parameters (nodeId and name) with 100% coverage, so the description does not need to elaborate. Since the description contains no additional parameter semantics, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('rename') and the resource ('node (layer)'), making it unambiguous. It is easily distinguished from sibling tools like move_node, delete_node, and resize_node due to its specific verb and object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of exclusions or side conditions. The one-line description simply states the action without any 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 must fully disclose behavioral traits. It fails to state whether the operation is read-only, what it returns, or any side effects. 'Scan' implies a non-destructive read, but this is not explicit, and the return format is 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 is a single, clear sentence with no redundancy. It is front-loaded with the verb and subject, making the core purpose immediately visible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the tool returns (e.g., list of text node IDs or text contents). It also causes ambiguity by saying 'selected Figma node' when the tool requires a nodeId parameter, and it does not clarify recursion depth or search scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter nodeId, and the schema description 'ID of the node to scan' fully explains it. The tool description adds no extra 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'scan' and the target resource 'all text nodes in the selected Figma node', giving a clear purpose. It is specific enough to distinguish from general scanning tools like scan_nodes_by_types, although it does not explicitly name alternatives. The term 'scan' is slightly vague but the intent is discernible.
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 usage guidelines are given; there is no mention of when to use this tool versus scan_nodes_by_types or other siblings. Usage is implied by the name and description (i.e., when you need text nodes), but alternatives and exclusions are not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. 'Create or update an annotation' is too vague; it fails to mention whether updates merge or replace properties, permission requirements, or side effects. The upsert semantics are only implicitly hinted at.
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 says exactly what the tool does. No waste, no fluff. It earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and no output schema, the description is far too minimal. It does not explain how to choose create vs update, what properties are for, or how this relates to get_annotations or set_multiple_annotations. The schema helps but the description lacks essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all five parameters. The description adds no additional parameter meaning beyond restating the purpose. Baseline of 3 is appropriate as high schema coverage carries the 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 'Create or update an annotation' clearly states the specific action (create/update) and resource (annotation). It distinguishes from sibling tools like get_annotations and set_multiple_annotations by implying a single annotation operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention set_multiple_annotations for batch operations nor explain the distinction between creating (no annotationId) and updating (with annotationId). This relies entirely on the schema.
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 merely states 'Set the corner radius' without mentioning side effects, node type compatibility, mutation behavior, or whether the operation is reversible. This leaves significant gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence of nine words. It is front-loaded with the essential action and resource, containing no redundant or filler content.
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 full schema coverage, the description is too thin for a mutation tool with no annotations. It omits important context such as the default behavior when the optional 'corners' parameter is omitted, which node types support corner radius, and the effect of the mutation (e.g., immediate visual change). This incomplete picture may lead to incorrect agent behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (nodeId, radius, corners) having descriptions. The high schema coverage means the description does not need to add parameter details, and indeed it does not. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set the corner radius of a node in Figma', using a specific verb ('Set') and resource ('corner radius'). This unambiguously distinguishes it from other sibling tools like set_fill_color or set_stroke_color, which operate on different node properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or contraindications. The description only states what it does, leaving the AI agent to infer usage from the tool's name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose side effects, permissions, error conditions, or whether the node must already exist as a copy. The term 'copied' hints at a prerequisite but remains 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 a single concise sentence, front-loaded with the action, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity (one parameter, no output schema), the description omits crucial context such as when to use it, what 'copied' implies, and any behavioral caveats. The agent has insufficient information to decide invocation confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with connectorId fully described in the schema. The tool description adds no additional parameter 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 ('set') and resource ('connector node') with a clear outcome ('as default connector'). It distinguishes this tool from siblings like move_node or delete_node, and there is no other set_default tool in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description does not explain what 'copied' means or when this action is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It offers no insights into side effects, failure modes, or what happens if the frame is not an auto-layout frame. It only states the target must be an auto-layout frame, which is a mild constraint but not enough to be considered 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?
The description is a concise single sentence of 11 words, effectively front-loading the action and target. Every word earns its place, and it avoids redundancy with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with detailed schema parameters and no output schema, the description provides the essential purpose and target but omits any mention of return values, side effects, or edge cases. It is minimally adequate but leaves questions about behavior when constraints are violated.
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% for the three parameters, including detailed explanations for enum values (e.g., BASELINE and SPACE_BETWEEN notes). The description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: setting primary and counter axis alignment on an auto-layout frame in Figma. It uses a specific verb and resource, and distinguishes itself from sibling tools like set_layout_mode and set_item_spacing by focusing on alignment axes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., the frame must already be an auto-layout) beyond the phrase 'for an auto-layout frame,' but this is implied rather than actionable. No exclusions or alternative tool suggestions are given, so the agent lacks context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Export a node as an image' but does not mention side effects, permissions, output type, error handling, or whether the operation is read-only. This is a significant gap for an export 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 of seven words, entirely free of fluff. It is front-loaded with the core action and resource, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and lacks behavioral detail. The description does not explain what the agent should expect (e.g., a URL, binary data, file path), nor does it mention limitations, default export settings, or node type compatibility. This is inadequate for a tool with three parameters and no structured output.
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 parameters are already fully documented. The description adds no extra 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 ('export') and resource ('a node') with the output being 'an image'. It is unambiguous and distinguishes itself from sibling tools, none of which handle image export.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for exporting nodes as images but does not explicitly state when to use it or mention alternatives. Since no sibling tool offers similar functionality, the lack of exclusions is less critical, but explicit context would improve 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 must disclose behavioral traits on its own. It only specifies the target (auto-layout frame) and omits critical constraints such as HUG being limited to frames/text, FILL being for auto-layout children only, and behavior when only one sizing parameter is set. This is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action, resource, and target. It contains no unnecessary words or redundant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite a clear purpose and strong schema support, the description lacks behavioral constraints, usage guidance relative to sibling tools, and handling of optional parameters. The absence of annotations makes this description insufficient for complete agent decision-making in a complex design tool context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full 100% coverage with detailed descriptions and enums for all three parameters. The description adds no additional parameter semantics beyond naming horizontal and vertical sizing modes, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') on a specific resource ('horizontal and vertical sizing modes for an auto-layout frame'), making it distinct from sibling tools like resize_node (which alters dimensions) or set_layout_mode (which sets layout type).
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 but does not explicitly state when to use this tool over alternatives such as resize_node or set_layout_mode, nor does it mention any exclusions or prerequisites beyond the auto-layout context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It simply states 'Set padding values' without mentioning that the frame must already be an auto-layout frame, that individual side padding may require independent padding mode, or any constraints on values. This leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, clearly front-loaded with 'Set padding values.' It contains no superfluous content, though 'in Figma' is arguably redundant, but it remains concise 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?
With 5 parameters, no annotations, and no output schema, the description should provide more context about usage constraints and side effects. It omits the auto-layout prerequisite and independent padding behavior, making it insufficient for reliable agent 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?
Schema coverage is 100%, with each parameter already described as 'Top padding value' etc. The description adds no additional parameter-level meaning beyond restating 'padding values.' Baseline 3 applies as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Set' and resource 'padding values', with context 'auto-layout frame', distinguishing it from siblings like set_item_spacing and set_layout_mode. It clearly states the tool's 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 phrase 'auto-layout frame' implies a precondition, but the description does not explicitly state when to use this tool versus alternatives like set_item_spacing or set_layout_mode. No exclusions or alternative recommendations are provided, making usage guidance merely 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 for behavioral disclosure. It only mentions the default connector style, omitting any details about permissions, validation of node IDs, side effects (e.g., overwriting existing connections), or return behavior. This is insufficient for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter (with nested objects) and no output schema or annotations. The description gives the essential purpose but lacks context about prerequisites (e.g., nodes must exist), error behavior, or return values. It is minimally viable but leaves room for more completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no extra meaning to the parameters beyond what the schema already provides; it doesn't clarify the structure of 'connections' or the semantics of startNodeId/endNodeId beyond their names and brief 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 clearly states the tool's function: create connections between nodes. It also specifies the connector style (default), which differentiates it from related tools like set_default_connector that manage style defaults rather than creating connections.
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 creating connections with the default style, but does not explicitly state when to prefer this tool over alternatives or mention any exclusions. Since sibling tools exist for node manipulation and connector styling, clearer guidance would improve this score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It mentions setting layout mode and wrap behavior, implying mutation, but does not explain potential side effects (e.g., what happens if layoutMode is NONE with layoutWrap set, or whether the frame must already have auto-layout). This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly conveys the tool's purpose with no wasted words. It is appropriately concise for a straightforward setter 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 simple parameter set and no output schema, the description covers the basics. However, it omits important constraints like frame eligibility and behavior nuances between layout modes, leaving the agent to infer potentially critical context for 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?
Schema description coverage is 100%, so baseline is 3. The description's phrase 'wrap behavior' adds minimal clarification beyond the schema's own parameter descriptions but does not provide deeper semantics such as interactions between layoutMode and layoutWrap.
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 specific verb 'set' and resource 'layout mode and wrap behavior of a frame', making it distinct from sibling tools like set_padding or set_layout_sizing. It unambiguously identifies what the tool does and what entity it 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used to set layout mode and wrap behavior, but provides no explicit guidance on when to use it over alternatives or any prerequisites such as the node needing to be a frame with auto-layout enabled. Lacks exclusions or alternative tool references.
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 adds the word 'parallelly' hinting at concurrency but does not disclose potential side effects, permissions, atomicity, or error behavior. This is a mutation tool, so more transparency is needed.
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. It is front-loaded with the action and resource, making it highly concise and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with two well-documented parameters and no output schema. The description adequately states the core function, but lacks context on concurrency semantics (e.g., 'parallelly') and error handling, leaving some gaps 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%, so the parameters are already well-documented. The description adds no additional parameter meaning beyond what the schema provides, so it remains at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'multiple text contents' within a node, differentiating it from the sibling tool set_text_content (singular). The scope is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating multiple text nodes at once (via 'multiple') but does not explicitly state when to use this over the singular set_text_content or any alternatives. No when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It implies a read-only operation via the verb 'scan' but does not clarify whether 'child nodes' means immediate children or all descendants, nor does it describe the return format. The term 'selected' could also be ambiguous against the nodeId parameter, though not contradictory.
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 effectively conveys the core purpose without unnecessary detail. It is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not specify the shape of the returned result (e.g., array of node IDs or nodes), nor does it clarify whether scanning is recursive or limited to direct children. An agent would need to infer these critical details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with clear descriptions ('nodeId' as the ID to scan, 'types' as the array of types to find). The description adds no additional parameter-level 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 clearly states the action ('Scan for child nodes') and specifies the resource ('with specific types in the selected Figma node'). This distinguishes it from sibling tools like scan_text_nodes, which focuses on text nodes, and get_node_info, which retrieves a single node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need to find child nodes of certain types. However, it does not explicitly mention when to avoid this tool or name alternatives, such as scan_text_nodes for text-specific scanning. There is no exclusion criterion or peer tool reference.
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 side effects and return behavior. It does not mention that the operation is read-only (though 'get' suggests it) or describe the return structure, leaving behavioral expectations unclear for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single clear sentence front-loads the operation and resource. There are no unnecessary words or redundant information; it is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only listing tool, the description is adequate but minimal. It omits return value details and potential library-component caveat, but the low complexity and lack of output schema make the description sufficient for an agent to invoke it 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?
The tool accepts no parameters, so the description doesn't need to explain them. The empty schema provides complete coverage, and the description adds no unnecessary param-related constraints. Baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('get'), identifies the resource ('local components'), and scopes it to the Figma document. This clearly distinguishes it from sibling tools like get_styles or 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?
The description implies the tool is for retrieving all components defined locally in the document, but it provides no explicit guidance on when to use it over alternatives or any exclusions (e.g., library components). The basic use case is understandable from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It simply states 'Set distance between children' without mentioning any side effects, prerequisites (beyond auto-layout frame), or special cases. This is a gap for a mutation tool; for example, it does not note that the change is applied to the node or that specific conditions (like SPACE_BETWEEN alignment) can override the 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, front-loaded sentence with no redundant words. It immediately conveys the tool's purpose and scope, earning a perfect score for conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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, the description plus the fully self-documenting schema is largely complete. It states the target (auto-layout frame) and action. It does not explain return values, but with no output schema and a simple setter, that is acceptable. However, it could be slightly more complete by mentioning that the node must be a frame with auto-layout enabled, though this is implied by 'auto-layout frame'.
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 no extra meaning about parameters; it only names the operation. The schema already documents each parameter, including notes about ignoring itemSpacing under certain conditions, so the description does not need to compensate. Thus, a 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' in 'auto-layout frame'), clearly distinguishing it from sibling tools like set_padding or set_axis_align. It precisely states the action and scope, 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 provides clear context by specifying 'in an auto-layout frame', indicating the tool is intended for auto-layout frames. It does not explicitly mention exclusions or alternatives, but the context is enough to infer when to use it, so it earns a 4.
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 side effect of scrolling the viewport, which is valuable. However, it does not mention whether the existing selection is replaced, how invalid node IDs are handled, or any constraints on selecting multiple nodes.
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 front-loads the core action and its side effect. Every word earns its place, with no redundant information or tangential details.
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?
For a tool with one required parameter and no output schema, this description is sufficiently complete. It states what the tool does and the notable side effect (scrolling), which is all an agent needs to know to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the nodeIds parameter with 100% coverage. The description's reference to 'multiple nodes' aligns with the array type but adds no additional meaning or constraints beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set selection') and the resource ('multiple nodes in Figma'), plus the additional behavior of scrolling the viewport. It distinguishes itself from siblings like get_selection by focusing on the write operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used when one wants to set the current selection to multiple nodes. However, it does not explicitly mention alternatives or when not to use it, though the purpose is clear enough that most agents would infer the correct 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?
No annotations are provided, so the description carries the full burden. It implies a read operation via 'Get' and discloses the critical post-processing requirement. However, it doesn't detail return format, error behavior, or side effects, leaving room for ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states the tool's purpose, the second provides a critical usage instruction. It is front-loaded, concise, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter, high schema coverage, no output schema, and no annotations, the description explains both what the tool does and the mandatory next step in the workflow. This makes the tool contextually complete for the intended use case, though it could mention input constraints (e.g., valid node IDs).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the single parameter with a clear description ('Array of node IDs to get reactions from'). The tool description adds no new parameter semantics beyond 'multiple nodes', which aligns with the array type. With high schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get Figma Prototyping Reactions from multiple nodes', a specific verb+resource+scope. It distinguishes from siblings like get_node_info by focusing on reactions, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit workflow: output must be processed via the 'reaction_to_connector_strategy' prompt then used with 'create_connections'. This tells the agent when/how to use the tool's output, though it doesn't state when not to use it or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey read-only behavior. 'Get' implies no side effects, but the description does not disclose whether it returns all style types (color, text, shape), whether it includes library styles, or potentially costs performance on large documents. This leaves some ambiguity 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, direct sentence that front-loads the verb and resource. It contains no redundant phrases and is highly scannable.
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), the description adequately covers its action and scope. It could improve by noting what a 'style' includes or what the return value looks like, but the basic purpose is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is empty and there is nothing to explain. The baseline of 4 applies because the description adds no param-related confusion and none 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 action ('Get'), the resource ('all styles'), and the scope ('current Figma document'), which distinguishes it from sibling tools like get_local_components and get_document_info. Its intent is immediately evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need styles from the document, but it does not explicitly mention when to use this tool over alternatives or provide exclusions. Given the many sibling getter tools, more explicit guidance would help, but the purpose is clear enough for basic selection.
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 and discloses two key behaviors: it selects the node and scrolls the viewport to it. This goes beyond a simple statement of purpose, though it does not mention side effects or required permissions, which would be additional 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 sentence that leads with the main action and includes necessary detail. 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 one-parameter tool with no output schema, the description adequately covers the operation and its effect on the editor. It might have noted the need for a valid nodeId or the fact that selection changes permanently, but as a basic action description, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the only parameter (nodeId) with 100% coverage. The description adds no extra semantics about the ID format or how to obtain it, so it only meets the baseline for schema-provided info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set focus') and resource ('specific node in Figma'), and additionally explains the mechanism ('by selecting it and scrolling viewport to it'). This clearly distinguishes it from similar tools like set_selections, which only selects without scrolling.
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 focusing on a node, but it does not explicitly state when to use it over alternatives, nor mention when not to use it. No exclusions or alternative tools are named, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It details the primary action (swap and apply overrides) but does not mention potential side effects, irreversibility, or permission requirements. This is adequate but not rich, as it lacks deeper context about the mutation's impact.
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 concise sentences. The first states the action, and the second clarifies the outcome. There is no fluff or redundancy, making it easily and quickly parsable.
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 2-param tool without an output schema or annotations, the description covers the action, target, and effect. It leaves out explicit prerequisites like 'copied overrides' but implies them. Overall, it is sufficiently complete for an agent to invoke the tool 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% with meaningful descriptions for both parameters. The tool description adds context by explaining that targetNodeIds refer to the selected instances and sourceInstanceId corresponds to the source component, reinforcing the semantic relationship beyond what the schema alone 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 'Apply' and clearly identifies the resource: 'previously copied overrides to selected component instances.' It also explains the effect—'swapped to the source component'—which distinguishes it from sibling tools like get_instance_overrides and creates a clear understanding of 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a workflow: overrides must have been copied beforehand and instances must be selected. It doesn't explicitly name alternatives, but the context is clear enough that an agent would know when to use this tool versus a similar one like get_instance_overrides.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that this is a read operation ('Get all override properties') and adds useful context about how the data can be used, which goes beyond a bare statement. It does not discuss return format or edge cases, but for a simple getter 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?
Two concise sentences, front-loaded with the primary action, and no redundant phrasing. Every sentence adds value.
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?
This is a simple getter with one optional parameter and no output schema. The description explains what the tool does and why the data is useful, making it sufficiently complete for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema's nodeId explanation, which already covers the optional/selected instance behavior.
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 with a specific verb and resource: 'Get all override properties from a selected component instance.' This distinguishes it from sibling tools like set_instance_overrides, and the additional sentence clarifies the purpose of these overrides.
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 when to use the tool by stating 'These overrides can be applied to other instances,' making the use case clear. However, it does not explicitly name alternatives or exclusions, such as 'use set_instance_overrides to apply these.'
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:

[![edgen-figma-to-code-mcp MCP server](https://glama.ai/mcp/servers/edgen-design/edgen-figma-to-code-mcp/badges/card.svg)](https://glama.ai/mcp/servers/edgen-design/edgen-figma-to-code-mcp)

Score Badge

Copy to your README.md:

[![edgen-figma-to-code-mcp MCP server](https://glama.ai/mcp/servers/edgen-design/edgen-figma-to-code-mcp/badges/score.svg)](https://glama.ai/mcp/servers/edgen-design/edgen-figma-to-code-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/edgen-design/edgen-figma-to-code-mcp'

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