Server Quality Checklist

Tool Scores

• clone_nodeC
  2.9/5.0
  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. 'Clone' implies a mutation operation, but the description doesn't specify whether this requires edit permissions, what happens to the original node, or if the clone inherits properties. It lacks details on error conditions, rate limits, or response format.

  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 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?

  For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., the cloned node's ID or properties), error handling, or behavioral nuances like whether x and y are optional or default values. Given the complexity of cloning in a design tool, 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 fully documents all three parameters (nodeId, x, y). The description adds no additional meaning beyond the schema, such as explaining coordinate systems or node ID formats. Baseline 3 is appropriate when the schema handles parameter documentation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb ('clone') and resource ('an existing node in Figma'), making the purpose unambiguous. However, it doesn't explicitly differentiate this from sibling tools like 'create_component_instance' or 'create_frame', which might also create new nodes but through different mechanisms.

  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 node), exclusions, or comparisons to sibling tools like 'create_frame' or 'create_rectangle' for creating new nodes from scratch.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_component_instanceC
  2.9/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Create an instance' which implies a write/mutation operation, but doesn't address permissions (e.g., edit access required), side effects (e.g., adds to document), error conditions (e.g., invalid componentKey), or response format. For a mutation tool with zero annotation coverage, this is a significant gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that gets straight to the point with zero wasted words. It's appropriately sized for a tool with clear purpose and good schema coverage, though it could benefit from additional context.

  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 'instance' means in Figma context, what happens on success/failure, or how this differs from similar creation tools. Given the complexity of Figma operations and lack of structured behavioral data, 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 three parameters (componentKey, x, y) with basic descriptions. The description adds no additional parameter semantics beyond what's in the schema, such as coordinate system details or componentKey format 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 ('Create an instance') and resource ('component in Figma'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'clone_node' or 'create_frame' that might also create visual elements, leaving some ambiguity about when this specific tool is appropriate versus alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives like 'clone_node' or 'create_frame'. It doesn't mention prerequisites (e.g., needing an existing component), context (e.g., must be in a Figma document), or exclusions (e.g., cannot create instances of non-existent components).

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_frameC
  2.9/5.0
  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. 'Create' implies a write/mutation operation, but the description doesn't mention permission requirements, whether the creation is reversible, what happens on failure, or what the tool returns. For a creation 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 communicates the core purpose without any wasted words. It's appropriately sized for a tool with a straightforward primary function, though the brevity comes at the cost of missing contextual 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 creation tool with 9 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what a 'frame' is in Figma context, what happens after creation, what gets returned, or how this differs from other creation tools. The agent would need to rely heavily on the schema alone.

  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 all parameters well-documented in the schema itself. The description adds no parameter information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.

  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 tool from similar sibling tools like 'create_rectangle' or 'create_component_instance', which would require specifying what makes a frame distinct from other Figma 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 multiple creation tools available (create_frame, create_rectangle, create_text, create_component_instance), the agent receives no help in choosing between them. There's also no mention of prerequisites, dependencies, or typical use cases.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_rectangleC
  2.9/5.0
  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 'Create' which implies a write/mutation operation, but doesn't disclose behavioral traits like permissions needed, whether it's destructive to existing elements, rate limits, or what happens on success/failure. This leaves significant gaps for a mutation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, 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?

  For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., the new rectangle's ID), error conditions, or behavioral context like how it interacts with Figma's document structure. This leaves the agent with insufficient information for reliable use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so all parameters are documented in the schema. The description adds no additional meaning about parameters beyond implying creation of a rectangle, which aligns with the schema. This meets the baseline of 3 when schema coverage is high.

  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 the resource ('in Figma'), which is specific and unambiguous. However, it doesn't distinguish this tool from other creation tools like 'create_frame' or 'create_text' in the sibling list, which would require mentioning what makes rectangles unique (e.g., geometric shape with width/height).

  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_text', there's no indication of when a rectangle is appropriate (e.g., for basic shapes vs. containers or text elements), nor any prerequisites or exclusions mentioned.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• create_textC
  2.9/5.0
  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 for behavioral disclosure. 'Create a new text element' implies a write/mutation operation, but the description doesn't mention permissions needed, whether this requires being in edit mode, what happens on failure, or any rate limits. For a mutation tool with zero annotation coverage, this is insufficient.

  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 any 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 8 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens after creation (e.g., returns a node ID), doesn't mention error conditions, and provides no context about the Figma environment needed for successful execution. The description should do more given the complexity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  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. According to the rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.

  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 from sibling tools like 'set_text_content' or 'clone_node' that might also create or modify text elements, 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 siblings like 'set_text_content' (which might update existing text) and 'clone_node' (which might duplicate text), there's no indication of when this specific creation tool is appropriate versus those other options.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• delete_nodeC
  2.9/5.0
  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. 'Delete' implies a destructive mutation, but the description doesn't specify whether this is permanent, reversible, requires specific permissions, affects other nodes, or has rate limits. For a destructive operation with zero annotation coverage, this is a significant gap in safety and 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 appropriately sized for a simple operation and front-loads the core action. Every word earns its place in conveying the essential purpose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a destructive mutation tool with no annotations and no output schema, the description is incomplete. It doesn't address critical context like what 'delete' means in Figma's context (permanent removal from file? moves to trash?), error conditions, or what happens to child elements. The agent lacks sufficient information to use this tool safely and 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%, with the single parameter 'nodeId' clearly documented in the schema. The description adds no additional parameter context beyond what the schema provides (no format examples, no constraints on valid node IDs). The baseline score of 3 reflects adequate coverage 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 ('Delete') and target resource ('a node from Figma'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from other destructive operations like 'clone_node' or 'move_node' in terms of what type of deletion occurs (permanent vs temporary, reversible vs irreversible).

  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), exclusions (e.g., cannot delete locked nodes), or what happens after deletion (e.g., whether parent-child relationships are affected). With multiple sibling tools that manipulate nodes, this lack of differentiation is problematic.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• export_node_as_imageC
  2.9/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool exports an image but doesn't describe what happens during export (e.g., file generation, download, or API response format), permissions required, rate limits, or side effects, which is insufficient for a mutation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, 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 (a mutation with 3 parameters) and lack of annotations and output schema, the description is incomplete. It doesn't explain the export result (e.g., image data, file path, or error handling), leaving critical gaps for an AI agent to use it effectively.

  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 parameters like 'nodeId', 'format', and 'scale'. The description adds no additional meaning beyond the schema, such as explaining parameter interactions or constraints, but meets the baseline since the schema handles 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 ('export') and resource ('a node as an image from Figma'), making the tool's purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_node_info' or 'clone_node', which might also involve node operations but serve different purposes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid node ID), exclusions, or comparisons to sibling tools like 'get_node_info' for non-export purposes, leaving usage context unclear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• join_channelC
  2.9/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Join') but doesn't clarify what 'join' entails (e.g., does it require permissions, is it reversible, what happens on success/failure?). This leaves critical behavioral traits like side effects or authentication needs unspecified.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, 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 of a 'join' operation (which implies potential side effects like authentication or state changes), lack of annotations, and no output schema, the description is insufficient. It doesn't explain what 'communicate with Figma' means in practice, return values, or error conditions, leaving gaps for the agent to handle.

  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 additional meaning beyond this, such as format examples or constraints, 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 action ('Join') and 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 sibling tools like 'get_document_info' or 'create_frame', which are unrelated operations.

  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 to be in a Figma workspace), exclusions, or related tools, leaving the agent to infer usage context solely from the purpose statement.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• move_nodeC
  2.9/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('move') but lacks details on permissions required, whether the move is destructive (e.g., affects parent-child relationships), error handling (e.g., invalid positions), or rate limits. 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's front-loaded and wastes no space, 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.

  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 (moving nodes) with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like side effects, return values, or error conditions, which are crucial for safe and effective use in a Figma context with multiple sibling tools.

  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 parameter definitions (nodeId, x, y). The description adds no additional semantic context beyond implying movement to coordinates, so it meets the baseline of 3 where the schema does the heavy lifting without compensating for any 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 ('move') and resource ('a node') with the context 'to a new position in Figma', making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'resize_node' or 'clone_node', which also manipulate node properties, leaving room for ambiguity in sibling 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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing node permissions), exclusions (e.g., not for moving groups vs. individual nodes), or comparisons to siblings like 'resize_node' for size changes or 'clone_node' for duplication, leaving usage context unclear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• resize_nodeC
  2.9/5.0
  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. 'Resize' implies a mutation operation, but it doesn't state whether this requires specific permissions, if changes are reversible, what happens to child elements, or any rate limits. 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 with zero waste—it directly states the action and target. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly without unnecessary elaboration.

  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 (e.g., permissions, side effects), usage context, and what the tool returns. This leaves the agent with insufficient information to use the tool effectively in a real scenario.

  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, width, height) with clear descriptions. The description adds no additional meaning beyond the schema, such as unit explanations (e.g., pixels) or constraints on width/height values. 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 ('Resize') and resource ('a node in Figma'), making the purpose immediately understandable. It distinguishes from siblings like 'move_node' (which changes position) and 'set_corner_radius' (which modifies shape properties). However, it doesn't specify what type of node can be resized or mention constraints, keeping it from 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. It doesn't mention prerequisites (e.g., needing a valid node ID), exclusions (e.g., nodes that cannot be resized), or related tools like 'move_node' for repositioning. This leaves the agent with minimal context for decision-making.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• set_corner_radiusC
  2.9/5.0
  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 modifies a node, implying mutation, but does not cover permissions, reversibility, error conditions, or effects on other node properties. 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 directly states the tool's purpose without unnecessary words. It is front-loaded and appropriately sized, 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 that this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits, return values, or error handling, which are crucial for effective tool invocation in a complex environment like Figma.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, so the input schema fully documents the parameters (nodeId, radius, corners). The description adds no additional meaning beyond what the schema provides, such as parameter interactions or examples, but does not need to compensate for gaps, 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 ('Set') and the resource ('corner radius of a node in Figma'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'resize_node' or 'set_fill_color', which also modify node properties, so it lacks sibling distinction for 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, such as other node modification tools in the sibling list. It mentions the context of Figma but offers no exclusions, prerequisites, or comparisons, leaving usage unclear beyond the basic action.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• set_fill_colorC
  2.9/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool modifies a node's fill color, implying a mutation operation, but doesn't mention permissions, side effects, error conditions, or response format. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence with zero wasted words. It front-loads the core purpose and includes relevant node type constraints. Every element 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?

  For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., permissions, side effects), error handling, and return values. Given the complexity of modifying Figma nodes and the absence of structured safety hints, more context is needed for effective 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?

  Schema description coverage is 100%, with clear documentation for all parameters (nodeId, r, g, b, a). The description adds no additional parameter semantics beyond what the schema provides, such as color format details or nodeId sourcing. 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 ('Set the fill color') and target resource ('a node in Figma'), specifying it can be TextNode or FrameNode. This distinguishes it from sibling tools like 'set_stroke_color' or 'set_text_content', though it doesn't explicitly contrast with all alternatives. The purpose is specific and actionable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage 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 'set_stroke_color' or other styling tools. The description mentions node types (TextNode or FrameNode) but doesn't clarify prerequisites, exclusions, or typical scenarios. Usage context 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.

• set_stroke_colorC
  2.9/5.0
  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. 'Set' implies a mutation, but the description doesn't disclose whether this requires specific permissions, if changes are reversible, what happens to existing stroke settings, or error conditions. For a mutation tool with zero annotation coverage, this lacks critical behavioral context about side effects 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 with zero waste. It's front-loaded with the core action and target, making it immediately scannable. Every word earns its place, and there's no redundant or verbose phrasing.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns, error handling, or behavioral nuances. While the schema covers parameters well, the overall context for safe and effective use is lacking, especially for a tool that modifies design assets.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with all parameters well-documented in the schema (e.g., 'Alpha component (0-1)', 'The ID of the node to modify'). The description adds no parameter semantics beyond what the schema provides, but since schema coverage is high, baseline 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 ('Set') and target ('stroke color of a node in Figma'), making the purpose immediately understandable. It distinguishes from siblings like 'set_fill_color' by specifying stroke rather than fill, though it doesn't explicitly contrast with all siblings. The description is specific but could be more precise about what 'set' entails.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives like 'set_fill_color' or 'set_corner_radius'. It doesn't mention prerequisites (e.g., needing a valid nodeId) or contextual constraints. Usage is implied by the action but without explicit when/when-not instructions or named alternatives.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• set_text_contentC
  2.9/5.0
  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 the tool modifies an existing node, implying mutation, but lacks critical behavioral details: whether it requires specific permissions, if changes are reversible, potential side effects (e.g., text overflow), or error conditions (e.g., invalid nodeId). 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 states the action, target, and context without redundancy. It is front-loaded and efficiently conveys the core purpose, 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 tool's mutation nature, lack of annotations, and no output schema, the description is incomplete. It fails to address behavioral aspects like permissions, reversibility, or response format, which are crucial for safe and effective use. While the schema covers parameters well, the overall context for a write operation remains underspecified.

  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 descriptions for both parameters ('nodeId' and 'text'). The description adds no additional semantic context beyond what the schema provides, such as format examples for nodeId or text constraints. Since the schema does the heavy lifting, the baseline score of 3 is appropriate, but no extra value is contributed.

  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 itself from siblings like 'create_text' (which creates new text) and 'delete_node' (which removes nodes). However, it doesn't explicitly mention what distinguishes it from other modification tools like 'set_fill_color' or 'set_stroke_color' beyond the resource type.

  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 minimal guidance by specifying 'existing text node,' which implies it cannot be used on non-text nodes or newly created ones. However, it offers no explicit when-to-use rules, alternatives for similar operations, or prerequisites (e.g., node must be editable). Without this, an agent might misuse it or overlook better options among siblings.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_document_infoB
  3.1/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations, the description carries full burden but only states it 'gets' information without detailing behavior such as permissions needed, rate limits, or what 'detailed information' entails. It lacks context on whether this is a read-only operation or has other 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, efficient sentence that front-loads the key action and resource without any wasted words. It's appropriately sized for a simple tool with no 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?

  For a tool with no annotations, no output schema, and no parameters, the description is incomplete. It doesn't explain what 'detailed information' includes or the return format, leaving significant gaps in understanding the tool's behavior and output.

  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 with 100% schema coverage, so no parameter documentation is needed. The description doesn't add param info, but this is acceptable as there are no parameters to describe, aligning with the baseline for zero parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Get detailed information') and resource ('current Figma document'), making the purpose understandable. It doesn't distinguish from siblings like 'get_node_info' or 'get_styles', which would require more specificity about what 'detailed information' includes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided on when to use this tool versus alternatives like 'get_node_info' or 'get_styles'. The description implies it's for document-level information, but this is not explicitly stated, leaving usage context unclear.

  Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

• get_local_componentsB
  3.1/5.0
  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 what the tool does but doesn't describe how it behaves: no information about return format (list, structure, pagination), permissions needed, rate limits, or error conditions. For a read operation 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.

  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 for a simple retrieval tool and front-loads the core functionality. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no annotations, no output schema, and a simple but potentially complex operation (retrieving 'all local components'), the description is insufficient. It doesn't explain what 'local components' means in Figma context, what format the return takes, or any limitations. For a tool that could return substantial data, more context is needed.

  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 with 100% schema description coverage (empty schema). The description doesn't need to compensate for any parameter gaps. Baseline for 0 parameters is 4, as there's nothing to document beyond what the schema already provides (no parameters).

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb 'Get' and resource 'local components from the Figma document', making the purpose unambiguous. It doesn't explicitly distinguish from siblings like 'get_styles' or 'get_document_info', but the specificity of 'local components' provides reasonable differentiation. It avoids tautology by not just restating the name.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives like 'get_document_info' or 'get_styles'. It doesn't mention prerequisites, context, or exclusions. The agent must infer usage from the name and 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.

• get_node_infoB
  3.1/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a read operation ('Get'), but doesn't mention permissions, rate limits, error conditions, or what 'detailed information' includes. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every element contributing to clarity.

  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 (1 parameter, 100% schema coverage) and lack of output schema, the description is minimally adequate but incomplete. It doesn't explain what 'detailed information' entails or potential behavioral aspects, which could hinder an agent's ability to use it effectively without trial and error.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 100%, with the single parameter 'nodeId' documented as 'The ID of the node to get information about'. The description adds no additional parameter semantics beyond what the schema provides, 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 verb 'Get' and resource 'detailed information about a specific node in Figma', making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_document_info' or 'get_selection', which also retrieve information but about different resources.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage 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 for selecting this over similar tools like 'get_document_info', or any exclusions, leaving the agent to infer usage based on 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.

• get_selectionB
  3.1/5.0
  Behavior2/5

  Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a read operation ('Get information'), but doesn't describe what information is returned, format, error conditions, or whether it requires specific permissions. For a tool with zero annotation coverage, this leaves significant gaps in understanding how it behaves.

  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 front-loaded with the essential information and contains zero wasted content. This is an excellent example of conciseness for a simple tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the absence of annotations and output schema, the description is insufficiently complete. It doesn't explain what information is returned about the selection, format, or error handling. For a tool that presumably returns structured data about Figma selections, more context about the return value would be helpful despite the lack of output schema.

  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 with 100% schema description coverage, so the schema fully documents the absence of inputs. The description adds no parameter information, which is appropriate since none are needed. The baseline for 0 parameters is 4, as the description doesn't need to compensate for any 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. It distinguishes from siblings like get_node_info or get_document_info by focusing specifically on the current selection rather than general nodes or documents. However, it doesn't specify what type of information is retrieved, leaving some ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides no guidance on when to use this tool versus alternatives like get_node_info or get_document_info. It doesn't mention prerequisites (e.g., whether a selection must exist), nor does it explain what happens if there's no current selection. 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.

• get_stylesB
  3.1/5.0
  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 states it retrieves 'all styles' but doesn't clarify what 'styles' encompass (colors, text styles, effects), whether this includes local vs. library styles, pagination behavior, or error conditions. The description doesn't contradict annotations (none exist), but provides inadequate transparency for a read operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that states exactly what the tool does without unnecessary words. It's front-loaded with the core action ('Get all styles') and specifies the scope ('from the current Figma document'). Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a read operation with no annotations, no output schema, and zero parameters, the description is insufficient. It doesn't explain what 'styles' include, the return format, or how this differs from similar retrieval tools. While the lack of parameters simplifies things, the description should provide more context about the data returned and its relationship to other document query tools.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, and schema description coverage is 100% (empty schema). The description appropriately doesn't discuss parameters since none exist, and it correctly implies this is a parameterless operation that retrieves all styles from the current context. This meets the baseline for zero-parameter tools.

  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 styles from the current Figma document'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_document_info' or 'get_local_components', which also retrieve document metadata but focus on different resources.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage 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 whether this is for retrieving design tokens, when to prefer this over 'get_document_info' for style-related queries, or any prerequisites like needing an open document. The agent must 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.