CC Fig MCP

by agenisea

Overview Schema Related Servers Score Discussions

JavaScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes targeting specific Figma operations like shape creation, styling, or node management, with clear boundaries. However, some overlap exists, such as set_fill_color, set_fill_style_id, and set_fill_variable, which could cause confusion about when to use each for fill operations, though descriptions help clarify their differences.
Naming Consistency5/5
Tool names follow a highly consistent verb_noun pattern throughout, such as create_rectangle, get_node_info, and set_font_size. This predictability makes it easy for agents to understand and select tools based on their intended actions and targets in the Figma domain.
Tool Count2/5
With 50 tools, the count is excessive for a typical MCP server, leading to cognitive overload and potential inefficiency. While Figma is a complex domain, this many tools suggests over-fragmentation of operations, such as having multiple separate tools for text styling (e.g., set_font_size, set_font_weight) that could be consolidated.
Completeness5/5
The tool set provides comprehensive coverage of Figma operations, including CRUD for nodes (create, delete, move, resize), styling (fills, strokes, effects, text properties), component management, variable handling, and utilities like export and grouping. No obvious gaps are present for core design workflows in the domain.
Average 3.1/5 across 50 of 50 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 3 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'clone' implies a mutation/write operation, the description doesn't specify whether this requires edit permissions, whether the clone inherits properties from the original, if it's placed in the same layer/parent, 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 that states the core functionality without any fluff. It's appropriately sized for a simple cloning operation and front-loads the essential information. 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?
For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the clone operation returns, whether it preserves relationships or styles, or how errors are handled. Given the complexity of cloning in a design tool context and the lack of structured metadata, the description should provide more behavioral context to be truly 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?
Schema description coverage is 100%, so the schema already documents all three parameters (nodeId, x, y) with clear descriptions. The description adds no additional parameter semantics beyond what's 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 ('clone') and target resource ('an existing node in Figma'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'create_rectangle' or 'create_text' by focusing on duplication rather than creation from scratch. However, it doesn't specify what types of nodes can be cloned or how the clone relates to the original.
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 preferable to creating new nodes, how it differs from 'duplicate' operations (if any), or what prerequisites exist (e.g., needing an existing node ID). With many sibling creation tools available, this lack of differentiation is a significant gap.
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' implies a write/mutation operation, but the description doesn't specify permissions needed, whether this affects other elements, error conditions, or what happens on success/failure. For a mutation 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 states exactly what the tool does without any wasted words. It's front-loaded with the core action and resource, making it immediately scannable and understandable.
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 'instance' means in Figma context, what gets returned, error handling, or dependencies. Given the complexity of component instantiation in design tools, more context is needed for the agent to use this 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 already documents all three parameters (componentKey, x, y) with basic descriptions. The description adds no additional parameter context beyond implying these are needed to create an instance. This meets the baseline of 3 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') and resource ('instance of a component in Figma'), making the purpose immediately understandable. It distinguishes from siblings like 'create_rectangle' or 'create_text' by specifying it creates component instances rather than primitive shapes. However, it doesn't explicitly differentiate from 'clone_node' which might also create instances in some contexts.
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 (like needing an existing component), when not to use it, or how it differs from similar creation tools like 'create_frame' or 'clone_node'. The agent must infer usage from the name and 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. 'Create a new ellipse' implies a write/mutation operation, but the description doesn't mention permissions needed, whether changes are reversible, rate limits, or what happens on success/failure. For a creation 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 states the core purpose without any wasted words. It's appropriately sized and front-loaded, 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?
For a creation tool with 9 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain what happens after creation (e.g., returns node ID), error conditions, or how it differs from other shape creation tools. The agent lacks critical context for proper tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all 9 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema. According to guidelines, 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 ellipse in Figma'), making the purpose immediately understandable. However, it doesn't differentiate this tool from other shape creation siblings like create_rectangle or create_polygon, which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like create_rectangle or create_polygon. There's no mention of prerequisites, context, or comparison with sibling tools, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Create a new frame' implies a write/mutation operation, but there's no information about permissions required, whether the creation is immediate or requires a save operation, what happens if parameters conflict, or what the tool returns. For a creation tool with 9 parameters and complex nested objects, 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 that states the core purpose without any wasted words. It's appropriately sized and front-loaded, getting straight to the point 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?
For a creation tool with 9 parameters (including complex nested objects for colors), no annotations, and no output schema, the description is inadequate. It doesn't explain what a frame is in Figma context, what happens after creation, whether there are limitations or constraints, or what the tool returns. The agent would need to infer too much from just the 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 schema description coverage is 100%, meaning all parameters are 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, 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 action ('Create') and resource ('new frame in Figma'), making the purpose immediately understandable. However, it doesn't differentiate this tool from other creation tools like create_rectangle or create_ellipse, which would require mentioning what distinguishes a frame from other shape types 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. With many sibling tools for creating different elements (rectangle, ellipse, polygon, star, text), there's no indication of when a frame is appropriate versus other shapes, or whether frames have special properties like being containers for other elements.
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 for behavioral disclosure. 'Create a new polygon' implies a write/mutation operation, but the description doesn't mention permissions needed, whether this modifies existing documents, what happens on failure, or what the return value might be. For a creation tool with 10 parameters and no annotations, 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 that states exactly what the tool does without unnecessary words. It's front-loaded with the core action and resource. Every word earns its place, making it maximally concise while still being clear.
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 10 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens after creation (return value), error conditions, or how this tool fits within the Figma editing workflow. The agent knows what the tool does but not the full context needed 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 already documents all 10 parameters thoroughly with descriptions, types, constraints, and required fields. The description adds no parameter information beyond what's in the schema - it doesn't explain relationships between parameters (like how x/y position relates to parentId) or provide usage examples. With complete schema coverage, the baseline is 3.
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 ('polygon in Figma'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like create_rectangle, create_ellipse, or create_star, which all create different shapes in Figma. The description is specific about what it creates 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. With multiple shape-creation siblings (rectangle, ellipse, star, etc.), there's no indication of when a polygon is appropriate versus other shapes, nor any mention of prerequisites or contextual constraints. 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?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Create a new rectangle' implies a write/mutation operation, but the description doesn't disclose any behavioral traits like permission requirements, whether the rectangle becomes part of the current selection, what happens on creation failure, 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 extremely concise at just 5 words, front-loading the essential information ('Create a new rectangle in Figma') with zero wasted words. Every word earns its place in this minimal but complete statement of 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 no annotations and no output schema, the description is inadequate. It doesn't explain what happens after creation (does it return the new rectangle's ID? does it become selected?), doesn't mention error conditions, and provides no behavioral context. The description should do more to compensate for the lack of structured metadata.
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 provides no parameter information beyond what's already in the schema. However, with 100% schema description coverage, all 6 parameters (x, y, width, height, name, parentId) are already documented in the input schema with clear descriptions. The baseline score of 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 a new rectangle') and the target resource ('in Figma'), which provides specific verb+resource information. However, it doesn't differentiate this tool from sibling tools like create_ellipse, create_frame, or create_polygon, which all create different shapes 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. There are multiple sibling tools for creating different shapes (ellipse, frame, polygon, star), but the description doesn't mention any context for choosing a rectangle over other shapes or when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. 'Create' implies a write/mutation operation, but the description doesn't mention permissions needed, whether the star becomes part of the document immediately, error conditions, or what happens on success/failure. For a creation 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 unnecessary 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 complex creation tool with 11 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens after creation (e.g., returns the new star's ID), error handling, or how the star integrates with the Figma document. The description should provide more context about the tool's behavior and outcomes.
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 semantics beyond what's already in the schema descriptions. According to guidelines, 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 star in Figma'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling shape creation tools like create_ellipse, create_polygon, or create_rectangle, which would require mentioning what makes a star distinct (e.g., points, inner radius).
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 shape creation siblings (ellipse, polygon, rectangle, etc.), there's no indication of when a star is appropriate versus other shapes, nor any 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?
With no annotations provided, the description carries full burden but only states the basic action without behavioral details. It doesn't mention whether this requires specific permissions, if it's destructive (creates new elements), what happens on failure, or typical response format. 'Create' implies mutation but lacks context about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it immediately scannable and efficient for an AI agent.
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 8 parameters, no annotations, and no output schema, the description is insufficient. It doesn't address what the tool returns, error conditions, or how it differs from related text manipulation tools. The agent would need to infer too much from 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 description adds no parameter information beyond what's already in the schema (which has 100% coverage). It doesn't explain relationships between parameters (e.g., how x/y position relates to parentId) or provide usage examples. With complete schema coverage, the baseline is 3 even without additional param details.
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 from other creation tools like create_rectangle or create_ellipse, which would require mentioning it's specifically for text elements with formatting capabilities.
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 sibling tools like set_text_content (for modifying existing text) or set_text_style_id (for applying styles), nor any context about prerequisites like needing a parent frame or being in edit mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Delete') but doesn't explain what 'delete' entails—whether it's permanent, reversible, requires specific permissions, affects child nodes, or has rate limits. This leaves significant gaps 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 wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse at a glance.
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 inadequate. It doesn't cover behavioral aspects like permanence, permissions, or error cases, nor does it explain return values or side effects. Given the complexity of deletion 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%, with the parameter 'nodeId' clearly documented in the schema. The description doesn't add any parameter-specific details beyond what the schema provides, such as format examples or constraints. 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 verb ('Delete') and resource ('a node from Figma'), making the tool's purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'ungroup_nodes' or 'flatten_node' which might also remove or transform nodes in different ways.
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. For example, it doesn't clarify if this is for permanent deletion versus other node-removal operations, or mention prerequisites like needing node permissions. No explicit when/when-not statements or sibling comparisons are included.
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 action ('Flatten') but doesn't explain what flattening entails (e.g., whether it's destructive, irreversible, or affects node hierarchy), nor does it mention permissions, rate limits, or response format. 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 ('Flatten a node in Figma') and provides clarifying examples in parentheses. Every word earns its place, with no redundancy or unnecessary elaboration, 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 mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., destructiveness), error conditions, or what the tool returns. While concise, it doesn't provide enough context for safe and effective use in a Figma design environment.
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 parameter semantics beyond what the schema provides, such as format requirements or examples. Since schema coverage is high, the baseline score of 3 is appropriate, as the description doesn't need to compensate but also adds no 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 ('Flatten a node') and the target resource ('node in Figma'), with specific examples of use cases ('for boolean operations or converting to path'). It distinguishes from siblings like 'group_nodes' or 'ungroup_nodes' by focusing on transformation rather than grouping. However, it doesn't explicitly differentiate from all siblings (e.g., 'export_node_as_image' also transforms nodes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions example use cases but doesn't specify prerequisites, constraints, or when other tools might be more appropriate. For instance, it doesn't clarify when flattening is preferred over other node operations like 'clone_node' or 'resize_node'.
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 'detailed information' but doesn't specify what that includes (e.g., node type, properties, children), whether it requires authentication, if there are rate limits, or how errors are handled. This leaves significant gaps in understanding the tool's behavior beyond basic functionality.
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 purpose without unnecessary words. It's front-loaded with the key action ('Get detailed information'), making it easy to parse. Every part of the sentence earns its place by specifying the resource and 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?
Given the complexity of a Figma node tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'detailed information' entails, how results are structured, or any prerequisites like authentication. For a tool that likely returns rich data, 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?
Schema description coverage is 100%, with the single parameter 'nodeId' clearly documented in the schema as 'The ID of the node to get information about'. The description doesn't add any additional semantic context beyond this, such as format examples or sourcing tips for node IDs. Given the high schema coverage, a 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 'Get' and the resource 'detailed information about a specific node in Figma', making the purpose immediately understandable. However, it doesn't explicitly distinguish this tool from sibling tools like 'get_nodes_info' (plural) or 'get_selection', which might retrieve similar information but with different scopes or parameters.
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. For example, it doesn't clarify if this is for single-node queries versus batch operations (like 'get_nodes_info'), or if it's preferred over 'get_selection' for non-selected nodes. 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Group') but doesn't explain what grouping entails (e.g., creates a parent container, affects layer hierarchy), potential side effects (e.g., may change node positions), permissions needed, or error conditions. 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, direct sentence with zero wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse, though this conciseness comes at the cost of completeness in other dimensions.
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 inadequate. It lacks details on behavior, side effects, error handling, and output format. Given the complexity of grouping operations in design tools and the absence of structured safety hints, more context is needed 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?
Schema description coverage is 100%, so the schema already fully documents both parameters (nodeIds array and optional name). The description adds no additional semantic context beyond what's in the schema, such as format examples or constraints (e.g., minimum node count). 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 ('Group') and resource ('nodes in Figma'), making the tool's purpose immediately understandable. However, it doesn't differentiate this grouping operation from similar sibling tools like 'ungroup_nodes' or 'flatten_node', 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. It doesn't mention prerequisites (e.g., needing existing nodes), exclusions (e.g., cannot group already grouped nodes), or comparisons to sibling tools like 'ungroup_nodes' or 'flatten_node', leaving 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.
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 action ('insert') which implies mutation, but doesn't cover critical aspects like permissions needed, whether the operation is reversible, error conditions (e.g., invalid IDs), or what happens to existing child nodes. 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's appropriately sized and front-loaded, with zero wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks behavioral context (permissions, reversibility, errors), doesn't explain the result of the insertion, and provides no usage guidance. While concise, it doesn't compensate for the missing structured 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%, with clear parameter documentation in the schema itself. The description adds no additional parameter semantics beyond what's already in the schema (e.g., it doesn't explain ID formats, index behavior beyond 'end', or relationships between parent and child nodes). 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 ('insert') and target ('a child node inside a parent node in Figma'), which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'move_node' or 'group_nodes' that also manipulate node relationships, leaving some ambiguity about when this exact insertion operation is needed 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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., whether nodes must exist), exclusions, or compare it to similar tools like 'move_node' or 'group_nodes' in the sibling list, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'join' and 'communicate', implying a connection or subscription action, but doesn't disclose behavioral traits like whether this is idempotent, requires authentication, has side effects (e.g., notifications), rate limits, or what happens on success/failure. The phrase 'communicate with Figma' is vague and adds little operational clarity.
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 front-loads the core action ('Join a specific channel'). It avoids redundancy and waste, though it could be slightly more informative (e.g., by clarifying 'communicate'). The structure is straightforward and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a vague description, the tool is inadequately documented for effective use. The description lacks details on behavior, output, error handling, and context within the sibling set (which are design tools). For a tool with potential side effects (joining/channel operations), this is a significant gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'channel' documented as 'The name of the channel to join'. The description adds no additional meaning beyond this, such as format examples (e.g., channel naming conventions) 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 ('Join') and resource ('a specific channel'), with the purpose being to 'communicate with Figma'. It distinguishes from siblings by focusing on channel joining rather than design operations like creating shapes or manipulating nodes. However, it doesn't specify what 'communicate with Figma' entails (e.g., messaging, notifications, collaboration).
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., needing channel names, being in a Figma workspace), exclusions, or related tools. Given the sibling tools are all design-focused, this stands out as different, but no context is given for why or when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool loads a font asynchronously, implying a non-blocking operation, but doesn't clarify what 'asynchronously' means in practice (e.g., whether it returns immediately, requires polling, or handles errors). It also omits details like permissions needed, rate limits, or what happens if the font isn't available.
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 context, making it easy 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 tool's complexity (asynchronous operation with 2 parameters) and lack of annotations or output schema, the description is incomplete. It doesn't explain what 'asynchronously' entails, potential side effects, error handling, or return values, leaving significant gaps for the agent to operate 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 already documents both parameters ('family' and 'style') adequately. The description adds no additional meaning beyond what's in the schema, such as examples of valid font families or style conventions. 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 ('Load a font asynchronously') and resource ('in Figma'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from sibling tools like 'set_font_name' or 'set_font_weight', which might handle font-related operations differently.
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 document open), exclusions, or compare it to sibling tools like 'set_font_name', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Move') but lacks critical details: whether this requires specific permissions, if it's destructive (likely yes, but unconfirmed), what happens to child nodes, or error conditions (e.g., invalid coordinates). 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 unnecessary 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 insufficient. It doesn't explain what 'move' entails behaviorally (e.g., coordinate system, units), potential side effects, or return values. Given the complexity of node manipulation in Figma, 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%, so the schema fully documents all three parameters (nodeId, x, y). The description adds no additional parameter semantics beyond implying movement involves coordinates, which the schema already covers. 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 verb ('Move') and resource ('a node') with the specific action ('to a new position in Figma'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'resize_node' or 'insert_child' that also manipulate node positioning, 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. It doesn't mention prerequisites (e.g., needing node IDs from 'get_node_info'), exclusions (e.g., not for grouped nodes), or comparisons to siblings like 'resize_node' or 'insert_child' that handle different aspects of node manipulation.
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. 'Resize' implies a mutation operation, but the description doesn't mention whether this requires specific permissions, whether the resize is constrained by parent containers, what happens to child elements, or if there are any rate limits. 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 perfectly concise at just four words, front-loading the essential action and target. Every word earns its place with zero waste or redundancy. This is an excellent example of efficient communication.
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 resizing (success/failure indicators), whether changes are reversible, or how this interacts with other node properties. Given the complexity of modifying Figma nodes and the lack of structured safety information, 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 input schema already documents all three parameters (nodeId, width, height) with their types and constraints. The description adds no additional parameter semantics beyond what's in the schema, such as units for width/height or nodeId format examples. 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 ('Resize') and target ('a node in Figma'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'move_node' or 'set_corner_radius' which also modify node properties, leaving some ambiguity about when to choose this specific operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'move_node', 'set_corner_radius', and various styling tools, there's no indication whether resize should be used for dimensional changes while other tools handle positional or stylistic modifications. No prerequisites or exclusions are mentioned.
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 ('scan') but doesn't explain what 'scan' entails—whether it returns text content, metadata, or something else, or if it has side effects like modifying nodes. This leaves significant gaps for a 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, direct sentence with no wasted words. It's front-loaded with the core action and target, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't clarify what 'scan' returns (e.g., text content, node IDs, or other data), which is critical for a tool that presumably retrieves information. This leaves too much ambiguity 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?
The input schema has 100% description coverage, with the 'nodeId' parameter clearly documented. The description adds no additional semantic context beyond implying the node must be 'selected' (which aligns with the schema). This meets the baseline of 3 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 ('scan') and target ('all text nodes in the selected Figma node'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_styled_text_segments' or 'set_text_content', which also deal with text nodes, 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. It doesn't mention prerequisites (e.g., needing a valid node ID), exclusions, or compare it to siblings like 'get_styled_text_segments' for more detailed text analysis.
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. 'Configure' implies a mutation operation, but the description doesn't specify whether this requires specific permissions, whether changes are destructive or reversible, what happens to existing auto layout settings not mentioned, or what the response looks like. For a mutation tool with 11 parameters and 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 that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every word earning its place. This represents ideal conciseness for a tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 11 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what happens after configuration, what values are returned (if any), error conditions, or behavioral implications. The agent would need to guess about the tool's effects and response format based solely on the parameter schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter clearly documented in the schema itself. The description doesn't add any additional parameter semantics beyond what's already in the schema descriptions. 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 ('configure') and resource ('auto layout properties for a node in Figma'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'set_corner_radius' or 'set_effects' beyond the specific property being configured, 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. It doesn't mention prerequisites (e.g., needing a valid node ID), when auto layout is applicable, or how it relates to sibling tools like 'resize_node' or 'group_nodes' that might affect layout. 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?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It states 'Set' implying mutation but doesn't disclose permissions needed, whether changes are reversible, error conditions (e.g., invalid nodeId), or side effects. 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 that directly states the tool's purpose with zero 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 insufficient. It doesn't explain what happens on success (e.g., returns updated node?), error handling, or visual consequences. Given the complexity of modifying design elements, more context about behavior and outcomes 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 parameters are fully documented in the schema. The description adds no additional meaning beyond what's in the schema (nodeId and radius are self-explanatory, corners array is clearly defined). 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 ('Set') and resource ('corner radius of a node in Figma'), making the purpose immediately understandable. It doesn't explicitly distinguish from sibling tools like 'set_fill_color' or 'set_stroke_color', but the specificity of 'corner radius' provides inherent 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?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., node must support corner radius), exclusions, or related tools like 'resize_node' or 'set_effects' that might affect similar visual 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 states the tool modifies a node's visual effects but doesn't mention whether this is a destructive operation (replacing existing effects), requires specific permissions, has side effects, or how errors are handled. For a mutation 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 directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and target, making it immediately scannable and wasting no space on redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens to existing effects (replaced or merged), what the return value is, error conditions, or permissions needed. Given the complexity of the effects parameter structure and the lack of structured behavioral hints, more contextual information is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents both parameters (nodeId and effects array). The description adds no additional semantic context about parameter usage, constraints, or examples beyond what's in the schema. This meets the baseline for high schema coverage but doesn't enhance 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 target ('visual effects of a node in Figma'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'set_effect_style_id' or other visual property setters, 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?
No guidance is provided on when to use this tool versus alternatives like 'set_effect_style_id' (which applies predefined styles) or other visual property setters. The description lacks context about prerequisites, such as needing an existing node ID, or when this tool is appropriate compared to other effect-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Apply an effect style' but doesn't clarify if this is a mutation (likely yes), what permissions are needed, whether it's reversible, or how it interacts with other effects. For a tool that modifies nodes, this lack of detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 modifies nodes (implied mutation) with no annotations and no output schema, the description is incomplete. It lacks behavioral details (e.g., error cases, side effects) and doesn't explain what happens upon success, leaving gaps in understanding 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?
The input schema has 100% description coverage, with clear parameter definitions ('nodeId' and 'effectStyleId'). The description adds no additional meaning beyond the schema, such as format examples or relationships between parameters. With high schema coverage, the baseline score of 3 is appropriate as 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 ('Apply') and target ('effect style to a node in Figma'), making the purpose immediately understandable. However, it doesn't differentiate from similar sibling tools like 'set_fill_style_id' or 'set_stroke_style_id' that also apply styles to nodes, missing explicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing valid node and style IDs), exclusions, or comparisons to sibling tools like 'set_effects' (which might handle effect properties directly), 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.
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 mentions alpha defaults and transparency effects, which is helpful, but fails to describe critical behaviors: whether this is a mutation (implied by 'Set'), what permissions are needed, if changes are reversible, error conditions (e.g., invalid nodeId), or response format. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding how the tool 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 extremely concise and front-loaded, stating the core purpose in the first clause. Both sentences earn their place: the first defines the action, and the second provides essential alpha behavior details. There's no wasted verbiage or redundancy, making it efficient for quick 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?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It covers the basic action and alpha behavior but misses critical context: error handling, response format, permissions, and differentiation from sibling tools. For a tool that modifies visual properties, more behavioral transparency 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%, so the schema already fully documents all parameters (nodeId, r, g, b, a). The description adds minimal value beyond the schema by reiterating the alpha default and explaining transparency, but doesn't provide additional semantic context like color format expectations or nodeId sourcing. 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 tool's purpose with a specific verb ('Set') and resource ('fill color of a node in Figma'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'set_fill_style_id' or 'set_fill_variable', which also modify fill properties, leaving some ambiguity about when to choose this specific tool over 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. It mentions alpha defaults and transparency, but doesn't specify prerequisites (e.g., node must exist), exclusions, or compare it to sibling tools like 'set_fill_style_id' for style-based coloring. This lack of contextual usage information could lead to incorrect tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Set' implies a mutation, the description doesn't specify whether this requires specific permissions, if changes are reversible, potential side effects (e.g., affecting text layout), or error conditions. 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 action and target without any wasted words. It directly communicates the tool's purpose in a structured manner, making it easy for an agent to parse and understand 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 fails to address behavioral aspects like error handling, permissions, or what the tool returns (e.g., success confirmation or updated node details). For a tool that modifies resources, more contextual information is needed to guide 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?
The schema description coverage is 100%, with clear descriptions for all three parameters ('nodeId', 'family', 'style'). The description adds no additional parameter semantics beyond what the schema already provides, such as format examples or constraints. However, since the schema does the heavy lifting, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('font name and style of a text node in Figma'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'set_font_size' or 'set_font_weight' by focusing specifically on font family and style. However, it doesn't explicitly contrast with all similar tools (e.g., 'set_text_style_id'), 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_text_style_id' or 'set_font_weight', nor does it mention prerequisites such as needing a valid text node ID. It lacks context about when this tool is appropriate compared to other font-related tools in the sibling list, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool modifies a text node, implying a mutation, but doesn't clarify permissions needed, whether changes are reversible, error conditions (e.g., invalid nodeId), or side effects. For a mutation tool with zero annotation coverage, this lack of behavioral detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 and target without unnecessary words. It avoids redundancy with the tool name or schema, making it highly concise and well-structured for quick 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?
Given the tool's mutation nature, lack of annotations, and absence of an output schema, the description is incomplete. It doesn't address behavioral aspects like error handling, response format, or integration with sibling tools (e.g., 'get_node_info' for nodeId retrieval). For a tool that modifies resources in a design platform, more context 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 descriptions for both parameters (nodeId and fontSize). The description adds no additional semantic context beyond what the schema provides, such as examples or constraints (e.g., typical font size ranges in Figma). 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 the target ('font size of a text node in Figma'), making the purpose immediately understandable. It distinguishes from siblings like 'set_font_name' or 'set_font_weight' by focusing specifically on size. However, it doesn't explicitly mention the platform context (Figma) as a differentiator from potential non-Figma tools, which keeps it from a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a text node ID), exclusions (e.g., not applicable to non-text nodes), or comparisons to siblings like 'set_text_style_id' that might affect font size indirectly. Without such context, the agent must infer usage solely from the tool name and parameters.
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 action ('Set') but does not describe behavioral traits such as whether this operation requires specific permissions, if changes are reversible, potential side effects (e.g., affecting text layout), or error conditions. 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 is appropriately sized and front-loaded, making it easy to understand quickly with zero waste.
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 information on behavioral aspects (e.g., permissions, reversibility), usage context, and what the tool returns or how errors are handled. The high schema coverage helps with parameters, but overall completeness is inadequate for a tool that modifies resources.
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 both parameters ('nodeId' and 'weight'), including allowed values for 'weight'. The description does not add any meaningful semantics beyond what the schema provides, such as explaining parameter interactions 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 verb ('Set') and resource ('font weight of a text node in Figma'), making the purpose specific and understandable. However, it does not explicitly distinguish this tool from similar siblings like 'set_font_name' or 'set_font_size', which also modify text node properties in Figma, so it lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a valid text node ID), exclusions (e.g., not applicable to non-text nodes), or comparisons to other font-related tools in the sibling list, 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.
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 modification operation ('Set'), implying mutation, but doesn't address permission requirements, whether changes are reversible, error conditions, or what happens if the node isn't a text node. 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 directly states the tool's purpose without unnecessary words. It's appropriately sized for a straightforward tool 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 the tool returns (e.g., success confirmation, error details), behavioral constraints, or integration with sibling tools. Given the complexity of modifying Figma nodes and the rich sibling toolset, more context is needed 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%, with clear descriptions for all three parameters (nodeId, letterSpacing, unit). The description adds no additional parameter semantics beyond what the schema already provides, such as explaining what letter spacing values are typical or how units affect rendering. 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 ('letter spacing of a text node in Figma'), making the purpose immediately understandable. However, it doesn't distinguish this tool from similar sibling tools like set_font_size or set_line_height, which follow the same pattern for different text 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., needing a text node ID), exclusions, or relationships to other text formatting tools in the sibling list, 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 the full burden of behavioral disclosure. It states a mutation action ('Set') but doesn't mention permissions, side effects, error conditions, or response format. This is inadequate for a mutation tool without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized and front-loaded, directly stating the tool's purpose 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?
For a mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens on success/failure, return values, or error handling, leaving significant gaps in understanding the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters (nodeId, lineHeight, unit). The description adds no additional meaning beyond implying these parameters exist, 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 ('Set') and target ('line height of a text node in Figma'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like set_font_size or set_paragraph_spacing, which share similar patterns for text node modifications.
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 lacks context about prerequisites (e.g., needing a valid text node ID) or exclusions (e.g., not applicable to non-text nodes), leaving usage entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but lacks behavioral details. 'Set' implies mutation, but it doesn't disclose permissions needed, whether changes are reversible, error handling, or performance implications of 'parallelly'. The agent must infer behavior from the tool name and parameters alone.
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. Every word contributes to understanding the tool's function 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?
For a mutation tool with no annotations and no output schema, the description is insufficient. It lacks details on return values, error conditions, side effects, and how 'parallelly' affects execution—critical gaps given the tool's complexity and potential impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are well-documented in the schema. The description adds minimal value beyond implying batch processing via 'multiple' and 'parallelly', but doesn't clarify parameter interactions or usage nuances beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set multiple text contents') and target ('in a node'), with the adverb 'parallelly' suggesting concurrent execution. It distinguishes from the sibling tool 'set_text_content' by specifying multiple vs. single text operations, though it doesn't explicitly name the sibling for comparison.
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_text_content' (for single updates) or other text-modifying siblings. The description implies batch operations but doesn't specify prerequisites, constraints, or optimal use cases.
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 modifies a text node, implying a mutation, but does not address critical aspects like whether changes are reversible, permission requirements, error handling, or side effects. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that efficiently conveys the core purpose without unnecessary words. It is front-loaded with the key action and target, making it easy to parse 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 lack of annotations and output schema, the description is incomplete for a mutation tool. It fails to explain what the tool returns, error conditions, or behavioral nuances, leaving the agent with insufficient context to use it effectively beyond basic parameter input.
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, clearly documenting both parameters ('nodeId' and 'paragraphSpacing'). The description adds no additional semantic details beyond what the schema provides, such as units clarification or valid ranges, so it meets the baseline for high schema coverage without 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 ('Set') and the target ('paragraph spacing of a text node in Figma'), making the purpose immediately understandable. However, it does not explicitly differentiate from sibling tools like 'set_line_height' or 'set_letter_spacing', which also modify text node properties, leaving some 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, such as other text formatting tools in the sibling list. It lacks context about prerequisites, like needing a valid text node ID, or exclusions, such as not applying to non-text nodes, which could lead to misuse.
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 it modifies a text node without disclosing behavioral traits. It doesn't mention whether this is a destructive operation, requires specific permissions, has rate limits, or what happens on success/failure. 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 with zero wasted words. It's appropriately sized and front-loaded with the core purpose, 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, error conditions, or behavioral implications. Given the complexity of modifying Figma nodes, more context about permissions, side effects, or success indicators would be valuable.
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 thoroughly. The description adds no additional meaning about parameters beyond what's in the schema (e.g., format of nodeId, interpretation of textCase 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 action ('Set the text case') and target resource ('a text node in Figma'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'set_text_content' or 'set_text_style_id' that also modify text nodes, 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. It doesn't mention prerequisites (e.g., needing a valid text node ID), exclusions, or comparisons to similar tools like 'set_text_content' for broader text modifications.
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 modifies an existing text node, implying mutation, but doesn't disclose behavioral traits like whether it requires specific permissions, if changes are reversible, rate limits, or what happens on failure (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, efficient sentence that front-loads the core purpose without unnecessary words. Every element ('Set', 'text content', 'existing text node', 'Figma') earns its place, making it easy to parse quickly. No fluff or redundancy is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It lacks context on permissions, error handling, return values, or side effects. While the schema covers parameters well, the overall tool behavior is underspecified for safe and effective use by 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?
Schema description coverage is 100%, with both parameters ('nodeId', 'text') clearly documented in the schema. The description adds no additional meaning beyond what the schema provides (e.g., no examples, format details, or constraints). 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 ('Set') and target resource ('text content of an existing text node in Figma'), making the purpose immediately understandable. It distinguishes from sibling tools like 'create_text' (which creates new text) and 'set_multiple_text_contents' (which modifies multiple nodes). However, it doesn't explicitly mention what distinguishes it from other text-related tools like 'set_text_case' or 'set_text_decoration'.
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 text node), exclusions (e.g., not for non-text nodes), or comparisons to siblings like 'set_multiple_text_contents' for bulk operations. The agent must infer usage from the tool name and 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 this is a modification tool ('Set'), implying mutation, but doesn't cover important aspects like whether changes are destructive, permission requirements, error conditions, or what happens if applied to non-text nodes. 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 unnecessary words. It's appropriately front-loaded with the core action and target, 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 insufficient. It doesn't explain what the tool returns, error conditions, side effects, or how it interacts with other text properties. Given the complexity of modifying design elements, more context about behavior and outcomes 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%, with both parameters clearly documented in the schema. The description doesn't add any meaningful parameter semantics beyond what's already in the schema (nodeId identifies the target, textDecoration specifies the type). 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 ('Set') and target ('text decoration of a text node in Figma'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'set_text_case' or 'set_text_style_id' that also modify text properties, 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. It doesn't mention prerequisites (e.g., needing a valid text node ID), exclusions, or comparisons to similar tools like 'set_text_style_id' that might handle decorations differently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but doesn't explain what 'ungroup' entails (e.g., whether children become independent, if properties are preserved, or if it requires specific permissions). For a mutation tool, this leaves significant gaps in understanding its effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and context, 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 behavior (e.g., what happens to children), error conditions, or return values, leaving the agent with insufficient context for reliable use.
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 description doesn't mention parameters, but with 100% schema description coverage and only one parameter (nodeId), the schema fully documents it. The baseline is 3 for high coverage, but with zero parameters in the description and a single well-documented parameter, a 4 is appropriate as the description doesn't need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Ungroup nodes in Figma' clearly states the action (ungroup) and resource (nodes in Figma), but it's vague about scope and doesn't differentiate from siblings like 'flatten_node' or 'delete_node' which also modify node structures. It avoids tautology by specifying the domain (Figma) beyond just 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?
No guidance is provided on when to use this tool versus alternatives like 'flatten_node' or 'delete_node', nor does it mention prerequisites such as requiring a group/frame node. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Export' which implies a read operation that generates output, but doesn't disclose behavioral traits like whether it requires specific permissions, what happens on failure, if it's rate-limited, or the nature of the output (e.g., file format details beyond the schema's enum). For a tool with no annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action ('Export a node as an image from Figma'). There is zero waste, and it's 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.
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, no annotations), the description is minimally adequate. It states the purpose clearly but lacks behavioral context and usage guidelines. With no output schema, it doesn't explain return values (e.g., image data or file reference), which is a gap for an export tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (nodeId, format, scale) with descriptions and constraints. The description adds no additional meaning beyond the schema's details, such as explaining what a 'node' represents in Figma or providing context for scale 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 ('Export') and resource ('a node as an image from Figma'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling export tools (none are listed in the provided siblings, but in a broader Figma context, there might be other export functions).
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 other tools. The sibling list includes many Figma manipulation tools, but no explicit export alternatives are named.
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 mentions what the tool shows ('bound to fills, strokes, and other properties'), but doesn't cover critical aspects like whether it's a read-only operation, error handling for invalid node IDs, or the format of returned data. For a 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 concise and well-structured, consisting of two sentences that efficiently convey the tool's purpose and scope without unnecessary details. Every sentence adds value, making it front-loaded and easy to understand.
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 complexity (simple read operation with one parameter), no annotations, and no output schema, the description is moderately complete. It explains what the tool does but lacks details on behavioral traits and output format. This is adequate for a basic tool but leaves gaps that could hinder effective use by 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 input schema has 100% description coverage, with 'nodeId' clearly documented as 'The ID of the node to inspect'. The description adds no additional parameter semantics beyond this, such as examples or constraints. According to the rules, when schema coverage is high (>80%), the baseline score is 3, which is appropriate 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 all variable bindings for a node' with specific details about what it shows ('which variables are bound to fills, strokes, and other properties'). It uses a specific verb ('Get') and resource ('variable bindings'), but doesn't explicitly distinguish it from siblings like 'resolve_variable_by_name' or 'clear_variable_binding', which prevents a score of 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
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 sibling tools like 'resolve_variable_by_name' for specific variable resolution. This lack of contextual usage information results in a low score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action but does not cover critical aspects like whether this is a read-only operation, potential rate limits, authentication needs, or the format of returned data. This leaves significant gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words, making it highly concise and front-loaded. Every part of the sentence contributes directly to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It does not explain what 'local components' entail, the return format, or any behavioral traits, leaving the agent with insufficient information to use the tool effectively in a complex environment.
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?
With 0 parameters and 100% schema description coverage, the baseline is 4. The description does not need to add parameter details, and it appropriately avoids redundancy, though it could hint at implicit context like document scope.
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 does not explicitly differentiate from its sibling 'get_remote_components', which is a notable omission given the 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?
No guidance is provided on when to use this tool versus alternatives, such as 'get_remote_components' or 'get_node_info' for component details. The description lacks context about prerequisites or typical use cases, offering minimal 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 what the tool does without disclosing behavioral traits. It doesn't mention whether this is a read-only operation, what format the information returns, if it requires specific permissions, or any limitations (e.g., only works when something is selected). This leaves significant gaps in understanding how the tool 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, clear sentence that efficiently conveys the core purpose without unnecessary words. It's front-loaded with the essential information and has zero wasted content, 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 lack of annotations and output schema, the description is incomplete for a tool that retrieves information. It doesn't specify what 'information' includes (e.g., node details, selection bounds, types), the return format, or any error conditions (e.g., no selection). For a read operation with no structured output documentation, this leaves the agent poorly equipped to use the tool 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 with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any parameters, earning a baseline score of 4 for not introducing confusion.
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 differentiate from sibling tools like 'get_node_info' or 'get_nodes_info' that also retrieve information about Figma elements, leaving some ambiguity about when this specific tool is preferred.
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_nodes_info'. It lacks context about prerequisites (e.g., needing an active selection) or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool 'analyzes' text nodes for styling, implying a read-only operation, but doesn't specify if it requires permissions, how it handles errors (e.g., invalid node IDs), or what the output format looks like (e.g., list of segments with style details). 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 front-loads the core purpose ('Get text segments with specific styling in a text node'). It uses no unnecessary words and directly communicates the tool's function without redundancy or fluff, making it easy to parse quickly.
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 (2 parameters, no output schema, no annotations), the description is adequate but incomplete. It covers the basic purpose but lacks details on behavioral aspects (e.g., error handling, output format) and usage guidelines. Without annotations or an output schema, the description should compensate more to ensure the agent can invoke it correctly, but it falls short of being fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for both parameters ('nodeId' and 'property'), including an enum for 'property'. The description adds minimal value beyond the schema, mentioning 'specific styling' which aligns with the 'property' parameter but doesn't provide additional context like examples of style properties or how segments are defined. 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 ('Get text segments') and the target ('in a text node'), specifying the filtering criterion ('with specific styling'). It distinguishes from siblings like 'get_node_info' or 'scan_text_nodes' by focusing on style analysis within text nodes. However, it doesn't explicitly contrast with all siblings, such as 'get_styles' which might retrieve style definitions rather than applied styles in text segments.
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 'get_styles' (for style definitions) or 'scan_text_nodes' (for broader text analysis). Usage is implied by the description but not explicitly defined.
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 defaults for opacity and weight, which adds some behavioral context, but doesn't disclose critical traits like whether this is a destructive mutation, permission requirements, error conditions, or what happens to existing stroke settings. 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 front-loads the core purpose and includes useful default information. There's no wasted verbiage, and every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with 6 parameters) and lack of annotations or output schema, the description is moderately complete. It covers the purpose and hints at defaults, but gaps remain in behavioral transparency and usage guidelines. It's adequate for basic understanding but could be more comprehensive 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%, so the schema fully documents all parameters (nodeId, r, g, b, a, strokeWeight). The description adds minimal value by implying defaults for 'a' (opacity) and 'strokeWeight', but doesn't explain parameter interactions or semantics beyond what the schema provides. 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 ('Set the stroke color') and target resource ('a node in Figma'), which is specific and unambiguous. However, it doesn't differentiate this tool from sibling tools like 'set_stroke_style_id' or 'set_stroke_variable', which appear to handle similar stroke-related modifications, so it doesn't fully distinguish from 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. It mentions defaults for opacity and weight, but doesn't explain when to choose this over other stroke-related tools (e.g., 'set_stroke_style_id' or 'set_stroke_variable') or prerequisites like node selection. This leaves the agent without clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It doesn't disclose whether this is a read-only operation, potential rate limits, authentication needs, error conditions, or what 'detailed information' entails. The description is functional but lacks critical 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 that front-loads the core purpose without unnecessary words. Every part earns its place by specifying the action, target, and context ('in Figma'), making it highly scannable and zero-waste.
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 complex node data. It doesn't hint at the structure or content of the returned information, error handling, or limitations, leaving significant gaps for an AI agent to operate 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%, with the parameter 'nodeIds' clearly documented in the schema as an array of node IDs. The description adds no additional parameter semantics beyond what the schema provides, such as format examples, ID sourcing, or constraints, 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 ('Get detailed information') and target resource ('multiple nodes in Figma'), making the purpose immediately understandable. It distinguishes from the sibling 'get_node_info' by specifying 'multiple nodes' versus presumably a single node, though it doesn't explicitly name the sibling for comparison.
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 detailed information about multiple nodes, but provides no explicit guidance on when to choose this over 'get_node_info' (e.g., batch efficiency vs. single-node specificity) or other sibling tools. It lacks context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves components but lacks details on permissions required, rate limits, pagination, error handling, or return format (e.g., list, structured data). For a read operation 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 fluff. It is front-loaded and wastes no words, making it easy to parse quickly. Every part of the sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks behavioral context (e.g., what 'get' returns, any side effects). For a tool with no annotations, it should provide more operational details to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds no parameter details, avoiding redundancy. A baseline score of 4 is applied as it correctly omits unnecessary information, though it doesn't enhance semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('available components from team libraries in Figma'), making the purpose immediately understandable. It distinguishes from sibling tools like 'get_local_components' by specifying 'remote' (team libraries). However, it could be more specific about what 'available components' entails (e.g., metadata, full definitions).
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., authentication, active team context), compare with 'get_local_components', or specify scenarios where remote components are needed (e.g., for reuse across projects). 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 'Get all styles' but doesn't explain what 'styles' includes (e.g., text, color, effect styles), whether this is a read-only operation, potential rate limits, or the return format. 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 with no wasted words. It front-loads the core purpose ('Get all styles') and specifies the context ('from the current Figma document'), making it easy to parse quickly.
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 output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on behavior, output, or usage context. For a read operation in a design tool environment, more context on what 'styles' entails would improve 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 appropriately doesn't discuss parameters, focusing on the tool's purpose instead. A baseline of 4 is applied for zero-parameter tools when schema coverage is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get all styles') and resource ('from the current Figma document'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'get_node_info' or 'get_local_components' that also retrieve document data, so it doesn't fully distinguish its unique 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 prerequisites (e.g., needing an open document), exclusions, or compare it to sibling tools like 'get_remote_components' or 'get_local_components' that might retrieve similar resources.
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 describes the tool as a lookup operation ('Find'), which implies it's read-only and non-destructive, but doesn't explicitly state this. It also doesn't cover potential behaviors like error handling (e.g., if the variable doesn't exist), return format, or any rate limits. For a 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 appropriately sized and front-loaded: two sentences that directly state the purpose and usage context without unnecessary details. Every sentence earns its place by providing essential information, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (a simple lookup with 2 parameters) and no output schema, the description is moderately complete. It covers the basic purpose and usage but lacks details on behavioral aspects (e.g., what happens if the variable isn't found) and doesn't explain return values. With no annotations and no output schema, it should do more to compensate, but it's adequate for a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear descriptions for both parameters ('name' and 'collectionName'). The description adds minimal value beyond the schema: it provides examples ('e.g., 'base-100', 'primary') which are already in the schema, and mentions 'semantic name' but doesn't clarify what that means. With high schema coverage, the baseline is 3, and the description doesn't significantly 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 tool's purpose: 'Find a variable ID by its name.' It specifies the verb ('Find') and resource ('variable ID'), and distinguishes it from siblings like 'get_bound_variables' by focusing on lookup by name rather than listing bound variables. However, it doesn't explicitly differentiate from other variable-related tools (none in the sibling list), so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance: 'Useful for binding variables when you know the semantic name.' This suggests a context (binding variables) but doesn't explicitly state when to use this tool versus alternatives like 'get_bound_variables' or other variable-handling methods. No exclusions or clear alternatives are mentioned, making it adequate but not comprehensive.
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 tool 'binds' a variable, implying a dynamic link rather than a static change, but doesn't disclose behavioral traits like whether this overrides existing bindings, requires specific permissions, affects other properties, or has side effects. 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 that front-loads the core action ('Bind a color variable to a node's stroke') and adds context ('Use this for theme-compatible border colors') without any wasted words. Every part earns its place, making it easy to scan and understand quickly.
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 (binding variables to strokes), no annotations, and no output schema, the description is adequate but incomplete. It covers the purpose and hints at usage but lacks details on behavior, error conditions, or return values. For a mutation tool in a design context, more information on effects and constraints would be beneficial.
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 all parameters (nodeId, variableId, strokeIndex). The description adds minimal value beyond the schema, only implying that 'stroke' relates to 'border colors' and 'theme-compatible' suggests variableId refers to a color variable. This meets the baseline of 3 since the schema does the heavy lifting, but doesn't provide additional syntax or format details.
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 ('Bind a color variable') and target ('to a node's stroke'), with the specific purpose of enabling 'theme-compatible border colors.' It distinguishes from sibling tools like 'set_stroke_color' (which sets a fixed color) and 'set_fill_variable' (which binds to fill instead of stroke). However, it doesn't explicitly contrast with all siblings, such as 'set_stroke_style_id'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for theme-compatible border colors, suggesting it should be used when dynamic color variables are needed rather than fixed colors. However, it doesn't explicitly state when to use this tool versus alternatives like 'set_stroke_color' or 'set_stroke_style_id,' nor does it mention prerequisites (e.g., requiring existing variables or nodes). The context is clear but lacks explicit exclusions or comparisons.
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. The description states 'Apply a stroke style to a node,' which implies a mutation operation, but it doesn't disclose any behavioral traits such as permission requirements, whether the change is reversible, error conditions, or what happens if the node doesn't support strokes. 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 extremely concise with two sentences that are front-loaded and waste no words. The first sentence states the core purpose, and the second provides essential usage guidance. Every sentence earns its place, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't cover behavioral aspects like error handling, permissions, or what the tool returns (e.g., success/failure, updated node info). The mention of 'get_styles' helps, but for a tool that modifies data, more context is needed to ensure safe and correct usage by 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?
Schema description coverage is 100%, with both parameters ('nodeId' and 'strokeStyleId') clearly documented in the schema. The description adds minimal value beyond the schema by implying that strokeStyleId values come from 'get_styles,' but doesn't provide additional syntax, format details, or constraints. This meets the baseline of 3 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 ('Apply') and resource ('stroke style to a node'), making the purpose immediately understandable. It distinguishes this tool from other styling tools like 'set_stroke_color' or 'set_effect_style_id' by specifying it's for stroke styles specifically. However, it doesn't explicitly differentiate from 'set_stroke_variable' which might be a related alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by mentioning 'Use get_styles to find available stroke style IDs,' which indicates a prerequisite workflow. This helps the agent understand when to use this tool (after obtaining style IDs via get_styles). However, it doesn't explicitly state when NOT to use it or name specific alternatives among siblings like 'set_stroke_color' or 'set_stroke_variable'.
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 mentions the action ('Remove') and outcome ('reverting to static value'), but doesn't specify permissions required, whether the operation is reversible, error conditions, or what happens if no binding exists. For a mutation 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.
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. Every word earns its place with no redundancy or 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?
For a mutation tool with no annotations and no output schema, the description adequately covers the basic purpose but lacks details on behavioral aspects like error handling or side effects. Given the 2-parameter input with full schema coverage, it's minimally viable but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both parameters clearly documented in the schema. The description doesn't add any additional meaning about nodeId or field beyond what the schema provides, so it meets the baseline of 3 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.
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 ('Remove a variable binding'), target resource ('from a node property'), and outcome ('reverting to the static value'). It distinguishes itself from siblings like set_fill_variable or set_stroke_variable by focusing on removal rather than assignment.
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 a variable binding needs to be cleared from a node property, but doesn't explicitly state when to use this tool versus alternatives like directly setting static values with other sibling tools (e.g., set_fill_color). No explicit exclusions or prerequisites are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It implies a mutation ('Apply') but doesn't specify permissions needed, whether changes are reversible, or error conditions. It adds some context about style ID sourcing but lacks comprehensive behavioral 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 perfectly concise with two sentences that each serve distinct purposes: stating the tool's function and providing usage guidance. There's zero wasted language, and information is front-loaded appropriately.
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 provides adequate basic information about what the tool does and how to prepare inputs. However, it lacks details about behavioral implications, error handling, or response format, leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters fully. The description doesn't add syntax or format details beyond what the schema provides, but references get_styles for fillStyleId context, offering marginal value. 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.
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 ('Apply a fill style') and target resource ('to a node in Figma'), distinguishing it from siblings like set_fill_color or set_fill_variable. It precisely identifies the tool's function without being tautological.
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 explicitly provides when-to-use guidance by directing users to 'Use get_styles to find available fill style IDs,' naming an alternative tool for prerequisite information. This creates clear context for proper tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the tool 'binds' a variable, implying a mutation that links a color variable to a node's fill, which is useful context. However, it lacks details on permissions, error conditions, or what happens if the variable or node doesn't exist, leaving gaps in behavioral transparency 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 two sentences with zero waste: the first states the purpose, and the second provides usage guidelines. It is front-loaded with the core action and efficiently conveys essential information without unnecessary details, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with 3 parameters) and no annotations or output schema, the description is moderately complete. It covers purpose and usage well but lacks behavioral details like error handling or response format. For a mutation tool without annotations, this leaves some gaps, but it's adequate for basic 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?
Schema description coverage is 100%, so the schema already documents all parameters (nodeId, variableId, fillIndex) with clear descriptions. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints, so it meets the baseline score 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 ('Bind a color variable to a node's fill') and the resource involved ('node's fill'). It distinguishes this tool from sibling tools like 'set_fill_color' (which likely uses hardcoded colors) by explicitly mentioning 'theme-compatible colors instead of hardcoded RGB values,' providing clear differentiation.
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 explicitly states when to use this tool ('Use this for theme-compatible colors instead of hardcoded RGB values'), providing clear guidance on its intended context. It implies an alternative ('hardcoded RGB values'), which likely refers to sibling tools like 'set_fill_color,' making the usage distinction clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a mutation ('Apply a text style to a text node'), suggesting it modifies existing data, but does not disclose behavioral traits like permission requirements, error conditions, or what happens if the style ID is invalid. 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 appropriately sized with two sentences that are front-loaded and waste-free. The first sentence states the core purpose, and the second provides essential usage guidance, with every sentence earning its place without redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (a mutation with 2 parameters), no annotations, and no output schema, the description is reasonably complete. It covers the purpose and usage guidelines but lacks details on behavioral aspects like error handling or return values, which would be beneficial for full 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 both parameters (nodeId and textStyleId) with clear descriptions. The description does not add any additional meaning or syntax details beyond what the schema provides, such as format examples or constraints, 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.
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 ('Apply a text style') and target resource ('to a text node in Figma'), distinguishing it from sibling tools like set_font_size or set_text_content that modify different text properties. It precisely identifies what the tool does without being vague or tautological.
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 explicitly provides when-to-use guidance by stating 'Use get_styles to find available text style IDs,' which names a specific alternative tool for prerequisite information. This helps the agent understand the workflow and when to invoke other tools, offering clear context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![cc-fig-mcp MCP server](https://glama.ai/mcp/servers/agenisea/cc-fig-mcp/badges/card.svg)](https://glama.ai/mcp/servers/agenisea/cc-fig-mcp)

Score Badge

Copy to your README.md:

[![cc-fig-mcp MCP server](https://glama.ai/mcp/servers/agenisea/cc-fig-mcp/badges/score.svg)](https://glama.ai/mcp/servers/agenisea/cc-fig-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/agenisea/cc-fig-mcp'

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