Conduit

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
Tools are generally distinct by resource and action (e.g., create_rectangle vs. resize_node), but there is significant overlap in style-setting tools (e.g., set_effect, set_gradient, apply_effect_style) and redundant getters (e.g., get_node_info, get_node_style, get_fill_and_stroke). This overlap could confuse agents about which tool to use for specific styling or info retrieval tasks.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (e.g., create_rectangle, delete_node, get_document_info), with clear action prefixes. However, there are minor deviations like 'boolean' (noun instead of verb_noun) and 'join' (single verb without noun), slightly disrupting the pattern.
Tool Count2/5
With 72 tools, this server is extremely large for a Figma automation domain. While Figma has many features, this count feels excessive and overwhelming, likely leading to confusion and inefficiency for agents. A more focused set of 20-30 tools would be more manageable and appropriate.
Completeness5/5
The toolset comprehensively covers Figma operations, including creation (e.g., create_frame, create_component_instance), modification (e.g., resize_node, set_text_style), retrieval (e.g., get_node_info, get_svg_vector), deletion (e.g., delete_node), and advanced features like variables and events. There are no obvious gaps for core Figma workflows.
Average 3.5/5 across 72 of 72 tools scored. Lowest: 1/5.
See the Tool Scores section below for per-tool breakdowns.
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Tool has no description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has no description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has no description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tool has no description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Tool has no description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions that the tool can add or delete guides and returns an array of result objects, but it lacks details on permissions, error handling, side effects (e.g., if deletions are permanent), or rate limits. For a mutation tool with zero annotation coverage, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with two sentences that directly state the action and return value. There is no wasted language, but it could benefit from slightly more detail to improve completeness without sacrificing brevity.
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 (mutation with nested parameters, no output schema, and 0% schema coverage), the description is incomplete. It does not cover parameter meanings, behavioral nuances, or usage context, leaving significant gaps for the agent to operate effectively in a Figma environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It does not explain the parameters 'guide' or 'guides', their structure (e.g., 'axis', 'offset', 'delete'), or how they interact (e.g., using 'guides' array for multiple operations). Without this, the agent cannot understand how to invoke the tool correctly beyond the raw 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 tool's purpose: 'Add or delete one or more guides on the current Figma page.' It specifies the verb ('Add or delete'), resource ('guides'), and scope ('on the current Figma page'), making the action explicit. However, it does not differentiate from sibling tools like 'get_guide' or 'set_grid', which slightly limits its clarity.
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 an open page), exclusions, or comparisons to sibling tools like 'get_guide' (for reading guides) or 'set_grid' (for grid settings). This lack of context leaves the agent without clear 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. It states the tool subscribes or unsubscribes to events and describes return values, but lacks critical details: it doesn't specify permissions required, rate limits, whether subscriptions persist, how events are delivered (e.g., webhooks), or error handling. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with two sentences that directly state the purpose and return values. There's no wasted text, and it efficiently covers the core functionality. However, it could be slightly more structured by separating subscription and unsubscribe details, but overall, it's appropriately sized for its 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?
Given the tool's complexity (managing event subscriptions with 4 parameters), no annotations, and no output schema, the description is incomplete. It lacks details on behavioral aspects like how subscriptions work, error cases, or integration with other tools. While it mentions return values, it doesn't provide a full context for effective use, making it inadequate for a mutation tool in this environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'eventType' with examples but doesn't explain 'filter', 'subscribe', or 'subscriptionId' parameters. The description adds minimal value beyond what's implied by the tool name, failing to clarify parameter roles or usage, which is insufficient given the low 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: 'Subscribe or unsubscribe to a Figma event (e.g., selection_change, document_change).' It specifies the verb (subscribe/unsubscribe) and resource (Figma event) with examples, making the intent unambiguous. However, it doesn't differentiate from sibling tools, which are mostly about creating, modifying, or fetching design elements rather than event management, so a distinction isn't critical here.
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 event types like 'selection_change' and 'document_change' but doesn't explain their contexts, prerequisites, or when to choose subscription over other methods. There's no mention of sibling tools or any usage constraints, leaving the agent to infer appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions that the tool can 'create, update, or delete' and returns an array of results, but lacks critical details like required permissions, whether operations are atomic, error handling, or rate limits. For a mutation tool with complex nested parameters, 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 extremely concise with two sentences: one stating the purpose and scope, and another specifying the return type. Every word earns its place, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters (one being a complex nested array), 0% schema description coverage, no output schema, and no annotations, the description is insufficient. It lacks details on parameter meanings, behavioral constraints, error cases, and output structure, leaving significant gaps for an AI agent to operate safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'entries' and 'one or more layout grids' but provides no explanation of what 'entries', 'nodeId', 'gridIndex', 'properties', or their sub-properties mean. The description adds minimal value beyond the schema's structure.
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 ('Create, update, or delete') and resource ('layout grids on Figma nodes'), with specific node types listed (FRAME, COMPONENT, INSTANCE). It doesn't explicitly differentiate from sibling tools like 'set_auto_layout' or 'set_guide', but the focus on 'layout grids' is sufficiently specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'set_auto_layout' or 'set_guide', nor are prerequisites or exclusions mentioned. The description only states what the tool does, not when it should be selected.
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. While it states the action is deletion (implying destructive mutation), it doesn't disclose critical behavioral traits: whether deletion is permanent/reversible, permission requirements, rate limits, or error conditions. The return format is described but lacks context about what happens on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences: one stating the purpose and one describing the return format. It's front-loaded with the core action. The return format explanation could be slightly more efficient but doesn't significantly detract from clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive mutation tool with no annotations and no output schema, the description is incomplete. It covers the basic action and return format but misses critical context: safety warnings, prerequisites, error handling, and how it differs from similar node manipulation tools. The return description helps but doesn't compensate for the missing behavioral transparency.
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 parameter semantics beyond what the schema provides (nodeId and nodeIds parameters with their formats and 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 action ('Deletes') and resource ('one or more nodes in Figma'), providing specific verb+resource information. However, it doesn't explicitly differentiate from sibling tools like 'flatten_node' or 'detach_instances' which might also involve node manipulation, missing full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 that manipulate nodes (e.g., 'move_node', 'duplicate_node', 'flatten_node'), there's no indication of when deletion is appropriate versus other operations, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the return type (array of constraint info) but lacks details on permissions needed, error handling, rate limits, or whether it's a safe read operation. The description doesn't contradict annotations (none exist), but it's insufficient for a mutation-free 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. The second sentence adds return value info efficiently. No wasted words, though it could be slightly more structured (e.g., bullet points for parameters).
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 read-only tool with full schema coverage but no output schema, the description covers basic purpose and return format. However, it lacks behavioral context (e.g., safety, errors) and usage guidance relative to siblings, making it minimally adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already fully documents all three parameters. The description adds no parameter-specific details beyond what's in the schema (e.g., no clarification on mutual exclusivity of nodeId vs nodeIds). 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 ('Get constraints') and resource ('Figma nodes'), specifying optional inclusion of children. It distinguishes from siblings like 'set_constraint' (write vs read) but doesn't explicitly differentiate from other read tools like 'get_node_info' or 'get_annotation'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_node_info' (which might include constraint data) or 'get_annotation' (which might overlap). The description mentions optional child inclusion but doesn't provide context for choosing between single vs batch node IDs or when to include children.
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 the return format but doesn't cover critical aspects like whether this is a read-only operation, error handling, rate limits, or authentication needs. For a tool that queries data, this lack of behavioral context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured in two sentences: one stating the purpose and another detailing the return format. It avoids redundancy and is front-loaded with the core functionality. A slight improvement could be adding usage context, but it's efficient as is.
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 (querying variants/properties), lack of annotations, and no output schema, the description is partially complete. It covers the purpose and return format but misses behavioral traits and usage guidelines. For a read operation, this is adequate but leaves gaps that could hinder effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents both parameters ('componentSetId' and 'componentSetIds') with clear descriptions. The description adds value by explaining the return format differences for single vs. batch queries, which helps interpret the parameters' effects. However, it doesn't provide additional semantic details beyond what the schema offers.
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 info about variants/properties for one or more component sets.' It specifies the verb ('Get info') and resource ('variants/properties for component sets'), making it easy to understand. However, it doesn't explicitly differentiate from sibling tools like 'get_components' or 'get_node_info', which might also retrieve component-related data.
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 whether component sets must exist, or compare it to sibling tools like 'get_components' or 'set_variant'. The agent must infer usage from the purpose alone, which is insufficient for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but lacks behavioral details. It states the tool is asynchronous and returns a message, but doesn't disclose error handling, performance implications, whether it affects existing text nodes, or authentication/rate limits. This is inadequate for a mutation tool in a design environment.
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 efficiently structured with a clear purpose statement followed by return format details. However, the example could be integrated more smoothly, and there's room to combine sentences without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters, 100% schema coverage, and no output schema, the description provides basic purpose and return format. However, as a mutation tool in Figma with no annotations, it should explain more about side effects, error cases, and integration with other font-related operations to be fully 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%, providing clear documentation for both parameters. The description adds no parameter-specific information beyond what's in the schema, so it meets the baseline score of 3 without adding extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Load a font asynchronously') and target resource ('in Figma'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'set_text_style' or 'set_text_content' that might also involve fonts, 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., whether a document must be open), compare to synchronous loading methods, or explain why asynchronous loading is beneficial in Figma's 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 the full burden of behavioral disclosure. It implies a mutation operation ('Sets') but does not specify whether this requires specific permissions, if changes are reversible, what happens to existing styles not mentioned, or any rate limits. This leaves significant gaps in understanding the tool's behavior and risks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the key action and resources without any wasted words. It is appropriately sized for the tool's complexity, 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.
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 (7 parameters, mutation operation) and lack of annotations and output schema, the description is insufficient. It does not explain return values, error conditions, or behavioral nuances, leaving the agent with incomplete information to invoke the tool safely and 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?
The input schema has 100% description coverage, clearly documenting all 7 parameters, including their purposes and constraints (e.g., 'Provide either nodeId or nodeIds, not both'). The description adds minimal value by summarizing the parameters but does not provide additional syntax, format details, or examples beyond what the schema already covers.
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 ('Sets') and the resources ('fill and/or stroke color(s) and/or stroke weight for one or more nodes'), making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'set_gradient' or 'set_effect', which might handle similar styling aspects, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'set_gradient' for gradient fills or 'set_effect' for effects. It lacks context on prerequisites, like whether nodes must be selected or exist, and does not mention any exclusions or best practices 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 for behavioral disclosure. It mentions the tool performs various mutation operations but doesn't specify permissions needed, whether operations are destructive, error handling, or rate limits. The return format is briefly mentioned but lacks detail on what 'result objects' contain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that efficiently cover the tool's capabilities and return value. It's front-loaded with the core functionality. However, the first sentence is somewhat dense with multiple action verbs, which slightly affects readability.
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 (multiple mutation operations, batch capability) and absence of both annotations and output schema, the description is moderately complete. It covers what the tool does and the return type but lacks details about behavioral aspects, error conditions, and specific usage scenarios that would be needed for full 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 all parameters thoroughly. The description adds minimal value beyond the schema by listing the action types and mentioning batch operations, but doesn't provide additional context about parameter usage or relationships between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('create, add, rename, delete, organize, or batch create') and resources ('variants/properties in a component set'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_variant' or 'set_variable', which would be needed for a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, when to choose single vs. batch operations, or how it relates to sibling tools like 'get_variant' or 'set_variable'. This leaves the agent without context for appropriate 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. It states the tool 'gets' data, implying a read-only operation, but doesn't confirm if it's safe or has side effects. It also doesn't mention rate limits, authentication needs, or what happens with invalid node IDs, leaving significant behavioral gaps for a tool that queries multiple nodes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without any wasted words. It directly communicates the tool's function in a clear and structured manner, 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.
Completeness3/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 minimally adequate for a read operation. It specifies what data is retrieved but lacks details on return format, error handling, or performance considerations. For a tool that queries potentially multiple nodes, more context on output structure or limitations would improve 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?
The input schema has 100% description coverage, clearly explaining the two parameters (nodeId and nodeIds) and their mutual exclusivity. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. With high schema coverage, a baseline score of 3 is appropriate as the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Gets fill and/or stroke color(s) and stroke weight for one or more nodes.' It specifies the action (gets), the resources (fill/stroke colors, stroke weight), and the target (nodes). However, it doesn't explicitly differentiate from sibling tools like 'get_node_style' or 'get_vector', which might retrieve similar style properties, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or comparisons to sibling tools such as 'get_node_style' or 'get_vector', which could also retrieve style-related data. This lack of context leaves the agent without clear 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. It mentions the return format for single and batch cases, which adds some behavioral context, but lacks details on permissions, rate limits, error handling, or whether it's a read-only operation (implied by 'get' but not explicit). This is a significant gap 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 front-loaded with the core purpose, followed by return details in a clear, efficient two-sentence structure. Every sentence adds essential information without waste, 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 no annotations, 0% schema coverage, and no output schema, the description is incomplete. It covers the basic purpose and return format but misses parameter details, behavioral traits, and usage context. For a tool with two parameters and no structured support, this is minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implies parameters for node IDs but doesn't explain 'nodeId' versus 'nodeIds' usage, their formats, or constraints. The mention of 'single' and 'batch' hints at parameter roles but lacks specifics, providing marginal value over the bare 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 tool retrieves layout grids for Figma nodes, specifying the node types (FRAME, COMPONENT, INSTANCE) and distinguishing it from siblings like 'get_guide' or 'get_constraint'. However, it doesn't explicitly differentiate from 'get_node_info' or 'get_node_style', which might also retrieve node properties, making it slightly less specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_node_info' or 'get_guide', nor any prerequisites or exclusions. The description only states what it does, leaving usage context implied from the function name and return format.
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?
The description adds minimal behavioral context beyond what annotations provide. Annotations already cover idempotency, non-destructive nature, and edge cases. The description only adds that it 'applies an effect style' and describes the return format. While not contradictory, it doesn't enrich understanding of how the tool behaves in practice beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two clear sentences: one stating the action and one describing the return format. There's no wasted verbiage, and the information is front-loaded. However, the return format description could be more efficiently integrated with the main purpose statement.
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 rich annotations (covering idempotency, edge cases, examples) and complete schema coverage, the description is minimally adequate. However, for a mutation tool that changes visual properties, the description could better explain what 'applying an effect style' means in practical terms - whether it overrides existing effects, merges with them, or replaces them entirely.
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?
With 100% schema description coverage, both parameters are already well-documented in the input schema. The description adds no additional parameter semantics - it doesn't explain what constitutes a valid 'effect style' or 'node' beyond what the schema already states. The baseline score of 3 reflects adequate coverage through the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Applies') and resource ('effect style to a node in Figma'), making the purpose immediately understandable. However, it doesn't differentiate this tool from similar sibling tools like 'set_effect' or 'set_node_style', which could have overlapping functionality. The description is specific about what it does but lacks sibling comparison context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With sibling tools like 'set_effect' and 'set_node_style' available, there's no indication whether this tool is for applying predefined styles versus custom effects, or what distinguishes it from other styling tools. The description assumes the user already knows when this specific tool is appropriate.
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?
Annotations indicate this is a write operation (readOnlyHint: false) and not idempotent (idempotentHint: false), which the description aligns with by using 'creates'. The description adds context about batch capabilities, but doesn't disclose other behavioral traits like error handling, permissions needed, or rate limits, leaving some gaps despite annotations covering basic safety.
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 directly address the tool's functionality and usage distinction. Every word serves a purpose, and it's front-loaded with the core action, 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 the complexity (2 parameters with nested objects, no output schema, and 0% schema coverage), the description is incomplete. It doesn't explain what vector nodes are, how they differ from other shapes, expected inputs like 'vectorPaths', or output details, leaving significant gaps for an AI agent to understand and use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only briefly mentions 'vector' for single and 'vectors' for batch without explaining parameter meanings like 'vectorPaths', 'parentId', or defaults. This leaves most parameters undocumented, failing to add sufficient semantic value beyond the bare 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 ('creates') and resource ('vector nodes in Figma'), making the purpose evident. It distinguishes between single and batch operations, though it doesn't explicitly differentiate from sibling tools like 'create_rectangle' or 'create_ellipse' beyond the resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage by specifying when to use 'vector' vs. 'vectors' for single or batch operations. However, it lacks explicit guidance on when to choose this tool over alternatives like 'create_rectangle' or 'create_polygon', and 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions that the tool clones nodes and returns new node IDs, which indicates a write operation. However, it lacks details on permissions, rate limits, error handling, or whether cloning preserves node properties. The description adds some value but does not fully compensate for the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with two sentences: one explaining the tool's function and parameters, and another detailing the return format. It avoids unnecessary details and is front-loaded with the core purpose. However, the return description could be slightly more integrated into the main flow.
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 (cloning with optional configurations) and the absence of annotations and output schema, the description is moderately complete. It covers the basic operation and return format but lacks deeper context such as error cases, performance implications, or examples. It meets minimum viability but has clear gaps in behavioral and usage details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal semantics by noting the tool accepts 'either a single node config (via 'node') or an array of configs (via 'nodes')' and mentions optional positions, offsets, and parent, but this mostly reiterates schema information. 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 tool's purpose: 'Clones one or more nodes in Figma.' It specifies the verb ('clones') and resource ('nodes in Figma'), making the action unambiguous. However, it does not explicitly differentiate from sibling tools like 'duplicate_page' or 'copy_node' (if present), which slightly reduces clarity.
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 the tool accepts single or batch configurations but does not specify scenarios for choosing between 'node' and 'nodes' parameters or when cloning is preferred over other operations like 'create_frame' or 'copy_node'. This lack of context leaves usage 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?
No annotations are provided, so the description carries the full burden. It discloses the return format ('Array of guides, each with { axis, offset }'), which is helpful. However, it lacks critical behavioral details: whether this is a read-only operation (implied by 'Get' but not stated), if it requires specific permissions, error conditions, or pagination/rate limits. 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 perfectly concise and well-structured: two sentences that front-load the core purpose and follow with return details. Every word earns its place, with no redundancy or fluff. It efficiently communicates essential information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is minimally complete. It states what the tool does and the return format, which is adequate for a basic retrieval operation. However, it lacks context about behavioral aspects (e.g., read-only nature, error handling), leaving gaps that could confuse an agent in complex scenarios.
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% (empty schema). The description doesn't need to explain parameters, so it appropriately focuses on output. It adds value by specifying the return structure, which isn't covered by an output schema. Baseline for 0 params is 4, and it meets this by being concise and relevant.
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 guides on the current Figma page.' It specifies the verb ('Get') and resource ('guides'), and indicates scope ('all guides', 'current Figma page'). However, it doesn't explicitly differentiate from sibling tools like 'get_page' or 'get_annotation', which are also retrieval operations in the same context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an active page), exclusions, or related tools like 'set_guide' for modification. Usage is implied by the name and purpose but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide significant behavioral hints: readOnlyHint=false (implies mutation), idempotentHint=true (safe to retry), destructiveHint=false (non-destructive). The description adds context by specifying that it's for communication with Figma and describes the return format, which is useful beyond annotations. However, it doesn't cover aspects like rate limits, authentication needs, or error conditions.
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 concise and front-loaded, with the main purpose stated first and return details following. It uses two sentences efficiently, though the return format explanation could be slightly more streamlined (e.g., by omitting redundant 'type: text' detail if not critical).
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 1 parameter with full schema coverage, annotations covering key behavioral traits, and no output schema, the description is moderately complete. It explains the purpose and return format but lacks details on error handling, side effects, or when to use alternatives, leaving some gaps for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'channel' clearly documented in the schema as 'The name of the channel to join. Must be a non-empty string.' The description adds no additional parameter semantics beyond this, so it meets the baseline of 3 where the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Join a specific channel') and the purpose ('to communicate with Figma'), which is a specific verb+resource combination. However, it doesn't distinguish this tool from its many siblings (like 'subscribe_event' or other communication-related tools), as the sibling list doesn't show obvious alternatives for joining channels.
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., whether the channel must exist or if authentication is needed), nor does it reference any sibling tools for comparison, despite the long list of siblings that might include related functionality.
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?
Annotations provide significant behavioral information (readOnlyHint=false, destructiveHint=false, idempotentHint=true). The description adds value by specifying the return format ('Array of objects...'), which isn't covered by annotations. However, it doesn't mention important behavioral aspects like permission requirements, rate limits, or what happens to child nodes during resizing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief with two sentences: one stating the purpose and one describing the return format. Both sentences earn their place by providing essential information. The structure is front-loaded with the core action first. Minor deduction because the return format description could be slightly more concise.
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 good annotations but no output schema, the description provides basic purpose and return format information. However, it lacks important context about how this operation fits within the Figma editing workflow, what validation occurs, or error conditions. The return format description helps but doesn't fully compensate for the missing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the input schema already fully documents all three parameters with their constraints and formats. The description adds no additional parameter information beyond what's in the schema. The baseline score of 3 reflects adequate coverage when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Resize a node in Figma') with a specific verb and resource. It distinguishes from siblings like 'move_node' or 'rotate_node' by focusing on dimension changes. However, it doesn't explicitly differentiate from tools like 'set_node' or 'set_node_prop' that might also modify node properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools that modify nodes (e.g., 'set_node', 'set_node_prop', 'move_node'), there's no indication of when resizing is the appropriate operation versus other modification methods. 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide significant behavioral information (idempotentHint=true, destructiveHint=false, readOnlyHint=false), so the description's burden is reduced. It adds value by describing the return format (array of objects with type, text fields), which isn't covered by annotations. However, it doesn't mention potential side effects, permissions needed, or rate limits that would enhance transparency beyond annotations.
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 efficiently structured with a clear purpose statement followed by return format details. Both sentences earn their place by providing essential information. However, the return format description could be slightly more concise, and there's some redundancy in describing the content structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations (idempotent, non-destructive, read/write) and comprehensive schema coverage, the description provides adequate context for a transformation tool. The addition of return format information compensates for the lack of output schema. However, it could better address when to use this versus other node manipulation tools for more complete 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?
With 100% schema description coverage, all parameters are well-documented in the schema itself. The description adds no additional parameter semantics beyond what's already in the schema descriptions (e.g., angle direction, pivot options, custom pivot requirements). This meets the baseline for high schema coverage but doesn't provide 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 ('Rotate a node in Figma') with the specific resource ('node'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from sibling tools like 'set_matrix_transform' or 'reorder_node' that might also affect node positioning or transformation, missing full 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. With many sibling tools that manipulate nodes (e.g., 'move_node', 'resize_node', 'set_matrix_transform'), there's no indication of when rotation is the appropriate operation versus other transformations or adjustments.
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?
Annotations provide rich behavioral info (readOnlyHint=false, idempotentHint=true, destructiveHint=false, edgeCaseWarnings). The description adds minimal value by specifying the return format ('Array of objects...'), which isn't covered in annotations. However, it doesn't elaborate on side effects, permissions, or rate limits beyond what annotations imply, so it's adequate but not highly informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the main purpose stated first and return details in a separate section. Both sentences are relevant and add value, with no wasted words. It could be slightly improved by integrating the return info more seamlessly, but it's efficient overall.
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 (3 required parameters), rich annotations, and no output schema, the description is reasonably complete. It covers the action and return format, though it lacks usage context. With annotations handling safety and edge cases, the description provides enough context for an agent to understand the tool's role, but gaps in guidelines prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear parameter descriptions and enums. The description adds no parameter-specific information beyond what's in the schema. According to the rules, when schema coverage is high (>80%), the baseline score is 3 even without param details in the description, which applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Sets hug or fill sizing mode on an auto layout frame or child node in Figma.' It specifies the verb ('Sets'), resource ('auto layout frame or child node'), and domain ('Figma'). However, it doesn't explicitly differentiate from sibling tools like 'set_auto_layout' or 'resize_node', which might handle similar operations, 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, context, or compare with sibling tools like 'set_auto_layout' or 'resize_node'. This leaves the agent without clear usage instructions, relying solely on the tool name and annotations.
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 the mutation action ('Set') and return format ('Array of result objects'), but lacks critical details: whether this operation is destructive to existing constraints, permission requirements, error conditions, or how batch operations handle failures. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief (two sentences) and front-loaded with the core purpose. The second sentence about return values is useful but could be integrated more smoothly. No wasted words, though slightly choppy structure.
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 basic purpose and return format but lacks sufficient behavioral context. It doesn't explain what 'constraints' mean in Figma's layout system, potential side effects, or error handling. Given the complexity (4 parameters including nested objects), this is minimally adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 4 parameters and their purposes. The description adds no parameter-specific information beyond what's in the schema (e.g., it doesn't explain constraint combinations or the relationship between 'constraint' and 'constraints' parameters). Baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Set constraints'), the target resource ('Figma nodes'), and enumerates the constraint types ('left/right/top/bottom/center/scale/stretch'). It distinguishes itself from sibling tools like 'get_constraint' (which retrieves constraints) and 'set_auto_layout' (which sets different layout properties).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing node IDs), exclusions (e.g., not applicable to certain node types), or compare it to related tools like 'set_auto_layout' or 'resize_node' that might affect node positioning. Usage context is implied but not explicit.
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?
Annotations provide rich behavioral hints (e.g., readOnlyHint: false, idempotentHint: true, destructiveHint: false, edgeCaseWarnings). The description adds minimal value by mentioning the return format ('Returns: - content: Array of objects...'), which isn't covered in annotations, but it doesn't elaborate on implications like permissions, rate limits, or side effects beyond what annotations already disclose.
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 brief and front-loaded, stating the core action in the first sentence. The second sentence on return values is relevant but could be more integrated. Overall, it avoids unnecessary verbosity, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (3 parameters, no output schema), annotations provide extensive coverage (e.g., usageExamples, edgeCaseWarnings), but the description lacks depth in explaining behavioral context or integration with sibling tools. It's minimally adequate but misses opportunities to enhance understanding beyond structured data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed parameter descriptions in the input schema (e.g., nodeId format, text length limits). The description adds no additional parameter semantics, merely restating the tool's purpose without clarifying parameter interactions or usage nuances 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 ('Sets the text content') and target ('one or more text nodes in Figma'), making the purpose evident. However, it doesn't explicitly differentiate from sibling tools like 'set_text' or 'set_text_style', which could be related text-manipulation tools in the list, leaving room for ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'set_text' or 'set_text_style' from the sibling list. It lacks context on prerequisites, exclusions, or typical scenarios for application, relying solely on the annotations for basic usage hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return format ('Returns: For single: { pageId, name, isActive }, for batch: Array<{ pageId, name, isActive }>'), which is useful behavioral context. However, it doesn't mention other traits like error handling, permissions, or rate limits, leaving gaps for a 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with the first sentence stating the core purpose and the second detailing the return format. Both sentences earn their place by providing essential information without waste. It could be slightly improved by integrating the return details more seamlessly, but it's efficient overall.
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 adequate but has gaps. It explains what the tool does and the return format, which is sufficient for basic use. However, it lacks context on usage scenarios, error cases, or how it fits with sibling tools, making it minimally viable but not fully comprehensive.
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 add parameter details beyond this, but since there are no parameters, a baseline of 4 is appropriate—it doesn't need to compensate for missing param info.
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 info for one, many, or all pages.' It specifies the verb ('Get info') and resource ('pages'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_doc_pages' or 'get_node_info', which might have overlapping functionality in a design context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions that it can handle 'one, many, or all pages,' but doesn't specify scenarios, prerequisites, or exclusions. For example, it doesn't clarify if this is for retrieving basic metadata versus detailed page data compared to siblings like 'get_doc_pages'.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, indicating a safe, repeatable read operation. The description adds that it retrieves 'one or more' nodes, which clarifies the scope, but doesn't provide additional behavioral details like error handling, rate limits, or authentication needs. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has annotations covering safety and idempotency, and no output schema, the description is minimally adequate. However, for a tool with 2 parameters and 0% schema coverage, it should provide more context on parameter meaning and expected outputs to be fully 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 0%, so the schema provides no parameter descriptions. The description specifies that it accepts 'nodeId' or 'nodeIds', adding basic semantics about parameter usage. However, it doesn't explain what these IDs represent, their format, or how they relate to vector nodes, leaving gaps in 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 ('Retrieves') and resource ('vector nodes by ID(s)'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_node_info' or 'get_svg_vector', which might also retrieve node information, so it's not fully distinguished.
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 like 'get_node_info' or 'get_svg_vector' that might retrieve similar data, there's no indication of specific use cases, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds some behavioral context by specifying the return format (array of objects with type 'text'), which isn't covered by annotations. However, it doesn't disclose important behavioral traits like whether this operation modifies existing nodes or creates new ones, what happens to original nodes, or any permission requirements. The annotations provide minimal information (just schema structure), so the description carries significant burden.
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 focused sentences: one stating the purpose and one describing the return format. Every word earns its place, and the structure is front-loaded with the core functionality.
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 this is a node manipulation tool with no output schema and minimal annotations, the description provides basic purpose and return format but lacks important context about how boolean operations work in Figma, what nodes are affected, whether this is destructive, and how it relates to sibling tools. For a tool performing potentially complex geometric operations, more guidance would be helpful.
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 appropriately doesn't waste space explaining non-existent parameters, though it could potentially mention that boolean operations are performed on selected nodes or through some other implicit mechanism.
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 performs boolean operations (union, subtract, intersect, exclude) on Figma nodes, which is a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'join' or 'flatten_node' which might have overlapping functionality in node manipulation 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. With sibling tools like 'join', 'flatten_node', and various node manipulation tools, there's no indication of when boolean operations are preferred over other approaches for combining or modifying nodes.
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?
The description adds some behavioral context beyond what annotations provide. Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows this is a safe, non-destructive read operation. The description adds useful context about the return format ('Array of objects... with generated HTML string'), which isn't covered by annotations. However, it doesn't mention potential limitations like rate limits, authentication needs, or what happens with invalid node IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise and well-structured. The first sentence clearly states the tool's purpose, and the second sentence efficiently describes the return format. Every sentence earns its place with zero wasted words, making it easy for an AI agent to parse quickly.
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 (3 parameters, 100% schema coverage, rich annotations), the description is reasonably complete. It explains what the tool does and what it returns. Since there's no output schema, the return format description is valuable. However, it could be more complete by mentioning when to use this versus sibling tools or potential constraints.
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?
With 100% schema description coverage, the input schema already fully documents all three parameters (nodeId, cssMode, format) with descriptions, defaults, and enums. The description adds no additional parameter information beyond what's in the schema. According to the scoring rules, when schema coverage is high (>80%), the baseline score is 3 even with no parameter details 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 tool's purpose: 'Generates HTML structure from Figma nodes.' It specifies both the verb ('generates') and resource ('HTML structure from Figma nodes'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get_css_async' or 'get_svg_vector' that also generate code from Figma 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. With many sibling tools available (like 'get_css_async' for CSS or 'get_svg_vector' for SVG), there's no indication of when HTML generation is appropriate versus other output formats. The description only states what the tool does, not when it should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide extensive behavioral information (readOnlyHint=false, edgeCaseWarnings, etc.), so the bar is lower. The description adds value by specifying the return format ('content: Array of objects...') which isn't covered by annotations. It also clarifies the batch capability ('one or more child nodes') and the optional index behavior. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise (two sentences) but could be better structured. The first sentence clearly states the purpose, but the second sentence mixes return format details with implementation specifics. It's front-loaded with the core functionality, but the return format explanation could be more streamlined.
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 complexity (batch operations, hierarchical manipulation) and rich annotations, the description provides adequate context. It covers the core functionality and return format, though it lacks output schema. The annotations compensate significantly with edgeCaseWarnings and detailedDescription, making the overall documentation fairly complete despite the description's brevity.
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 doesn't add any parameter-specific information beyond what's in the schema (e.g., no examples of valid node IDs, no clarification on batch vs single operation trade-offs). Baseline 3 is appropriate when the schema carries the full parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Sets or inserts one or more child nodes into parent nodes at optional index positions in Figma.' This specifies the verb (sets/inserts), resource (child nodes into parent nodes), and context (Figma). However, it doesn't explicitly differentiate from sibling tools like 'move_node' or 'reorder_node' which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. While annotations mention 'Use with valid node IDs to avoid unexpected behavior,' this is a general warning rather than usage context. There's no indication of when to choose this over tools like 'move_node', 'reorder_node', or 'set_node_prop' from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are present but complex (ZodEffects with refinement), indicating potential validation or transformation behavior not fully disclosed. The description adds minimal behavioral context: it implies a write operation (mutation) by using 'Sets', but doesn't detail effects like whether changes are reversible, require specific permissions, or have side effects on sibling nodes. With annotations providing some structure, the description adds limited value beyond the obvious mutation intent.
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 ('Sets node properties') and includes essential details (examples, scope). There is no wasted verbiage or redundancy, making it easy to parse quickly. Every word contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 operation with 0 parameters but likely internal validation via annotations), the description is minimally adequate. It states what the tool does but lacks context on behavioral traits, error conditions, or output (no output schema provided). With annotations hinting at refinement effects and no output schema, more detail on expected results or constraints would improve completeness for safe agent 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 input schema has 0 parameters, with 100% description coverage, so no parameters need documentation. The description doesn't mention any parameters, which is appropriate here. It implies properties like 'locked' and 'visible' are set, but since there are no parameters in the schema, this doesn't add or detract from parameter understanding—it's neutral and fits the baseline for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Sets') and target ('node properties'), with examples of specific properties like 'locked' and 'visible'. It also specifies scope ('for one or more nodes'), making the purpose unambiguous. However, it doesn't explicitly differentiate from similar sibling tools like 'set_node' or 'set_annotation', which could handle related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing node IDs or permissions, or contrast it with sibling tools like 'set_node' (which might set different properties) or 'set_ariable' (for variables). 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.
Behavior3/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 discloses the tool performs multiple mutation operations (create, delete, rename, set) and returns an array of results, which is useful behavioral context. However, it doesn't mention permission requirements, error handling, or what 'set current page' specifically means in this 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 perfectly concise with two sentences that each earn their place: the first states all operations, the second describes the return format. No wasted words, front-loaded with the core functionality.
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 multi-operation mutation tool with no annotations and no output schema, the description provides basic operational scope and return format. However, it lacks details about authentication needs, error conditions, batch operation specifics, or what 'result objects' contain. Given the complexity of supporting four different operations, more context would be helpful.
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 appropriately doesn't waste space discussing non-existent parameters, though it could theoretically mention that operations are specified elsewhere (e.g., in request body) but isn't required given the empty 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 tool's purpose with specific verbs (create, delete, rename, set) and resource (page), including batch operations. It distinguishes from siblings like 'duplicate_page' or 'get_page' by covering multiple operations. However, it doesn't explicitly differentiate from all sibling tools that might handle page operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'duplicate_page', 'get_page', and 'get_doc_pages', there's no indication of when this multi-operation tool is preferred over more specific single-operation tools or how it relates to other page-related operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover key behaviors (readOnlyHint=false, destructiveHint=false, idempotentHint=true), but the description adds useful context by specifying the return format ('Array of objects... with the updated node's ID'). This disclosure of output structure goes beyond annotations, though it doesn't mention side effects like visual changes in Figma.
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 front-loaded with the core purpose in the first sentence, followed by return details. Both sentences earn their place by providing essential information, though the return format could be more succinctly integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with rich annotations (covering safety, idempotency, edge cases) and full schema coverage, the description is reasonably complete. It explains the action and return format, though it could better address prerequisites or integration with sibling tools for a perfect score.
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?
With 100% schema description coverage, the schema fully documents both parameters ('radius' and optional 'corners'). The description adds no parameter-specific information beyond what's in the schema, so it meets the baseline of 3 without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Sets') and resource ('corner radius of a node in Figma'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from other node-modification siblings like 'set_fill_and_stroke' or 'set_effect', 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. It doesn't mention prerequisites (e.g., needing a node ID from another tool), nor does it compare with similar tools like 'set_node' or 'set_node_prop' that might also modify node properties.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide rich behavioral hints (readOnlyHint: true, idempotentHint: true, destructiveHint: false, edgeCaseWarnings), so the bar is lower. The description adds value by specifying the return format ('Array of objects... with the pages info as JSON'), which isn't covered by annotations. It doesn't contradict annotations, as 'Get information' aligns with read-only behavior.
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 front-loaded with the core purpose in the first sentence, followed by return details. It's efficient with two sentences, though the return format explanation could be slightly more concise (e.g., 'Returns an array of objects with page information as JSON'). No wasted words, but minor room for tightening.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, read-only), annotations cover safety and edge cases comprehensively, and the description adds output format details. There's no output schema, so the description's return explanation is valuable. It's nearly complete for this context, lacking only explicit sibling differentiation or advanced usage notes.
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% (empty schema). With no parameters, the baseline is 4, as there's nothing to document. The description doesn't need to add parameter semantics, and it appropriately focuses on the output instead.
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 information about all pages in the current Figma document.' It specifies the verb ('Get information') and resource ('pages in the current Figma document'), making the function unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_page' (singular) or 'get_document_info', which might provide overlapping information.
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 sibling tools like 'get_page' (for a single page) or 'get_document_info' (which might include page data), nor does it specify prerequisites or contextual constraints. The annotations include 'extraInfo' with basic usage, but the description itself lacks this guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it specifies the return structure ('Array of objects' with 'type: "text"' and 'text field with the styles info as JSON'), which isn't covered by annotations. Annotations already indicate read-only, non-destructive, and idempotent operations, but the description complements this by detailing the output format, enhancing transparency.
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 front-loaded with the main purpose in the first sentence, followed by return details. It's efficient with two sentences, though the return explanation could be slightly more concise. Overall, it avoids unnecessary fluff and is well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, read-only operation) and rich annotations (including edge case warnings and extra info), the description is reasonably complete. It explains what the tool does and the return format, which is sufficient since there's no output schema. However, it could benefit from mentioning the scope (e.g., shared styles vs. local) as hinted in annotations.
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 doesn't need to explain parameters, and it doesn't add any param-specific information, which is appropriate given the empty input schema. This meets expectations for a parameterless tool.
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'), making the purpose understandable. It distinguishes from siblings like 'get_text_style' by specifying it retrieves all styles, not just text styles. However, it doesn't explicitly contrast with 'get_node_style' which might retrieve styles for specific 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 doesn't mention siblings like 'get_text_style' (for text-only styles) or 'get_node_style' (for styles of specific nodes), nor does it specify prerequisites or exclusions. The annotations include 'extraInfo' suggesting use for listing shared styles, but this isn't in the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide rich behavioral details (readOnlyHint, idempotentHint, destructiveHint, edgeCaseWarnings), so the description's burden is lower. It adds value by specifying the return format ('content: Array of objects...') and clarifying that it scans 'all descendant text nodes', which isn't covered by annotations, enhancing transparency without contradiction.
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 front-loaded with the core action and resource, followed by a clear return format. Both sentences are essential and waste-free, making it highly efficient and well-structured for quick understanding.
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 annotations cover safety, idempotency, and edge cases, and the schema fully documents the single parameter, the description is reasonably complete. However, without an output schema, it could benefit from more detail on return values, but the provided return format is adequate for a read-only 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%, with the parameter 'nodeId' fully documented in the schema. The description doesn't add any extra meaning or details about the parameter beyond what's in the schema, so it meets the baseline score without compensating or detracting.
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 resource ('all text nodes in the selected Figma node'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_styled_text_segments' or 'get_text_style', which might offer similar text-related functionality, so it doesn't reach 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 sibling tools or contexts where this scan is preferred over other text-related operations, leaving the agent without explicit usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide rich behavioral information (readOnlyHint: false, edgeCaseWarnings about node not found errors and delete behavior, usage examples). The description adds value by specifying the return format for single vs batch operations, which isn't covered in annotations. No contradiction with annotations exists.
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 well-structured: one sentence for the core functionality and a clear bullet-point format for return values. Every element serves a purpose with zero wasted words, making it easy to parse quickly.
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 rich annotations (which cover safety, edge cases, and examples) and 100% schema coverage, the description provides adequate context. It adds the return format specification, which is helpful since there's no output schema. For a mutation tool with good annotation support, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema fully documents the 'entries' and 'entry' parameters. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline expectation without enhancing understanding of parameter usage or meaning.
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, update, or delete') and resource ('annotation(s) for one or more Figma nodes'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_annotation' or other annotation-related tools that might exist, though the 'set' vs 'get' distinction is implied.
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 sibling tools like 'get_annotation' for retrieval or other annotation-related operations, nor does it specify prerequisites or appropriate contexts for setting vs updating vs deleting annotations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond annotations by specifying the return format ('Array of objects with type: text and text field'), which isn't covered in annotations. Annotations already cover idempotency, destructiveness, and edge cases, but the description usefully discloses output structure. No contradiction with annotations exists.
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: one stating the core purpose and another specifying the return format. Every word earns its place, and it's front-loaded with the main functionality, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutating operations with multiple parameter combinations) and rich annotations covering idempotency, edge cases, and examples, the description is reasonably complete. It adds output format details, which is helpful since there's no output schema. However, it could better explain the create/update/delete logic interplay.
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?
With 100% schema description coverage, the schema fully documents both parameters ('ids' and 'variables') and their complex structures. The description adds no parameter-specific information beyond what's in the schema, so it meets the baseline of 3 without compensating for any gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'creates, updates, or deletes one or more Figma Variables (design tokens)', which is a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'set_text_style' or 'set_variant' that also modify design elements, leaving room for confusion about when to use this specific variable tool versus other setters.
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. While annotations mention it depends on which parameters are provided, the description itself lacks explicit when/when-not instructions or references to sibling tools, leaving the agent to infer usage from parameter combinations alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide rich behavioral info (readOnlyHint=false, idempotentHint=true, destructiveHint=false, edgeCaseWarnings). The description adds value by specifying the tool creates a 'complete button with background and text' and details the return format (array with node IDs), which isn't covered in annotations. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose in the first sentence and return details in the second. It avoids unnecessary elaboration, though the return format explanation could be slightly more concise. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (13 parameters, nested objects) and rich annotations (covering safety, idempotency, edge cases), the description is mostly complete. It explains what the tool does and the return format, though it lacks output schema. However, it doesn't fully address usage context or sibling differentiation, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 13 parameters. The description adds minimal param semantics by listing customizable attributes (size, text, colors, font, corner radius, name, parent node) but doesn't provide syntax or format details beyond what the schema already specifies. Baseline 3 is appropriate given 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 tool's purpose with specific verbs ('Creates a complete button') and resources ('in Figma'), distinguishing it from sibling tools like create_rectangle or create_frame by specifying it creates a button with both background and text. It goes beyond just restating the name/title.
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 sibling tools like create_rectangle (for simpler shapes) or create_component_instance (for reusable components), nor does it specify prerequisites like needing a valid Figma document or parent node. 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover key behavioral traits (readOnlyHint=false, destructiveHint=false, idempotentHint=true), but the description adds value by specifying the batch capability ('one or more') and hinting at the return format. However, it doesn't fully explain edge cases like name uniqueness constraints or how duplicates are handled, which annotations partially address with warnings.
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 front-loaded with the core purpose in the first sentence, followed by return value details. It avoids redundancy and wastes no words, though the return format explanation could be slightly more integrated. Overall, it's efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (batch creation with detailed parameters), annotations provide extensive behavioral context (idempotency, warnings), and the schema fully documents inputs. The description covers purpose and output, but lacks usage guidelines. With no output schema, the return format description is helpful but could be more detailed.
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 the 'gradients' parameter and its nested properties. The description only mentions 'one or more gradient style variables', which adds minimal semantic context beyond what the schema already provides. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Creates') and resource ('one or more gradient style variables in Figma'), making the purpose specific and unambiguous. It distinguishes itself from siblings like 'set_gradient' by focusing on creating reusable style variables rather than applying gradients directly to 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 like 'set_gradient' or other style creation tools. It lacks context about prerequisites (e.g., needing a Figma document open) or typical use cases, leaving the agent to infer usage from the tool name and parameters alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide rich behavioral context (e.g., idempotentHint, destructiveHint, edgeCaseWarnings), so the description's bar is lower. It adds value by clarifying the return format ('Returns: - content: Array of objects...'), which isn't covered in annotations. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with the core purpose stated first. However, the return format section could be more concise, and the listing of optional parameters is somewhat redundant with the schema. Overall, it's efficient but has minor verbosity.
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 complexity (creation with multiple parameters) and rich annotations (covering safety, idempotency, edge cases), the description is mostly complete. It lacks output schema, but describes return values. It could improve by addressing sibling differentiation or more detailed usage scenarios, but it's adequate for the 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 parameters are fully documented in the schema. The description adds minimal semantics beyond the schema by listing optional parameters ('name, a parent node ID, fill color, stroke color, and stroke weight'), but doesn't provide additional context like format details or examples. Baseline 3 is appropriate given 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 ('Creates one or more polygons in Figma') and resource ('polygons'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'create_rectangle' or 'create_ellipse' beyond the polygon-specific nature, which is implied but not stated.
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 by mentioning the option for single vs. batch creation ('Accepts either a single polygon config... or an array of configs'), but lacks explicit guidance on when to use this tool versus alternatives like 'create_rectangle' or 'create_vector'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint=true and destructiveHint=false, indicating safe, repeatable operations. The description adds valuable context beyond annotations by specifying the return structure ('Array of objects...') and clarifying that it exports 'from Figma', which implies it's a read operation that doesn't modify the node. However, it doesn't mention potential rate limits, authentication needs, or file size constraints.
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 front-loaded with the core purpose in the first sentence, followed by return details. It avoids unnecessary fluff, but the second sentence could be more integrated (e.g., 'Returns an array of image objects with type, data, and mimeType'). Overall, it's efficient but slightly disjointed in structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, 100% schema coverage, and annotations covering safety/idempotency, the description is reasonably complete. It explains the action, resource, and return format. However, without an output schema, it could benefit from more detail on error cases or output variations (e.g., multiple images for complex nodes).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear documentation for nodeId, format, and scale parameters. The description adds minimal value beyond the schema, only reiterating 'specified format and scale' without providing additional context like format-specific behaviors (e.g., SVG vs. PNG) or scale implications. Baseline 3 is appropriate given the comprehensive schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Exports a node as an image'), the resource ('from Figma'), and the key parameters ('specified format and scale'). It distinguishes itself from sibling tools like 'get_image' (which likely retrieves existing images) or 'set_image' (which modifies images) by focusing on export functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid node ID), exclusions (e.g., unsupported node types), or comparisons to similar tools like 'get_svg_vector' or 'get_html' for different export formats. 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by detailing the return structure ('Array of objects... with CSS properties as JSON'), which isn't covered by annotations. Annotations already provide readOnlyHint, idempotentHint, and edgeCaseWarnings, so the bar is lower. The description complements this with output format specifics, enhancing transparency without contradicting annotations.
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 concise and front-loaded, starting with the core purpose ('Get CSS properties from a node.') followed by return details. Both sentences are relevant and add value, with no wasted words. However, it could be slightly more structured by separating purpose and returns more clearly, but it remains efficient.
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 (2 parameters, no output schema), the description is reasonably complete. It covers the purpose and return format, while annotations handle behavioral hints and examples. Without an output schema, the description's return details are valuable. It could improve by mentioning error cases or sibling differentiation, but it's largely adequate for the 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?
With 100% schema description coverage, the input schema fully documents both parameters ('nodeId' and 'format'), including descriptions and enum values. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3. No compensation is needed given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get CSS properties from a node.' It specifies the verb ('Get') and resource ('CSS properties from a node'), making the action clear. However, it doesn't explicitly differentiate from sibling tools like 'get_node_style' or 'get_html', which might also retrieve style-related information, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage through the return format details, but lacks explicit guidance on when to use this tool versus alternatives like 'get_node_style' or 'get_html'. The annotations include 'extraInfo' suggesting use for 'code generation or inspection', which adds some context, but the description itself doesn't offer clear when/when-not instructions or name specific siblings for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover key behavioral traits (readOnlyHint: true, destructiveHint: false, idempotentHint: true), but the description adds valuable context by specifying the return format ('Array of objects... with the document info as JSON') and hints at the data scope ('detailed information'). This enhances transparency beyond what annotations provide, though it doesn't fully detail edge cases like performance implications.
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 highly concise and well-structured, with two sentences that efficiently convey the tool's purpose and return format. Every sentence earns its place by providing essential information without redundancy, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema) and rich annotations (including edgeCaseWarnings and extraInfo), the description is mostly complete. It covers the core action and return format, but could be more comprehensive by explicitly mentioning when to use it over siblings or detailing the JSON structure further, though annotations help fill some gaps.
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 focuses on the return value instead. Since there are no parameters to explain, a baseline of 4 is justified, as it avoids unnecessary repetition and adds value by describing the output.
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 detailed information about the current Figma document.' It specifies the verb ('Get') and resource ('current Figma document'), making the action explicit. However, it doesn't differentiate from sibling tools like 'get_node_info' or 'get_doc_pages', which also retrieve document-related information, so it falls short of 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 lacks explicit instructions on usage context, exclusions, or comparisons to sibling tools such as 'get_node_info' or 'get_doc_pages', which might retrieve specific subsets of document data. This omission leaves the agent without clear direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide rich behavioral context (readOnlyHint=false, idempotentHint=true, destructiveHint=false, edgeCaseWarnings), so the description's bar is lower. The description adds value by specifying the return format ('content: Array of objects...'), which isn't covered by annotations. It doesn't contradict annotations—the description's 'Moves' action aligns with readOnlyHint=false. However, it could mention more about side effects or constraints beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose. The two sentences are efficient: the first explains the action and parameter options, the second describes the return format. There's no wasted text, though it could be slightly more structured (e.g., bullet points for returns). Every sentence earns its place by adding necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (mutation tool with batch operations), rich annotations (covering safety, idempotency, edge cases), and 100% schema coverage, the description is mostly complete. It adds return format details, which compensates for the lack of output schema. However, it could better integrate with sibling tools (e.g., hinting at when to use vs. 'reorder_node') to be fully comprehensive for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed parameter descriptions in the schema (e.g., nodeId format, x/y ranges). The description adds minimal semantics beyond the schema, only noting the choice between 'move' (single) and 'moves' (array). This meets the baseline of 3 since the schema does the heavy lifting, but the description doesn't provide additional context like examples of valid nodeId formats or practical usage tips.
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 'Moves one or more nodes to a new position in Figma', providing a specific verb ('Moves') and resource ('nodes'). It distinguishes from siblings like 'reorder_node' (which likely changes stacking order) and 'resize_node' (which changes size rather than position), though it doesn't explicitly name these alternatives. The purpose is clear but could be more specific about what distinguishes it from similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied usage guidance by mentioning it accepts 'either a single move config or an array of configs', which helps understand when to use each parameter format. However, it doesn't explicitly state when to choose this tool over alternatives like 'reorder_node' or 'set_matrix_transform', nor does it mention prerequisites or context for when moving nodes is appropriate versus other transformations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover key behavioral traits (readOnlyHint=false, destructiveHint=false, idempotentHint=false, edge case warnings), so the bar is lower. The description adds value by explaining the return format ('Array of objects... with results and any errors') and the batch processing capability with 'skip_errors', which aren't fully detailed in annotations. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core action and key parameters. The second sentence adds useful detail about options, and the return explanation is necessary. However, the return format description could be slightly more concise, and the structure is straightforward but not optimally segmented.
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 complexity (batch operations, error handling) and rich annotations (edge case warnings, usage examples), the description is fairly complete. It covers the main functionality, parameter options, and return format. Without an output schema, the return explanation is valuable. However, it could better integrate with annotations to avoid redundancy and provide more context on sibling differentiation.
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 67%, providing good documentation for parameters like 'reorder', 'reorders', and 'options'. The description adds marginal value by clarifying the choice between single config ('reorder') or array ('reorders') and mentioning 'skip_errors', but doesn't elaborate on parameter meanings beyond what the schema describes (e.g., what 'direction' values imply in context). Baseline 3 is appropriate given the schema's coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('reorders') and resource ('one or more nodes in their parents' children arrays'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'move_node' or 'resize_node', which might also affect node positioning. The title annotation 'Reorder Nodes' reinforces but doesn't add differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reordering nodes within parent arrays, and annotations provide extra context ('useful for changing stacking order of layers'), but it lacks explicit guidance on when to use this tool versus alternatives like 'move_node' (which might handle spatial movement) or 'set_node_prop' (which could modify properties). The edge case warnings hint at prerequisites (valid parent, children array) but don't frame them as usage rules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide rich behavioral information (idempotentHint: true, destructiveHint: false, edgeCaseWarnings). The description adds value by specifying the return format ('array of result objects') and clarifying the single/batch parameter structures, which goes beyond what annotations provide. No contradiction with annotations.
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 efficiently structured with a clear opening sentence followed by bullet-like formatting for parameter structures. Every sentence serves a purpose, though the formatting could be slightly cleaner for machine parsing.
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 annotations provide extensive behavioral context (idempotent, non-destructive, edge cases) and the schema has good coverage, the description adds useful operational context about single/batch modes and return format. The main gap is lack of output schema, but the description partially compensates by specifying the return type.
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 80%, so the schema already documents most parameters well. The description adds marginal value by showing example structures for single vs batch operations, but doesn't explain parameter meanings beyond what's in the schema descriptions (like what 'channelId' or 'parentId' actually do).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'applies' and the resource 'a mask in Figma', specifying it supports both single and batch operations. It distinguishes itself from sibling tools like 'set_effect' or 'set_gradient' by focusing specifically on masking functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'boolean' (which might handle masking differently) or other sibling tools. It mentions support for single/batch operations but doesn't explain when to choose one over the other or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the flattening operation and return format, but misses details like whether this is a destructive mutation (likely, based on 'merging'), permission requirements, error handling, or rate limits. The description adds some value but leaves gaps 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 front-loaded with the core purpose in the first sentence, followed by return details. Every sentence earns its place with zero waste, making it efficient and easy to parse for an AI agent.
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 (3 parameters, no output schema, no annotations), the description is mostly complete. It covers the operation and return format, but lacks details on mutation behavior, error cases, or sibling tool differentiation. Without an output schema, the return explanation is helpful but could be more thorough.
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 the three parameters (nodeId, nodeIds, selection). The description mentions 'one or more nodes' and 'current selection', which aligns with but doesn't add meaning beyond the schema. 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.
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 ('flatten'), target resources ('one or more nodes in Figma, or the current selection'), and outcome ('merging all child vector layers and shapes into a single vector layer'). It distinguishes itself from sibling tools like 'group_node' or 'duplicate_node' by focusing on flattening rather than grouping or copying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning 'one or more nodes' and 'current selection', but lacks explicit guidance on when to use this tool versus alternatives like 'group_node' for organization or 'duplicate_node' for copying. No exclusions or prerequisites are stated, leaving the agent to infer context from the input schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide rich behavioral hints (readOnlyHint: true, idempotentHint: true, destructiveHint: false, edgeCaseWarnings), so the bar is lower. The description adds value by specifying the return format ('Array of objects... with type: text and text field as JSON'), which isn't covered in annotations, enhancing transparency about output structure. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by a concise returns section. Every sentence earns its place by providing essential information without redundancy, making it efficient and well-structured for quick understanding.
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 complexity (4 parameters, read-only operation) and rich annotations covering safety, idempotency, and edge cases, the description is largely complete. It specifies sources and return format, though it could benefit from more detail on pagination behavior or error handling. No output schema exists, but the description adequately describes returns.
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 (e.g., 'after' for pagination, 'source' with enum values). The description doesn't add any meaningful parameter semantics beyond what the schema already provides, such as explaining interactions between parameters (e.g., how 'team_id' relates to 'source'). Baseline 3 is appropriate given 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 ('Get') and resource ('components') with specific sources ('current document, a team library, or remote team libraries'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'get_node_info' or 'get_variant' that also retrieve document elements, missing full 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by listing the three source options, but doesn't provide explicit guidance on when to choose this tool over alternatives like 'get_node_info' for specific component details or 'create_component_instance' for component creation. The annotations include edge cases (e.g., 'team_id is required for team source'), which adds some context but isn't fully integrated into the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by specifying the return format ('Array containing a text message with the updated node(s) ID(s) or a summary'), which isn't covered in annotations. Annotations provide rich behavioral details (e.g., 'idempotentHint: true', 'destructiveHint: false', 'edgeCaseWarnings'), and the description doesn't contradict them. However, it could mention batch processing capabilities more explicitly, though annotations cover this via 'extraInfo'.
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: the first sentence clearly states the purpose, and the second sentence specifies the return format. There's no wasted text, and every sentence earns its place by providing essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (batch operations, multiple application methods) and rich annotations (which cover safety, idempotency, and edge cases), the description is reasonably complete. It explains the core action and return values, though it could benefit from more explicit guidance on usage scenarios. The lack of an output schema is mitigated by the description's return format details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't add parameter-specific details beyond what's in the input schema, which has 100% schema description coverage. It mentions 'one or more nodes' and 'directly or by style variable', which align with the 'entries' parameter but don't provide additional syntax or format insights. With high schema coverage, the baseline is 3, as the schema adequately documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set a gradient on one or more nodes in Figma, either directly or by style variable.' It specifies the verb ('Set'), resource ('gradient'), target ('one or more nodes in Figma'), and two application methods. However, it doesn't explicitly differentiate from sibling tools like 'create_gradient_style' or 'set_fill_and_stroke', which might handle similar operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning two application methods ('directly or by style variable'), but doesn't provide explicit guidance on when to choose one method over the other or when to use this tool versus alternatives like 'create_gradient_style' or 'set_fill_and_stroke'. The annotations include 'extraInfo' and 'edgeCaseWarnings' that offer some context, but the description itself lacks clear when-to-use directives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations by specifying the return format ('Returns: content: Array of objects...') and clarifying the input options (single vs. array). Annotations cover safety (readOnlyHint: false, destructiveHint: false) and idempotency, but the description provides useful operational details without contradicting annotations.
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 well-structured and front-loaded with the main purpose, followed by parameter details and return information. It avoids unnecessary fluff, but the corner radius explanation could be more concise. Overall, it's efficient with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 parameters with nested objects, no output schema), the description is fairly complete. It explains the tool's purpose, input options, return format, and key parameter details. However, it could benefit from more explicit usage guidelines or error handling context, though annotations partially cover this with edge case warnings.
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 some parameter semantics by listing optional properties (name, parentId, fill color, etc.) and explaining corner radius formats, but the input schema has 100% description coverage and already documents all parameters thoroughly. The description provides marginal value beyond the schema, 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 verb ('Creates') and resource ('one or more frame nodes in the specified Figma document'), distinguishing it from sibling tools like create_rectangle or create_ellipse by specifying it creates frame nodes specifically. It also mentions the batch creation capability, which adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by mentioning the tool creates frame nodes, but it does not explicitly state when to use this tool versus alternatives like create_rectangle or create_component_instance. The annotations provide extra context about generating UI containers, but the description itself lacks explicit guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide rich behavioral context (e.g., readOnlyHint: false, idempotentHint: true, edgeCaseWarnings), and the description adds value by explaining the return format ('Array of objects... with the created rectangle node ID(s)') and optional parameters like name, parentId, and corner radius. It does not contradict annotations, enhancing transparency beyond the structured data.
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 well-structured and front-loaded with the core purpose, followed by parameter details and return format. It uses two sentences efficiently, with no wasted words, though it could be slightly more concise by integrating the return format more seamlessly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 parameters with nested objects, no output schema), the description is fairly complete. It covers the tool's purpose, parameter options, and return values, supported by annotations that add usage examples and edge cases. However, it lacks explicit guidance on when to use versus siblings, slightly reducing 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 all parameters thoroughly. The description adds marginal value by mentioning the choice between single config ('rectangle') or array ('rectangles') and optional parameters like name, parentId, and corner radius, but does not provide significant additional semantics beyond what the schema covers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'creates' and the resource 'rectangle shape nodes in the specified Figma document', specifying it can create one or multiple rectangles. It distinguishes from siblings like create_ellipse or create_frame by focusing on rectangles, making the purpose specific and well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating rectangle shapes in Figma documents, with annotations providing extra context like 'Useful for generating UI elements, backgrounds, or design primitives programmatically'. However, it does not explicitly state when to use this tool versus alternatives (e.g., create_button or create_frame) or provide clear exclusions, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide rich behavioral details (e.g., idempotentHint: true, destructiveHint: false, edgeCaseWarnings), but the description adds value by specifying the return format ('Array of objects... with the inserted image node ID(s)'), which is not covered in annotations. It does not contradict annotations, and it complements them with output information, though it lacks details on error handling or performance beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core action and key details. Sentences are efficient, but the return value explanation could be more integrated. There is no wasted text, though minor restructuring might improve flow, such as merging the return details with the main description for better cohesion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (2 parameters with nested objects, no output schema) and rich annotations, the description is mostly complete. It covers purpose, input flexibility, and return values, but lacks explicit usage context or error handling details that could enhance completeness. Annotations fill many gaps, making the overall context sufficient but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed parameter documentation in the schema. The description adds minimal semantics beyond the schema, only clarifying that inputs can be 'a single image config (via 'image') or an array of configs (via 'images')' and listing sources (URL, file path, base64), which are already implied in schema descriptions. This meets the baseline for high schema coverage without significant added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Sets or inserts one or more images into Figma') and resource ('images'), distinguishing it from sibling tools like 'get_image' or 'export_node_as_image'. It specifies the scope (single or multiple images) and supported sources (URL, file path, base64), making the purpose unambiguous and distinct.
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 context by mentioning 'into Figma' and listing input sources, but it does not explicitly state when to use this tool versus alternatives like 'set_node' or 'set_node_prop' for general node operations. No guidance is provided on prerequisites, such as needing an open Figma document or specific permissions, leaving usage context partially inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide extensive behavioral context (readOnlyHint=false, idempotentHint=true, destructiveHint=false, edge case warnings). The description adds value by clarifying the return format ('Array of objects... with inserted SVG vector node ID(s)'), which isn't covered by annotations. No contradiction with annotations exists.
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 efficiently structured in two sentences: the first states the purpose and parameter options, the second explains the return format. Every sentence adds value, though the return explanation could be slightly more concise. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mutation with batch support), rich annotations (covering safety, idempotency, edge cases), and 100% schema coverage, the description is largely complete. It clarifies the return format, which isn't in an output schema. Minor gaps include lack of sibling differentiation and deeper parameter context, but overall it provides sufficient guidance for 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 parameters are fully documented in the schema. The description adds minimal semantics by explaining the 'svg' vs 'svgs' parameter distinction (single vs batch), but doesn't provide additional context beyond what the schema already specifies. Baseline 3 is appropriate given 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 ('Sets or inserts'), target resource ('one or more SVG vectors in Figma'), and distinguishes from siblings like 'create_vector' by specifying SVG content. The verb+resource combination is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for inserting SVG vectors in Figma but provides no explicit guidance on when to use this tool versus alternatives like 'create_vector' or 'set_vector'. It mentions the parameter options (single vs batch) but doesn't contextualize this choice within broader workflows or sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=false, destructiveHint=false, and edgeCaseWarnings, but the description adds valuable context: it specifies the return format (array of objects with type 'text' and instance IDs), which isn't covered by annotations. This disclosure of output behavior helps the agent understand what to expect from the 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 front-loaded with the core purpose, followed by parameter guidance and return format. Every sentence earns its place: the first states what it does, the second clarifies parameter usage, and the third describes the output. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (creation operation with batch support), annotations cover safety and edge cases, and the description adds output details. However, without an output schema, the description's return format explanation is helpful but could be more detailed (e.g., structure of the text field). It's mostly complete but has minor gaps in output documentation.
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 the two parameters (entry and entries). The description adds minimal value beyond the schema by mentioning the single vs. batch creation distinction, but doesn't provide additional semantic context about the parameters. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Creates') and resource ('component instances in Figma'), specifying it can handle single or multiple entries. It distinguishes from siblings like create_components_from_node (which creates components from nodes) and create_button/rectangle/etc. (which create specific element types).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating component instances, but doesn't explicitly state when to use this vs. alternatives like create_components_from_node or create_button. It mentions the entry/entries parameter choice, which provides some operational guidance, but lacks explicit when/when-not scenarios or sibling tool comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond annotations: it specifies the return format ('Array of objects' with 'type' and 'text' fields containing JSON strings), which isn't covered by annotations. Annotations already cover readOnlyHint=false (mutation), destructiveHint=false (non-destructive), idempotentHint=true, and edge cases, so the description doesn't need to repeat those. No contradiction with annotations exists.
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 highly efficient: the first sentence states the core purpose, and the second sentence clearly describes the return format. Every word earns its place with no redundancy, and it's front-loaded with the main action. The structure separates purpose from output details cleanly.
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 complexity (batch conversion with nested objects) and rich annotations (covering idempotency, destructiveness, edge cases), the description is mostly complete. It adds return format details, which compensates for the lack of output schema. However, it could briefly mention the batch nature hinted in annotations but not explicitly in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description doesn't add any parameter-specific details beyond what's in the schema (e.g., it doesn't explain 'entries' array structure or 'skip_errors' behavior). Baseline 3 is appropriate since the schema carries the full burden, and the description adds no extra param semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('converts one or more existing nodes into components') and resource ('in Figma'), distinguishing it from siblings like create_component_instance (which creates instances from existing components) or create_button/rectangle/etc. (which create new elements from scratch). The verb 'converts' precisely captures the transformation from nodes to components.
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 converting existing nodes to reusable components, which suggests it's for design system workflows. However, it doesn't explicitly state when to use this versus alternatives like create_component_instance (for instantiating existing components) or when not to use it (e.g., if nodes are already components). The annotations provide edge case warnings but no direct comparison guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it explains the return format ('Array of objects... with the created ellipse node ID(s)'), which isn't covered by annotations. While annotations provide edge case warnings and idempotency hints, the description complements this with output structure details, though it doesn't mention rate limits or authentication needs.
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 efficiently structured: first sentence states the core purpose, second explains the parameter options, third lists optional parameters, and fourth clearly describes the return format. Every sentence adds value with zero wasted words, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with rich annotations (idempotentHint, edge case warnings) but no output schema, the description provides good completeness by explaining the return format. It covers the essential what, how, and output, though it could benefit from more explicit usage guidance relative to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema fully documents all parameters. The description adds minimal value by mentioning the optional parameters (name, parent ID, colors, stroke weight) but doesn't provide additional semantic context beyond what's already in the schema. 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.
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 ('Creates one or more ellipse nodes') and resource ('in the specified Figma document'), distinguishing it from sibling tools like create_rectangle or create_polygon that create different shape types. It precisely defines 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through parameter explanation (single vs. array configs) but doesn't explicitly state when to use this tool versus alternatives like create_rectangle or create_vector. The annotations provide extra context about batch creation efficiency, but the description itself lacks explicit guidance on tool selection scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide excellent coverage (readOnlyHint, idempotentHint, destructiveHint, edgeCaseWarnings). The description adds value by specifying the return format structure for both single and batch operations, which isn't covered in annotations. It doesn't contradict annotations (which correctly mark it as read-only and non-destructive). The description complements rather than repeats annotation information.
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 structured and concise. The first sentence states the core purpose. The next two lines efficiently document return formats for both operation modes. Every sentence earns its place with no wasted words. The information is front-loaded with the most important purpose statement first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with comprehensive annotations and full schema coverage, the description provides adequate context. It explains what the tool returns, which is crucial since there's no output schema. The main gap is lack of explicit guidance on when to use this versus other node information retrieval tools. Given the rich annotations, the description is reasonably complete for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already fully documents both parameters (nodeId for single, nodeIds for batch). The description mentions 'one or more Figma nodes' which aligns with the parameters but doesn't add meaningful semantic information beyond what's in the schema. The baseline score of 3 is appropriate when the schema does all the parameter documentation work.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('Get') and resource ('annotation(s) for one or more Figma nodes'). It distinguishes itself from siblings like 'set_annotation' (write operation) and other 'get_' tools that retrieve different node properties. The description explicitly mentions both single and batch operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through the return format descriptions (single vs batch), but doesn't explicitly state when to use this tool versus alternatives. It doesn't mention prerequisites, dependencies, or compare with other 'get_' tools like 'get_node_info' or 'get_node_style' that might provide overlapping functionality. The guidance is functional but not strategic.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, and edgeCaseWarnings about invalid nodes and return format. The description adds value by specifying the return structure 'Array of { nodeId, styles } objects, one per node' which clarifies the output organization beyond what annotations state about 'even for single'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: first states purpose with concrete examples, second specifies return format. Perfectly front-loaded with the core functionality, then essential output detail.
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 read-only tool with good annotations covering safety and edge cases, the description is adequate but incomplete. The major gap is parameter documentation (0% schema coverage with no description compensation). Without output schema, the return format description is helpful but minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for 2 parameters, the description provides no information about nodeId/nodeIds parameters. It doesn't explain what format node IDs should be, whether both parameters can be used together, or their relationship. The description fails to compensate for the schema coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'all style properties for one or more nodes', with specific examples of what properties are included (fills, strokes, effects, text styles, style IDs). It distinguishes from siblings like get_fill_and_stroke (subset) and get_text_style (text-specific).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying 'for one or more nodes' and the annotations provide explicit extraInfo 'Use this command to inspect all style properties'. However, it doesn't explicitly state when NOT to use it or name specific alternatives beyond what's implied by the property list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide rich behavioral information (readOnlyHint: false, destructiveHint: false, idempotentHint: true, edgeCaseWarnings, etc.). The description adds value by specifying the return format ('content: Array of objects...'), which isn't covered in annotations. It doesn't contradict annotations but provides additional output 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 extremely concise with only two sentences: one stating the core functionality and one specifying the return format. Every sentence earns its place by providing essential information not available elsewhere. It's front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (conditional grouping/ungrouping with 4 parameters), rich annotations, and 100% schema coverage, the description is reasonably complete. It covers purpose and output format. The main gap is lack of explicit usage guidelines versus alternatives, but annotations provide substantial behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are well-documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions. The baseline of 3 is appropriate when the schema carries the full parameter documentation burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Groups or ungroups') and resource ('nodes in Figma'), and distinguishes this tool from siblings by specifying its unique grouping/ungrouping functionality. It's specific about the conditional behavior based on the 'group' flag.
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 through the 'group' flag parameter but doesn't provide explicit guidance on when to use this tool versus alternatives. While it mentions the conditional behavior, it lacks explicit when/when-not scenarios or named alternatives among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide rich behavioral context (idempotentHint: true, destructiveHint: false, edgeCaseWarnings). The description adds value by specifying it works on 'one or more layout grids' (implying batch operations) and mentioning the return format 'Array of result objects for each operation', which isn't covered in annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: first sentence states purpose and scope, second sentence specifies return format. Perfectly front-loaded with essential information.
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 rich annotations (idempotentHint, destructiveHint, edgeCaseWarnings) and 100% schema coverage, the description provides adequate context. It adds useful information about batch operations and return format. The main gap is no output schema, but the description partially compensates by mentioning the return structure.
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 the single 'layout' parameter and its nested properties. The description doesn't add any parameter-specific details beyond what the schema provides, maintaining the baseline score 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 verb 'Set, update, or delete' and the resource 'layout grids on Figma nodes', specifying the node types (FRAME, COMPONENT, INSTANCE). It distinguishes from sibling tools like 'set_auto_layout_resizing' by focusing on layout grids rather than resizing behavior.
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 layout grid operations on Figma nodes but doesn't explicitly state when to use this tool versus alternatives like 'set_auto_layout_resizing' or other node modification tools. 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide rich behavioral context (idempotent, non-destructive, batch support, edge cases), but the description adds value by specifying the return format ('Array containing a text message with updated node(s) ID(s) or a summary'), which isn't covered in annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and scope, second specifies return format. No wasted words, front-loaded with core functionality, and appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations (covering safety, idempotency, batch support, examples, warnings) and 100% schema coverage, the description is mostly complete. It adds return format details not in annotations, though lacks output schema. Minor gap in not explicitly linking to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so parameters are fully documented in the schema. The description doesn't add parameter-specific details beyond mentioning 'direct or by style variable' and 'one or more nodes', which aligns with but doesn't extend schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'effect(s)' on 'nodes in Figma', specifying both direct and style variable methods. It distinguishes from sibling 'apply_effect_style' by covering both approaches and batch operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for setting effects on Figma nodes but doesn't explicitly state when to use this tool versus alternatives like 'apply_effect_style' or other styling tools. No guidance on prerequisites or exclusions is provided beyond what's in annotations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond annotations by specifying the return format ('Array of objects... with the detached instance's ID or error info'), which is not covered in annotations. Annotations already cover key behavioral traits (e.g., 'destructiveHint: false', 'idempotentHint: true', edge cases), but the description provides useful output context without contradiction.
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 front-loaded with the core action and resource, followed by return details in a clear format. It uses two sentences efficiently, with no wasted words, though it could be slightly more structured for readability.
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 complexity (3 parameters, nested objects, no output schema) and rich annotations (covering safety, idempotency, edge cases), the description is reasonably complete. It adds output format details, but could benefit from more context on when to use specific parameters, though annotations help fill gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema fully documents parameters like 'instanceId', 'instanceIds', and 'options'. The description does not add any parameter-specific semantics beyond what the schema provides, meeting the baseline for high 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 verb ('detaches') and resource ('Figma component instances from their masters'), making the purpose specific. It distinguishes from siblings like 'create_component_instance' or 'duplicate_node' by focusing on detachment rather than creation or duplication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for detaching component instances, but does not explicitly state when to use this tool versus alternatives like 'flatten_node' or 'delete_node'. However, the annotations provide extra context with 'Use this command to detach one or more component instances from their masters in a single call,' which clarifies the intended context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide rich behavioral hints (readOnlyHint: true, idempotentHint: true, destructiveHint: false, edgeCaseWarnings). The description adds value by specifying the return format ('Array of objects... with the node(s) info as JSON'), which is not covered in annotations. It does not contradict annotations, as 'Get' aligns with readOnlyHint, and it provides useful context on output structure beyond the safety profile.
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 front-loaded with the core purpose and efficiently structured into two sentences: one for the action and one for the return format. It avoids redundancy with annotations and schema, though it could be slightly more concise by integrating return details with the action statement, but overall it is well-sized and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (read-only, multiple parameters, no output schema), the description and annotations together provide a complete picture: purpose, usage, behavioral traits (safe, idempotent), parameter details, and edge cases. The description covers the return format, compensating for the lack of output schema, but could slightly enhance completeness by mentioning performance implications or error handling more explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed descriptions for 'nodeId' and 'nodeIds' parameters (e.g., format requirements, array constraints). The description does not add any parameter-specific information beyond what the schema provides, such as explaining the relationship between 'nodeId' and 'nodeIds' or usage examples. Baseline score of 3 is appropriate as the schema fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get detailed information') and resource ('one or more nodes in Figma'), with specific distinction from siblings like 'delete_node', 'move_node', or 'set_node' which modify nodes rather than retrieve information. The annotations reinforce this with 'Unified version of get_node_info and get_nodes_info' and 'inspect properties and metadata', making the purpose explicit and differentiated.
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 and annotations provide clear context for when to use this tool: to inspect node properties and metadata, as opposed to modifying nodes (e.g., 'set_node', 'delete_node') or retrieving other data (e.g., 'get_document_info', 'get_components'). However, it lacks explicit exclusions or alternatives for specific scenarios, such as when to use 'get_node_info' vs. 'get_selection' or 'get_page', which slightly limits guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide rich behavioral context (e.g., readOnlyHint: false, idempotentHint: true, destructiveHint: false, edgeCaseWarnings), but the description adds value by specifying the return format ('Array of objects... with the created line node ID(s)'), which isn't covered in annotations. It doesn't contradict annotations, and it complements them with output details, though it could mention more about batch efficiency as hinted in extraInfo.
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: the first sentence states the core purpose, followed by input details and return format. Every sentence earns its place without redundancy, making it efficient and well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (creation tool with nested objects) and rich annotations (covering safety, idempotency, edge cases), the description is mostly complete. It explains the action, input options, and return values, but lacks an output schema, so it compensates by describing returns. However, it could integrate more from annotations (e.g., batch efficiency) for full 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 all parameters thoroughly. The description adds minimal semantics by mentioning the input options ('line' or 'lines') and optional parameters, but it doesn't provide additional meaning beyond what's in the schema (e.g., no examples or constraints). 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('creates') and resource ('one or more line nodes in the specified Figma document'), distinguishing it from siblings like create_rectangle or create_ellipse by specifying it's for lines. It also mentions the dual input options (single line vs array), making the purpose specific and well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage by mentioning the input options (single line or array) and optional parameters like parent node ID, stroke color, and stroke weight. However, it doesn't explicitly state when to use this tool versus alternatives like create_vector or create_polygon, nor does it mention any exclusions or prerequisites, keeping it from a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and edgeCaseWarnings. The description adds value by specifying the return format (array of objects with type and text fields) and clarifying it's for analyzing style runs, which goes beyond annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by a concise specification of the return format. Every sentence adds necessary information without waste, making it efficient and well-structured for quick understanding.
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 (2 parameters, read-only operation), annotations provide rich details (edgeCaseWarnings, usageExamples), and the description adds return format clarification. However, there is no output schema, and the description could benefit from more detail on output structure or error handling, though annotations partially compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear descriptions for nodeId (format, purpose) and property (enum values). The description does not add any additional parameter semantics beyond what the schema provides, such as explaining how property selection affects output or nodeId validation details, so it meets the baseline for high 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 verb 'Get' and the resource 'text segments with specific styling in a text node', specifying it analyzes style runs within text nodes. This distinguishes it from sibling tools like get_text_style (which likely gets overall text styles) or get_node_info (general node info), making the purpose specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for analyzing style runs for advanced formatting, and annotations provide extraInfo reinforcing this context. However, it lacks explicit guidance on when to use this tool versus alternatives like get_text_style or get_node_style, though annotations include edgeCaseWarnings that help with prerequisites (e.g., node must be a valid text node).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond what annotations provide. While annotations cover idempotency (idempotentHint: true) and non-destructive nature (destructiveHint: false), the description discloses the return format ('Array of objects... with original and new name(s)') and clarifies the dual input modes (single vs batch). This provides important operational context not captured in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly structured and concise. The first sentence immediately states the core functionality, the second explains the input options, and the third clearly describes the return format. Every sentence earns its place with zero wasted words, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with rich annotations (including idempotency, edge cases, and examples) but no output schema, the description provides good contextual completeness. It explains the return format that the annotations don't cover, though it could potentially mention more about error conditions or the relationship between the two parameter options. Given the comprehensive annotations, the description does well but has minor room for improvement.
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?
With 100% schema description coverage, the input schema already fully documents both parameters ('rename' and 'renames') including their structure, constraints, and descriptions. The description mentions the dual input modes but doesn't add meaningful semantic context beyond what's already in the schema. The baseline score of 3 reflects adequate but not exceptional value addition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('renames') and resources ('nodes in Figma'), distinguishing it from sibling tools like 'delete_node', 'move_node', or 'duplicate_node' which perform different operations on nodes. The description explicitly mentions both single and batch renaming capabilities, making the scope unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool by explaining it accepts either single or batch rename configurations. However, it doesn't explicitly state when NOT to use it or mention alternatives like 'set_node_prop' for other property changes. The annotations provide usage examples but the description itself lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide rich behavioral context (e.g., idempotentHint: true, destructiveHint: false, edge case warnings about batch updates and parameter requirements). The description adds minimal behavioral detail beyond annotations, but it does specify the return format ('content: Array of objects...'), which is useful since there's no output schema. No contradiction with annotations exists.
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 front-loaded with the core purpose in the first sentence, followed by a concise return value explanation. Every sentence earns its place by providing essential information without redundancy, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, nested objects, no output schema) and rich annotations, the description is mostly complete. It covers the purpose and return format, but could better integrate with annotations to explain parameter interactions (e.g., 'nodeId/styles' vs. 'entries') or prerequisites. The annotations compensate well, but the description itself has minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters like 'entries', 'nodeId', and 'styles'. The description doesn't add any parameter-specific semantics beyond what's in the schema, such as explaining the relationship between 'nodeId/styles' and 'entries' or clarifying style property interactions. Baseline 3 is appropriate given 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 ('Sets'), the resource ('text style properties'), and the target ('one or more nodes in Figma'). It distinguishes from siblings like 'set_text' (which likely changes text content) and 'set_text_content' by focusing specifically on style properties like font, size, weight, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating text styles, and annotations provide edge case warnings about valid node IDs and batch updates. However, it doesn't explicitly state when to use this versus alternatives like 'set_node_style' (which might apply broader styles) or 'get_text_style' (for reading styles), leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable context beyond annotations: it specifies that duplication includes 'all its children' and describes the return format ('Array of objects... with the new page info as JSON'). Annotations provide edgeCaseWarnings about independent children and readOnlyHint=false for mutation, but the description complements this with output details not covered elsewhere.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states the core action and scope, second describes the return format. Every sentence adds essential information with zero waste, and the purpose is front-loaded effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (duplication with children), rich annotations (including edgeCaseWarnings and usageExamples), and no output schema, the description provides complete context: it clarifies the scope, output format, and complements annotations without redundancy.
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?
With 100% schema description coverage, the schema already documents both parameters (pageId and newPageName). The description doesn't add parameter-specific details beyond what's in the schema, so it meets the baseline of 3 without compensating value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Duplicate') and resource ('a Figma page and all its children as a new page'), distinguishing it from sibling tools like duplicate_node (which duplicates individual nodes) and create_page (which creates empty pages). The verb+resource combination is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for duplicating entire pages with their contents, but doesn't explicitly state when to use alternatives like duplicate_node for partial duplication or create_page for empty pages. The annotations provide extraInfo clarifying 'entire page and its contents', which helps but isn't in the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations by specifying the exact return format ('Array of { nodeId, svg } objects, one per node') and clarifying that it works for 'one or more' nodes. While annotations cover read-only, idempotent, and error conditions, the description provides concrete output structure information.
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: the first states the tool's function, the second specifies the return format. There's zero wasted language, and the information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations (readOnlyHint, idempotentHint, edgeCaseWarnings, usageExamples) and complete schema coverage, the description provides exactly what's needed: clear purpose statement and output format clarification. The combination of description and annotations creates a complete understanding of this read-only data retrieval 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?
With 100% schema description coverage, the input schema already fully documents both parameters (nodeId and nodeIds) including their mutual exclusivity. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline expectation.
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 ('Get SVG markup') and target resource ('vector nodes'), distinguishing it from sibling tools like 'get_vector' or 'export_node_as_image'. The verb 'Get' combined with the resource type provides precise purpose identification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through 'one or more vector nodes' but doesn't explicitly state when to use this versus alternatives like 'get_vector' or 'export_node_as_image'. However, the annotations provide clear usage examples and edge case warnings that help guide proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide rich behavioral info (e.g., idempotentHint: true, destructiveHint: false, edgeCaseWarnings). The description adds value by explaining the return format ('Returns: - content: Array of objects...') and clarifying the effect of width/height on text box type, which isn't covered in annotations. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: first sentence states purpose, second explains parameter options, third clarifies bounded vs. regular text, and fourth details return format. Every sentence adds essential information with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the rich annotations (including usageExamples and edgeCaseWarnings) and 100% schema coverage, the description provides complete context. It explains creation behavior, parameter usage, and return format. No output schema exists, but the description adequately covers return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents parameters. The description adds marginal value by explaining the text/texts parameter relationship and the width/height effect on text box type, but doesn't provide additional semantic context beyond what's in the schema descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Creates one or more text elements in Figma') and distinguishes it from siblings like 'set_text_content' (which modifies existing text) or 'create_rectangle' (which creates a different element type). It specifies the resource (text elements) and the context (Figma).
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 on when to use this tool: for creating text elements, with options for single or batch creation and bounded vs. regular text nodes. It doesn't explicitly mention when not to use it or name alternatives like 'set_text_content' for modifying existing text, but the context is sufficiently clear for an agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover key behavioral traits (readOnlyHint: true, idempotentHint: true, destructiveHint: false), but the description adds valuable context about the return format ('Array of objects... type: "text" and a text field with the selection info as JSON') and the annotations' edgeCaseWarnings provide additional behavioral details (empty array if nothing selected, array for multiple nodes). The description complements annotations without contradiction.
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 efficiently structured in two sentences: the first states the purpose, the second details the return format. Every sentence earns its place by providing essential information without redundancy, making it front-loaded and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema) and rich annotations, the description is mostly complete. It covers purpose and return format, but could slightly enhance completeness by explicitly mentioning the read-only/inspection nature, though annotations partially address this. It's adequate but not exhaustive.
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 appropriately doesn't discuss parameters, as none exist, and focuses on the return value instead, which adds semantic value beyond the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('information about the current selection in Figma'), distinguishing it from siblings like 'set_selection' or 'get_node_info'. It explicitly identifies the domain (Figma) and scope (current selection).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('current selection in Figma') and the annotations provide explicit guidance ('Use this command to inspect the current selection context'), but it doesn't explicitly state when NOT to use it or name specific alternatives among siblings. The context is clear but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond annotations: it explains the return format ('Returns: content: Array of objects...') which isn't covered by annotations. Annotations already provide destructiveHint=true and edge case warnings, but the description complements this by clarifying the output structure. No contradiction with annotations exists.
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?
Perfectly structured and concise: a clear opening sentence stating purpose, followed by well-organized parameter and return sections. Every sentence earns its place by providing essential information without redundancy. The description is appropriately sized for a tool with 3 parameters and complex behavior.
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 complexity (matrix transformations, batch operations, error handling), rich annotations, and no output schema, the description is nearly complete. It covers purpose, parameters, and return format. The only minor gap is not explicitly mentioning the 6-element matrix requirement (though annotations cover this), making it slightly less than perfect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries full burden and excels: it documents all 3 parameters (entry, entries, options), explains their purposes (single vs batch operations, error handling), and provides semantic meaning for each. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Set') and resource ('transformation matrix on one or more Figma nodes'), specifying both single and batch operations. It distinguishes from sibling tools like 'move_node', 'rotate_node', or 'resize_node' by focusing specifically on matrix transformations rather than simpler geometric operations.
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 about when to use this tool (for setting transformation matrices on Figma nodes, either single or batch). However, it doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools, though the context implies it's for matrix-based transformations rather than other node manipulation methods.
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:

[![conduit MCP server](https://glama.ai/mcp/servers/amalinakurniasari/conduit/badges/card.svg)](https://glama.ai/mcp/servers/amalinakurniasari/conduit)

Score Badge

Copy to your README.md:

[![conduit MCP server](https://glama.ai/mcp/servers/amalinakurniasari/conduit/badges/score.svg)](https://glama.ai/mcp/servers/amalinakurniasari/conduit)

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/amalinakurniasari/conduit'

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