Cursor Talk to Figma MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
Most tools have distinct purposes, but there is some overlap and ambiguity. For example, 'get_selection' and 'read_my_design' both retrieve selection information, and 'get_node_info' vs 'get_nodes_info' differ only in singular/plural. However, descriptions clarify differences, and tools generally target specific actions like creation, deletion, or styling.
Naming Consistency4/5
Naming is mostly consistent with a verb_noun pattern (e.g., create_frame, delete_node, set_fill_color), but there are minor deviations like 'read_my_design' and 'join_channel' that break the pattern. Overall, the naming is predictable and readable, with only a few tools not following the dominant convention.
Tool Count3/5
With 38 tools, the count is borderline high for a Figma integration, feeling heavy and potentially overwhelming. While Figma is a complex domain, many tools could be consolidated (e.g., multiple 'set_' tools for styling). The scope is broad, but the number risks confusion and inefficiency for agents.
Completeness5/5
The tool set provides comprehensive coverage for interacting with Figma, including CRUD operations (create, get, update, delete), styling, layout management, annotations, and prototyping. There are no obvious gaps; tools cover nodes, components, text, images, connections, and document info, enabling full agent workflows without dead ends.
Average 3/5 across 38 of 38 tools scored.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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. While 'Clone' implies a mutation operation, the description doesn't specify whether this requires edit permissions, what happens to the original node, whether the clone inherits properties, or any rate limits. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every word earning its place in conveying the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what the clone operation returns, what properties are copied, whether the operation is reversible, or permission requirements. Given the complexity of cloning operations and lack of structured data, the description should provide more behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (nodeId, x, y) with clear descriptions. The description doesn't add any additional parameter semantics beyond what's in the schema, such as explaining coordinate systems or node ID formats. This 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Clone') and resource ('an existing node in Figma'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'create_frame' or 'create_rectangle' which also create visual elements, leaving some ambiguity about when cloning is preferred over creating new elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when cloning is appropriate versus creating new nodes with sibling tools like 'create_frame', nor does it specify prerequisites such as needing an existing node ID. This leaves the agent without contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Create an instance' which implies a write/mutation operation, but doesn't clarify permissions needed, whether it's destructive to existing elements, rate limits, or what happens on success/failure. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every word earns its place, and there's no redundancy or fluff. It's appropriately sized for a straightforward tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects like permissions, side effects, or return values, leaving gaps that could hinder an agent's ability to use it correctly. The high schema coverage helps with parameters, but overall context is lacking.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (componentKey, x, y) with clear descriptions. The description adds no additional meaning about parameters beyond what's in the schema, such as explaining what a 'componentKey' represents or coordinate system details. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create an instance') and resource ('of a component in Figma'), making the purpose immediately understandable. It distinguishes itself from siblings like 'create_frame' or 'create_rectangle' by focusing on component instantiation rather than creating new elements from scratch. However, it doesn't specify what distinguishes 'component' from other elements or mention the sibling 'clone_node', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing component), exclusions, or compare it to siblings like 'clone_node' (which might duplicate nodes) or 'create_frame' (which creates new frames). Without this context, an agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'default connector style' but doesn't disclose critical behaviors: whether connections are bidirectional, if they can be edited/deleted later, what happens with invalid node IDs, or if there are rate limits. For a creation tool with zero annotation coverage, this leaves significant gaps in understanding its operational 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 a single, efficient sentence that front-loads the core action ('create connections between nodes') and adds a useful constraint ('using the default connector style'). There is no wasted wording, and it directly addresses the tool's function without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a creation tool with potential side effects (modifying node relationships), the description is incomplete. It lacks details on behavioral traits (e.g., error handling, idempotency), return values, or usage context. For a tool that alters a design environment, more guidance is needed to ensure safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear documentation for the 'connections' array and its nested properties (startNodeId, endNodeId, text). The description adds minimal value beyond the schema, only implying the 'default connector style' applies to all created connections. No additional syntax or format details are provided, meeting the baseline for 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 clearly states the action ('create connections') and resource ('between nodes'), specifying it uses 'default connector style'. It distinguishes from siblings like 'set_default_connector' (which configures style) and 'clone_node' (which duplicates nodes). However, it doesn't explicitly differentiate from tools like 'move_node' or 'set_axis_align' that might involve node relationships.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., existing nodes), exclusions (e.g., invalid node IDs), or comparisons to siblings like 'set_default_connector' (for style changes) or 'move_node' (for repositioning). Usage is implied but not explicitly 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Create a new frame' which implies a write operation, but doesn't specify permissions needed, whether it's destructive to existing elements, rate limits, or what the response looks like (e.g., returns a node ID). For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 complexity (20 parameters, no output schema, no annotations), the description is inadequate. It doesn't explain what a 'frame' is in Figma context, how it differs from other elements, what happens on success/failure, or provide any behavioral context. For a tool with this many parameters and mutation behavior, more guidance 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 description coverage is 100%, so the schema already documents all 20 parameters thoroughly with descriptions, constraints, and enums. The description adds no additional meaning about parameters beyond what's in the schema, such as explaining relationships between parameters (e.g., how layoutMode interacts with padding). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and resource ('a new frame in Figma'), making the purpose immediately understandable. However, it doesn't differentiate this from sibling tools like 'create_rectangle' or 'create_component_instance', which also create design elements in Figma, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'create_rectangle' and 'create_component_instance' available, there's no indication of when a frame is preferred over other shapes or components, nor any mention of prerequisites or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Create a new rectangle' implies a write operation, but it doesn't specify permissions needed, whether the creation is reversible, how it interacts with the Figma document (e.g., layer ordering), or what happens on success/failure. This leaves significant gaps for a mutation tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It's appropriately sized for a straightforward tool, with zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., effects, permissions), usage context relative to siblings, and expected return values, leaving the agent with insufficient information for reliable 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 the schema already documents all parameters (x, y, width, height, name, parentId) with basic descriptions. The description adds no additional meaning beyond implying creation occurs in Figma, which is redundant with the schema's context. Baseline 3 is appropriate when the schema handles parameter documentation adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new rectangle') and resource ('in Figma'), making the purpose immediately understandable. However, it doesn't differentiate this tool from similar creation tools like 'create_frame' or 'create_component_instance' among the siblings, which would require more specific context about what makes a rectangle distinct.
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. With siblings like 'create_frame' and 'create_component_instance', there's no indication of when a rectangle is preferred over other shape or container types, nor any mention of prerequisites or exclusions for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Delete multiple nodes from Figma at once', which implies a destructive mutation, but doesn't address critical aspects like permissions required, whether deletions are permanent or reversible, error handling for invalid node IDs, or rate limits. For a destructive tool with zero annotation coverage, this is a significant gap in 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, efficient sentence with zero waste: 'Delete multiple nodes from Figma at once'. It is front-loaded with the core action and resource, making it immediately understandable. Every word earns its place, and there is no redundant or verbose language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's destructive nature, lack of annotations, and absence of an output schema, the description is incomplete. It doesn't cover behavioral traits like permanence, permissions, or error handling, nor does it explain return values or side effects. For a mutation tool with no structured safety hints, the description should provide more context to ensure safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'nodeIds' clearly documented as 'Array of node IDs to delete'. The description adds no additional semantic context beyond what the schema provides, such as format examples or constraints on node ID validity. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
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 ('Delete') and resource ('multiple nodes from Figma'), making the purpose unambiguous. It distinguishes from the sibling 'delete_node' by specifying 'multiple nodes at once', though it doesn't explicitly name the alternative. The description is specific but could be more explicit about the 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 like 'delete_node'. It mentions 'multiple nodes at once', which implies a batch operation, but doesn't specify thresholds or scenarios where batch deletion is preferred over individual deletion. No exclusions, prerequisites, or explicit alternatives are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits. It doesn't mention whether deletion is permanent, requires specific permissions, affects linked components, or has side effects like cascading changes, which is critical for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero waste, front-loading the essential action and resource. It's appropriately sized for a simple tool, making it easy to scan and understand 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?
For a destructive tool with no annotations and no output schema, the description is incomplete. It lacks crucial details like what happens post-deletion (e.g., confirmation, error handling), return values, or implications in a collaborative Figma environment, leaving significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, with the single parameter 'nodeId' clearly documented in the schema. The description doesn't add any extra meaning beyond what the schema provides, such as examples or constraints, but this is acceptable given the high coverage, resulting in a 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 action ('Delete') and target resource ('a node from Figma'), which is specific and unambiguous. However, it doesn't differentiate from sibling 'delete_multiple_nodes', which handles multiple deletions, leaving some room for improvement in distinguishing between similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'delete_multiple_nodes' for bulk operations or other deletion-related tools. The description lacks context about prerequisites, permissions, or typical scenarios for single-node deletion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It implies a write/export operation but doesn't disclose whether this consumes API credits, has rate limits, requires specific permissions, or what happens on failure (e.g., invalid node ID). The description is technically accurate but lacks operational 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, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable and appropriately sized for a straightforward export tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool (export generates output) with no annotations and no output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., image data, download link, status), error conditions, or practical constraints. The context signals indicate this tool has behavioral complexity that isn't addressed.
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%, providing complete parameter documentation. The description adds no parameter-specific information beyond what's in the schema (nodeId, format, scale). This meets the baseline of 3 since the schema adequately covers parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Export') and resource ('a node as an image from Figma'), making the tool's purpose immediately understandable. It distinguishes from siblings like 'get_node_info' (read-only) or 'delete_node' (destructive), but doesn't explicitly differentiate from other export-related tools since none are listed among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid node ID), constraints (e.g., export limits), or related operations (e.g., using 'get_node_info' first to verify node existence).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'Get all annotations' but doesn't disclose behavioral traits such as whether this is a read-only operation (implied by 'get'), potential permissions needed, rate limits, pagination, or what happens if no document is open. The description adds minimal context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads the core action ('Get all annotations') and specifies scope ('in the current document or specific node') concisely. Every word earns its place, making it easy to parse quickly.
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 2 parameters with full schema coverage, the description is incomplete. It lacks context on behavioral aspects (e.g., read-only safety, error conditions), output format (what 'annotations' include), and usage guidelines. For a tool in a design/UI context with many sibling tools, more guidance is needed to help an agent use 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 schema fully documents both parameters (nodeId and includeCategories). The description adds no additional meaning beyond implying 'nodeId' targets a 'specific node' and 'all annotations' might default to the current document. Baseline 3 is appropriate as the schema does the heavy lifting, but the description doesn't compensate with extra insights like parameter interactions or default behaviors.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'annotations', specifying scope with 'in the current document or specific node'. It distinguishes from siblings like 'set_annotation' (write vs read) and 'get_document_info' (annotations vs general info), though not explicitly named. However, it doesn't fully differentiate from all siblings like 'get_reactions' or 'get_styles' which are also read operations on document elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an open document), exclusions, or compare to siblings like 'get_document_info' (which might include annotations) or 'scan_nodes_by_types' (which might filter nodes). Usage is implied by the name and purpose but not explicitly 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?
No annotations are provided, so the description carries the full burden. It states it 'gets' information, implying a read-only operation, but does not disclose behavioral traits like whether it requires authentication, rate limits, error handling, or the format of the returned information. This leaves significant gaps for an agent to understand how to use it effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy for an agent to parse quickly.
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 complexity of a Figma node query tool with no annotations and no output schema, the description is incomplete. It lacks details on what 'detailed information' includes, how errors are handled, or any context about the Figma environment, making it insufficient for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the single parameter 'nodeId' clearly documented. The description does not add any meaning beyond the schema, such as examples of node IDs or context on where to obtain them, so it meets the baseline for high schema coverage without compensating further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'detailed information about a specific node in Figma', which is specific and unambiguous. However, it does not explicitly differentiate from sibling tools like 'get_nodes_info' (plural) or 'get_document_info', leaving some ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools like 'get_nodes_info' for multiple nodes or 'get_document_info' for broader context, nor does it specify prerequisites such as needing a valid node ID from the Figma document.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but only states what the tool does, not how it behaves. It doesn't mention whether this is a read-only operation, what format the information returns in, whether there are rate limits, authentication requirements, or error conditions for invalid node IDs.
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 efficiently communicates the core function without unnecessary words. It's appropriately sized for a straightforward tool and front-loads the essential information 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?
For a tool with no annotations, no output schema, and multiple sibling tools (including the similar 'get_node_info'), the description is insufficient. It doesn't explain what 'detailed information' includes, how results are structured, or address potential confusion with the singular version of this tool, leaving significant gaps for agent understanding.
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 has 100% description coverage, with the single parameter 'nodeIds' clearly documented as 'Array of node IDs to get information about'. The description adds no additional parameter context beyond what's in the schema, so it meets the baseline for high schema coverage without adding 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 states the action ('Get detailed information') and resource ('multiple nodes in Figma'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from its sibling 'get_node_info' (singular vs. plural), which could cause confusion about when to use each tool.
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 like 'get_node_info' (singular) or 'get_document_info'. There's no mention of prerequisites, limitations, or typical use cases, leaving the agent to infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the action ('Join') but doesn't disclose behavioral traits such as whether this requires authentication, if it's idempotent, what happens on success/failure, or any side effects (e.g., notifications). The description is minimal and lacks crucial operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and appropriately sized, with every word earning its place by conveying the core action and goal.
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 complexity (a potentially interactive tool with no annotations and no output schema), the description is incomplete. It doesn't explain what 'join' entails operationally, what the expected outcome is, or any error conditions. For a tool that might involve network communication or state changes, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with the parameter 'channel' documented as 'The name of the channel to join'. The description doesn't add any meaning beyond this, such as channel naming conventions or examples. With high schema coverage, the baseline score of 3 is appropriate 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Join') and the resource ('a specific channel'), with the purpose being 'to communicate with Figma'. It's specific about what the tool does, though it doesn't explicitly differentiate from siblings like 'get_document_info' or 'read_my_design', which are read-only operations, whereas this implies an interactive action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The description doesn't mention prerequisites (e.g., needing to be in a Figma workspace), exclusions, or related tools. It's a standalone statement with no context for usage decisions.
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 states the tool performs a mutation ('move'), but doesn't disclose behavioral traits such as permissions required, whether the move is reversible, effects on other nodes, error conditions, or rate limits. The description is minimal and misses critical context 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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse. Every word contributes to the purpose without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects, error handling, return values, and how it fits with sibling tools. For a tool that modifies Figma nodes, more context is needed to ensure safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions in the schema. The description adds no additional meaning beyond implying positional movement, which is already covered by the schema's 'x' and 'y' descriptions. Baseline 3 is appropriate as the schema does the heavy lifting, but the description doesn't compensate or enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('move') and resource ('a node') with specific context ('to a new position in Figma'). It distinguishes from siblings like 'resize_node' or 'delete_node' by focusing on positional changes, though it doesn't explicitly contrast with them. The purpose is unambiguous but could be more specific about what constitutes a 'node' in Figma.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing node permissions), when not to use it (e.g., for non-positional changes), or how it relates to siblings like 'resize_node' or 'set_layout_mode'. Usage is implied by the action but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Resize' implies a mutation operation, but the description doesn't specify whether this requires edit permissions, what happens to child nodes or constraints, if the operation is reversible, or any rate limits. It lacks critical context for a destructive operation in a design 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, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately understandable. Every word earns its place by conveying essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mutation tool in a design environment with no annotations and no output schema, the description is insufficient. It doesn't cover behavioral aspects (e.g., permissions, side effects), output expectations, or error conditions. For a tool that modifies Figma nodes, more context is needed to ensure safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions (nodeId, width, height). The description adds no additional semantic context beyond what the schema provides, such as unit explanations (e.g., pixels) or constraints (e.g., minimum/maximum values beyond exclusiveMinimum). Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Resize a node in Figma' clearly states the action (resize) and target resource (node in Figma). It distinguishes from siblings like move_node, delete_node, or create_rectangle by specifying the resize operation. However, it doesn't explicitly differentiate from tools that might also modify node dimensions indirectly (e.g., set_layout_sizing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid nodeId), exclusions (e.g., not applicable to certain node types), or comparisons to sibling tools like move_node or set_layout_sizing. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks behavioral details. It doesn't specify whether this is a read-only operation, what happens with invalid inputs, depth of scanning (direct children only or recursive), or output format. The description is minimal and doesn't compensate for the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., list of node IDs, node details), error conditions, or behavioral aspects like scanning scope. The context demands more information for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (nodeId and types). The description adds no additional meaning beyond what's in the schema, such as examples of valid node types beyond 'COMPONENT' and 'FRAME', or constraints on the nodeId format. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Scan for child nodes') and resource ('in the selected Figma node'), specifying the filtering criteria ('with specific types'). It distinguishes from siblings like 'scan_text_nodes' by mentioning broader node types, but doesn't explicitly contrast with other scanning/filtering tools that might exist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid node ID), exclusions, or compare with siblings like 'get_nodes_info' or 'scan_text_nodes' for different filtering needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without disclosing behavioral traits such as what 'scan' entails (e.g., returns text content, counts nodes, error handling), permissions needed, or rate limits. This leaves significant gaps for a tool that likely reads data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded and appropriately sized for its purpose, earning full marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a single parameter with full schema coverage, the description is incomplete. It lacks details on what the scan returns (e.g., list of text nodes, content), error cases, or behavioral context, making it inadequate for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'nodeId' clearly documented. The description adds no additional meaning beyond the schema, such as format examples or constraints, so it meets the baseline for high schema coverage without compensating 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 states the action ('scan') and target ('all text nodes in the selected Figma node'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'scan_nodes_by_types' or 'get_node_info', which could provide similar functionality, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'scan_nodes_by_types' or 'get_node_info', nor does it mention prerequisites or exclusions. It merely states what the tool does without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Create or update' implies a mutation operation, but it doesn't specify permissions needed, whether changes are reversible, rate limits, or what happens when updating versus creating. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable and appropriately sized for its 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 mutation tool with 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after creation/update, error conditions, or how to distinguish between create and update scenarios. The agent would need to guess about behavioral aspects and output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds no additional meaning about parameters beyond what's in the schema, such as explaining the relationship between 'annotationId' for updates versus creates. Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create or update') and resource ('an annotation'), making the purpose immediately understandable. However, it doesn't differentiate this tool from 'set_multiple_annotations' or 'get_annotations' among its siblings, which would require explicit comparison to achieve a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'set_multiple_annotations' or 'get_annotations'. It lacks any context about prerequisites, appropriate scenarios, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool sets a default connector, implying a mutation operation, but doesn't cover critical aspects like required permissions, whether this action is reversible, potential side effects, or error conditions. This is a significant gap for a tool that likely modifies system state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that efficiently conveys the core action without unnecessary words. It's front-loaded with the key verb and resource, making it easy to parse and understand quickly, which is ideal for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool likely performs a mutation (setting a default connector) with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, error handling, or return values, making it inadequate for safe and effective use by an AI agent in a design or connector management 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 has 100% description coverage, with 'connectorId' clearly documented. The description adds no additional parameter semantics beyond what's in the schema, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and resource ('a copied connector node as the default connector'), making the purpose understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'create_connections' or 'move_node', which might also involve connector operations, leaving some ambiguity about its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a copied connector node), exclusions, or related tools like 'create_connections' for creating connectors, leaving the agent to infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It states this modifies a node's fill color but doesn't disclose whether this is a destructive operation, what permissions are required, whether changes are reversible, what happens if the node doesn't exist, or what the response looks like. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point. It's appropriately sized for a straightforward tool, though it could be slightly more structured by front-loading the most critical information about node types or constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens after the color is set, what errors might occur, whether there are rate limits, or what visual feedback to expect. Given the complexity of modifying design elements and the lack of structured behavioral data, more context 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 description coverage is 100%, so all parameters are documented in the schema. The description adds no additional parameter information beyond what's already in the schema (node types are mentioned but not as parameters). With complete schema coverage, 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 states the action ('Set the fill color') and target resource ('a node in Figma'), with specific node types mentioned ('TextNode or FrameNode'). It distinguishes this as a color-setting operation, though it doesn't explicitly differentiate from sibling 'set_stroke_color' beyond the fill/stroke 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 like 'set_stroke_color' or color-related styling tools. The description mentions node types but doesn't explain prerequisites, permissions needed, or when this operation is appropriate versus other color modification approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It describes the mutation action ('swapped', 'applied') but lacks critical behavioral details: whether this is destructive, requires specific permissions, has rate limits, or what happens to existing properties. The phrase 'target instances will be swapped' suggests a potentially significant change, but this isn't elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that efficiently convey the core functionality. The description is front-loaded with the main action. No wasted words, though it could be slightly more structured with explicit prerequisites.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover error conditions, return values, or important behavioral aspects like whether the operation is reversible. The context of 'previously copied overrides' is mentioned but not explained in relation to tool workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters fully. The description adds no additional parameter semantics beyond what's in the schema (e.g., it doesn't explain format of IDs or what 'previously copied' means in relation to parameters). Baseline 3 is appropriate when schema does the heavy lifting.
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 ('Apply previously copied overrides') and target ('selected component instances'), with specific details about swapping to source component and applying override properties. It doesn't explicitly distinguish from sibling tools like 'get_instance_overrides' or 'clone_node', but the purpose is well-defined.
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 mentions 'previously copied overrides' and 'currently selected instances will be used' as contextual hints, but provides no explicit guidance on when to use this tool versus alternatives like 'clone_node' or 'set_multiple_annotations'. No prerequisites or exclusions are 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?
No annotations are provided, so the description carries full burden. It states this is a mutation ('Set'), implying it modifies data, but doesn't disclose behavioral traits like whether changes are reversible, permission requirements, side effects on child elements, or error conditions. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core purpose and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks critical context like what the tool returns, error handling, or how it interacts with other layout tools. The high schema coverage helps, but doesn't compensate for missing behavioral and output information.
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 parameters. The description adds no additional meaning beyond what's in the schema—it doesn't explain parameter interactions, default behaviors, or practical examples. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and target ('layout mode and wrap behavior of a frame in Figma'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this tool from similar sibling tools like 'set_layout_sizing' or 'set_item_spacing', which also configure layout properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., requires a frame node), exclusions, or compare it to related tools like 'set_layout_sizing' for sizing behavior or 'create_frame' for initial setup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'Set[s]' modes, implying a mutation operation, but does not cover critical aspects like whether this requires specific permissions, if changes are reversible, potential side effects, or error handling. This leaves significant gaps in understanding the tool's behavior beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and target, making it easy to parse quickly, which is ideal for conciseness in tool descriptions.
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 complexity of a mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on behavioral traits, error conditions, return values, or how it integrates with sibling tools. For a tool that modifies layout settings, more context is needed to ensure safe and effective use by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for all parameters, including enums and constraints. The description does not add any semantic details beyond what the schema provides, such as explaining the practical implications of 'HUG' vs 'FILL' modes. Thus, it meets the baseline for adequate but not enhanced parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the target ('horizontal and vertical sizing modes for an auto-layout frame in Figma'), making the purpose evident. However, it does not explicitly differentiate this tool from sibling tools like 'set_layout_mode' or 'resize_node', which might also involve layout adjustments, leaving some ambiguity about its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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. With siblings like 'set_layout_mode' and 'resize_node' that could relate to layout changes, there is no mention of specific contexts, prerequisites, or exclusions, leaving the agent to infer usage without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the action without behavioral details. It doesn't disclose whether this is a mutation (implied by 'Set'), what permissions are needed, if it's idempotent, how errors are handled, or what 'parallelly' means operationally. This leaves significant behavioral gaps for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point without unnecessary words. However, it could be slightly more structured by front-loading key distinctions (e.g., 'batch operation for multiple annotations') to improve immediate comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't cover behavioral aspects (permissions, side effects), doesn't explain the return value or error handling, and doesn't differentiate from sibling tools. Given the complexity of batch annotation operations, more context 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?
The description adds no parameter-specific information beyond what's already in the schema (which has 100% coverage). It doesn't explain the relationship between the top-level 'nodeId' and nested 'nodeId' in annotations, or clarify what 'parallelly' means for the 'annotations' array processing. Baseline 3 is appropriate since the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set multiple annotations parallelly') and the target ('in a node'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from its sibling 'set_annotation' (singular vs. multiple), which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'set_annotation' (for single annotations) or 'get_annotations' (for retrieval). There's no mention of prerequisites, constraints, or typical use cases, leaving the agent without contextual usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Set' (implying mutation/write) and 'parallelly' (suggesting concurrent updates), but doesn't disclose critical behavioral traits: whether this is destructive (replaces existing text), requires specific permissions, has rate limits, or what happens on failure. For a mutation tool with zero annotation coverage, this is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse. Every word earns its place without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'parallelly' entails operationally, what the tool returns (success/failure indicators), error conditions, or side effects. For a tool that modifies multiple text nodes, more context is needed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters ('nodeId', 'text') well-documented in the schema. The description adds no additional meaning beyond implying parallel processing for multiple text nodes. Since the schema does the heavy lifting, 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 states the action ('Set multiple text contents parallelly') and target resource ('in a node'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'set_text_content' (singular vs. multiple) or 'set_instance_overrides' (which might also modify text). The purpose is clear but 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. There's no mention of prerequisites (e.g., needing node IDs), when-not-to-use scenarios, or explicit alternatives like 'set_text_content' for single updates. The agent must infer usage from the name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states this is a mutation ('Set padding values') but doesn't mention permissions needed, whether changes are reversible, error conditions (e.g., invalid nodeId), or side effects. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose with zero wasted words. It immediately communicates what the tool does without unnecessary elaboration, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens on success (e.g., returns updated frame object), error handling, or important constraints like frame type requirements. Given the complexity of modifying design elements, more context 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 description coverage is 100%, so the schema already documents all parameters thoroughly. The description doesn't add any parameter-specific context beyond what's in the schema (e.g., units for padding values, whether padding is in pixels, default behaviors). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set padding values') and target resource ('an auto-layout frame in Figma'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'set_item_spacing' or 'set_layout_mode' that also modify auto-layout properties, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., the frame must already exist and be in auto-layout mode), exclusions, or comparisons to similar tools like 'set_item_spacing' for spacing between items versus padding within a frame.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Set' implies a mutation operation, the description doesn't disclose whether this requires specific permissions, whether changes are reversible, what happens if the node doesn't exist, or any rate limits. It provides minimal behavioral context beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states exactly what the tool does with zero wasted words. It's appropriately sized and front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens on success/failure, what the tool returns, or provide any context about the Figma environment. Given the complexity of modifying design elements and the lack of structured safety information, more guidance 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 description coverage is 100%, so the schema already documents all 6 parameters thoroughly. The description doesn't add any parameter semantics beyond what's in the schema - it doesn't explain relationships between parameters, provide examples, or clarify edge cases. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and target ('stroke color of a node in Figma'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from similar sibling tools like 'set_fill_color' or 'set_text_content' beyond the specific property being modified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., needing a valid node ID), when not to use it, or what other tools might be more appropriate for related tasks like setting fill color or other node properties.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a mutation operation ('Set') but lacks critical details: whether this requires edit permissions, if changes are reversible, potential side effects (e.g., text overflow), or error conditions (e.g., invalid nodeId). This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple tool with two 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 this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address behavioral aspects (permissions, reversibility), error handling, or return values. For a tool that modifies content in a design system, more context is needed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly documented in the schema. The description adds no additional meaning beyond what the schema provides (e.g., format of nodeId, text encoding, or constraints). Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and target resource ('text content of an existing text node in Figma'), making the purpose immediately understandable. It distinguishes from siblings like 'create_text' (creation vs. modification) and 'set_multiple_text_contents' (single vs. multiple nodes), though the differentiation could be more explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid text node ID), exclusions (e.g., not for non-text nodes), or comparisons to siblings like 'set_multiple_text_contents' for bulk updates or 'create_text' for new nodes.
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 offers minimal information. It states this is a creation operation but doesn't mention whether it requires specific permissions, what happens on success/failure, whether the text becomes part of the current selection, or any rate limits. For a mutation tool with zero annotation coverage, this leaves significant behavioral questions unanswered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the core purpose without unnecessary words. It's appropriately sized for a tool with comprehensive schema documentation and gets straight to the point with zero wasted text.
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 creation tool with no annotations and no output schema, the description is minimally adequate. The schema provides excellent parameter documentation, but the description doesn't address behavioral aspects like what the tool returns, error conditions, or integration with the Figma document structure. Given the mutation nature of the tool and lack of output schema, more contextual information would be helpful.
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 description coverage is 100%, so the schema already documents all 8 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema, which is acceptable given the comprehensive schema documentation. The baseline score of 3 reflects adequate coverage through 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 ('Create') and resource ('new text element in Figma'), making the purpose immediately understandable. However, it doesn't differentiate this tool from other creation tools like create_frame or create_rectangle, which would require mentioning it specifically creates text elements rather than other types of design elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like create_frame, create_rectangle, and set_text_content available, there's no indication whether this is for creating standalone text elements versus modifying existing ones, or how it relates to other text manipulation tools like set_multiple_text_contents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get detailed information' but doesn't specify what information is included, whether it's read-only, if it requires permissions, or how it handles errors. For a tool with no annotation coverage, this is insufficient to inform safe and effective use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any wasted words. It's front-loaded and appropriately sized for a simple tool, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (0 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what 'detailed information' entails, the return format, or behavioral aspects like read-only nature. For a tool in a design context with siblings that handle specific data, more context is needed to guide the agent effectively.
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 schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, but it could hint at implicit context like 'current document' if relevant. Since no parameters exist, a baseline of 4 is appropriate as there's nothing to compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'detailed information about the current Figma document', making the purpose specific and understandable. However, it doesn't explicitly differentiate from siblings like 'get_node_info' or 'get_nodes_info', which focus on nodes rather than the entire document, leaving some ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention context like needing document-level metadata, prerequisites, or exclusions, such as not using it for node-specific details. This lack of usage context leaves the agent to infer based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions that overrides 'can be applied to other instances', which hints at potential use cases, but doesn't disclose critical behavioral traits like whether this is a read-only operation, what permissions are needed, what format the overrides are returned in, or whether there are any rate limits. For a tool with zero annotation coverage, this leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with two sentences that each serve a purpose: the first states the core functionality, the second explains potential applications. It's front-loaded with the main purpose. There's minimal waste, though the second sentence could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete for a tool that presumably returns structured override data. It doesn't explain what format the overrides are returned in, what properties are included, or how to interpret the results. For a tool with zero structured metadata, the description should provide more complete context about the operation and its outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents the single optional parameter. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3. It doesn't explain what happens when nodeId is omitted beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'override properties from a selected component instance', making the purpose understandable. It distinguishes from siblings like 'get_node_info' or 'get_styles' by focusing specifically on overrides. However, it doesn't explicitly differentiate from 'set_instance_overrides' beyond the get/set distinction.
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 needing to copy overrides between instances, but doesn't explicitly state when to use this tool versus alternatives like 'get_node_info' or 'get_styles'. It mentions applying overrides to other instances, which provides some context, but lacks clear when-not-to-use guidance or explicit alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it 'gets' components, implying a read-only operation, but doesn't specify details like whether it returns a list, format, pagination, or error conditions. For a tool with zero annotation coverage, this is inadequate, as it lacks critical 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, efficient sentence that directly states the tool's purpose without any wasted words. It's front-loaded and appropriately sized for a simple tool, making it easy to parse quickly.
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 no output schema, the description is incomplete for a tool that retrieves data. It doesn't explain what 'local components' entail, the return format, or any limitations. For a read operation with no structured output information, this leaves significant gaps in understanding how to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the input schema has 100% description coverage (though empty). The description doesn't need to add parameter information, so it meets the baseline for no parameters. It implies no inputs are required, which aligns with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('all local components from the Figma document'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_document_info' or 'get_node_info', which might also retrieve document-related information, so it doesn't fully distinguish itself in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, such as whether it's for retrieving components vs. other document elements or how it relates to tools like 'get_document_info'. This leaves the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action 'set' but lacks details on behavioral traits like whether it modifies existing properties, requires specific permissions, or has side effects. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with zero waste. It front-loads the core action and resource efficiently, making it easy to parse and understand without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema, and no annotations), the description is minimally adequate. It states what the tool does but lacks context on usage, behavioral details, or output expectations, leaving gaps that could hinder an agent's effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for nodeId, radius, and corners. The description adds no additional meaning beyond what the schema provides, such as explaining the units for radius or the default behavior if corners is omitted. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'set' and the resource 'corner radius of a node in Figma', making the purpose specific and understandable. It distinguishes itself from siblings like set_fill_color or set_stroke_color by focusing on corner radius, though it doesn't explicitly contrast with them beyond the naming.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing a valid node ID, or compare it to similar tools like set_layout_mode or set_padding, leaving the agent to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool modifies a frame (implying mutation) but doesn't disclose permission requirements, whether changes are reversible, rate limits, or what happens if the frame isn't auto-layout. The description mentions the itemSpacing parameter's limitation with SPACE_BETWEEN alignment, which adds some behavioral context, but overall coverage is minimal for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized for a simple tool with two parameters and front-loads the core functionality. Every word earns its place with zero waste.
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 mutation tool with no annotations and no output schema, the description is minimally adequate. It covers the basic purpose but lacks behavioral context, error conditions, and relationship to other layout tools. The 100% schema coverage helps with parameters, but overall completeness is limited given the tool's potential complexity in a design system 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%, providing complete parameter documentation. The description adds no additional parameter semantics beyond what's in the schema. It mentions 'distance between children' which echoes the schema's 'itemSpacing' description, but doesn't clarify units, valid ranges, or edge cases. With high schema coverage, 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 states the action ('Set distance') and target ('children in an auto-layout frame'), providing a specific verb+resource combination. It distinguishes from siblings like 'set_padding' or 'set_layout_mode' by focusing specifically on child spacing. However, it doesn't explicitly differentiate from all potential layout-related tools beyond the auto-layout context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an auto-layout frame), when-not-to-use scenarios, or how it relates to sibling tools like 'set_layout_sizing' or 'set_padding'. The agent must infer usage from the description alone without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but doesn't describe how it behaves: e.g., whether it returns structured data, what happens if no selection exists (error vs. empty result), or if it's read-only (implied by 'Get' but not explicit). For a tool with zero annotation coverage, this leaves significant gaps in understanding its operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core functionality without any fluff. It's front-loaded with the key action and resource, making it easy to parse. Every word earns its place, adhering to best practices for concise tool descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is adequate as a basic overview. However, it lacks details on output format (e.g., what information is returned about the selection) and behavioral context (e.g., error handling), which could help an agent use it more effectively. For a read operation in a design tool context, more completeness would be beneficial.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't mention parameters, focusing instead on the tool's purpose. This aligns with the baseline expectation for zero-parameter tools, where the description needn't compensate for schema gaps.
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 information') and target resource ('current selection in Figma'), making the purpose immediately understandable. However, it doesn't distinguish itself from similar sibling tools like 'get_node_info' or 'get_nodes_info', which also retrieve information about Figma elements, so it doesn't fully differentiate its specific scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't specify if this is for real-time selection updates, how it differs from 'get_node_info' (which might require node IDs), or any prerequisites like needing an active selection in Figma. Without such context, the agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves styles but doesn't describe what 'styles' includes (e.g., text, color, effect styles), whether it's read-only (implied by 'Get'), potential rate limits, authentication needs, or the return format. For a tool with zero annotation coverage, 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, efficient sentence that front-loads the core purpose ('Get all styles'). There is no wasted language, repetition, or unnecessary elaboration, making it highly concise and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, no annotations, and no output schema, the description is minimally adequate. It specifies the resource ('styles') and scope ('current Figma document'), but lacks details on return values, error conditions, or behavioral traits. For a simple read operation, it meets basic needs but leaves room for improvement in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter details beyond the schema, but with no parameters, this is appropriate. A baseline of 4 is applied as it meets the requirement for parameterless tools without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('all styles from the current Figma document'), making the purpose immediately understandable. It doesn't explicitly differentiate from siblings like 'get_local_components' or 'get_document_info', but the specificity of 'styles' provides inherent distinction. The description avoids tautology by not just restating the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an open document), exclusions, or compare it to similar tools like 'get_local_components' or 'get_document_info'. The agent must infer usage solely from the tool name and description without explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it 'Get[s] detailed information' but doesn't disclose behavioral traits like whether it's read-only (implied but not explicit), requires specific permissions, has rate limits, or what happens with no selection. For a tool with zero annotation coverage, this leaves significant gaps in understanding its operation and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Get detailed information about the current selection in Figma') and adds a clarifying detail ('including all node details'). There is zero waste, and every word contributes to understanding the tool's function.
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 0 parameters, 100% schema coverage, and no output schema, the description is minimally adequate but incomplete. It lacks context on prerequisites (e.g., requires a selection), behavioral details (e.g., error handling), and output specifics (e.g., format of 'detailed information'). For a tool in a complex environment like Figma with many siblings, more guidance would be beneficial.
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 schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add param info beyond the schema, but with no params, the baseline is 4 as it adequately addresses the lack of inputs without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'detailed information about the current selection in Figma', specifying it includes 'all node details'. It distinguishes from siblings like 'get_selection' by emphasizing detailed node information rather than just selection data. However, it doesn't explicitly contrast with 'get_node_info' or 'get_nodes_info', which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'get_selection', 'get_node_info', or 'get_nodes_info'. It mentions 'current selection' but doesn't clarify prerequisites (e.g., requires an active selection) or exclusions (e.g., works only in Figma editor context). No explicit alternatives or context boundaries are 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?
No annotations are provided, so the description carries full burden. It states this is a 'Set' operation (implying mutation) but doesn't disclose behavioral traits like whether changes are reversible, permission requirements, error conditions, or what happens if applied to non-auto-layout frames. The description is minimal and lacks crucial context 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, efficient sentence that front-loads the core purpose without any wasted words. It directly communicates the tool's function in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects (e.g., side effects, error handling) or provide usage context. While the schema covers parameters well, the overall tool context lacks necessary disclosure for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed parameter descriptions already in the schema (e.g., explaining MIN/MAX mappings and SPACE_BETWEEN behavior). The tool description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 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 clearly states the specific action ('Set') and target resource ('primary and counter axis alignment for an auto-layout frame in Figma'). It distinguishes this from sibling tools like set_item_spacing or set_layout_mode by specifying the exact alignment properties being modified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While it mentions 'auto-layout frame', it doesn't specify prerequisites (e.g., the frame must already have auto-layout enabled) or contrast with similar tools like set_layout_mode that might affect related properties.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses critical behavioral traits: the output requires immediate processing with a specific prompt and tool ('reaction_to_connector_strategy' and 'create_connections'), which is essential context beyond basic functionality. However, it doesn't cover other aspects like error handling, rate limits, or authentication needs, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, but the second sentence is lengthy and includes specific tool/prompt names, which may be necessary but adds complexity. It's front-loaded with the core purpose, but the critical instruction could be more streamlined. Overall, it's adequately sized but not optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (no annotations, no output schema, 1 parameter with full schema coverage), the description is fairly complete. It explains the purpose, usage guidelines, and critical behavioral context (output processing). However, it lacks details on return values or error cases, which would enhance completeness for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'nodeIds' documented as 'Array of node IDs to get reactions from.' The description adds no parameter-specific information beyond what the schema provides. According to the rules, with high schema coverage (>80%), the baseline score is 3 when no param info is in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get Figma Prototyping Reactions from multiple nodes.' It specifies the verb ('Get') and resource ('Figma Prototyping Reactions'), and distinguishes it from siblings like 'get_annotations' or 'get_node_info' by focusing on reactions. However, it doesn't explicitly differentiate from hypothetical similar tools (e.g., 'get_single_reaction'), though none exist 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'CRITICAL: The output MUST be processed using the 'reaction_to_connector_strategy' prompt IMMEDIATELY to generate parameters for connector lines via the 'create_connections' tool.' This clearly states when to use it (as a precursor to 'create_connections') and implies an alternative workflow, though it doesn't specify when not to use it or name other alternatives directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

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

Copy to your README.md:

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

Score Badge

Copy to your README.md:

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

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/andreycretsu/cursor-talk-to-figma-mcp-main'

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