Talk to Figma MCP
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation3/5
There are redundant tools like get_selection and read_my_design which both retrieve selection info with unclear distinction. scan_text_nodes and scan_nodes_by_types also overlap, as you can filter by type. While most tools are distinct, these overlaps make misselection likely.
Naming Consistency4/5Most tool names follow a verb_noun pattern (get_, set_, create_, delete_, move_, etc.). A few outliers like read_my_design, get_figma_comments, and post_figma_comment break the convention slightly, but overall it's fairly consistent.
Tool Count2/542 tools is excessive for the scope, with many granular variants (single vs multiple) that could be consolidated with parameters. Stub tools for comments add to the clutter, making it heavy and potentially overwhelming for agents.
Completeness3/5The set covers many core Figma operations (read nodes, create shapes, edit layout, export), but lacks common operations like modifying text font properties, grouping nodes, deleting annotations, and comments are non-functional stubs. These gaps will require workarounds or cause failures.
Average 3.6/5 across 42 of 42 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the creation action, without mentioning side effects, error conditions, required permissions, or what happens to the frame after creation. No context is given about auto-layout behavior or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no extraneous words, making it efficient and front-loaded. However, given the tool's 20-parameter complexity, it is slightly under-specified but still appropriately concise for stating the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description fails to provide necessary contextual details such as whether the tool returns the new frame's ID, requires a parent, or how the extensive parameters interact. For a complex creation tool with this many options, the one-sentence description is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 20 parameters have detailed descriptions in the input schema, including notes like itemSpacing being ignored when primaryAxisAlignItems is SPACE_BETWEEN. The description adds no additional parameter information, so the baseline of 3 applies given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Create' and resource 'frame', clearly stating the tool's function. It distinguishes from siblings like create_rectangle and create_text by the object type, though it doesn't elaborate on the unique characteristics of frames.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like create_rectangle or create_text, nor does it mention prerequisites such as requiring a parent node. The phrase 'Create a new frame in Figma' offers no contextual usage information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only says 'Delete a node from Figma' and fails to mention permanence, impact on child nodes, or permission requirements. For a destructive operation, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no redundant words. It is front-loaded and to the point, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool, the description is minimal, but it omits important context for a destructive action, such as whether the deletion is permanent or affects child nodes. With no annotations and no output schema, the description should provide more behavioral context to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the only parameter (nodeId) as 'The ID of the node to delete'. The description adds no additional meaning beyond that, so it receives 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the resource (a node in Figma). It is specific and unambiguous, but it does not explicitly distinguish from the sibling tool delete_multiple_nodes, though the singular 'a node' implies a single-node operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. Sibling tools such as delete_multiple_nodes exist, but no mention is made of when to choose this tool or when to opt for the multi-delete variant.
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?
With no annotations, the description carries full responsibility for behavioral disclosure. 'Resize a node in Figma' reveals nothing about side effects, constraints on resizing, or implications for the node's children. This is a significant gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence and no wasted words. It is properly front-loaded with the action and target, although it could have used the available brevity to include context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with only three parameters and no output schema, but the description offers minimal context about the resize operation's effects, return values, or constraints. It is the bare minimum for a usable tool description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are adequately documented in the schema. The description adds no extra semantic detail beyond the schema, but the baseline of 3 applies since the schema handles parameter explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses an explicit verb ('Resize') and resource ('a node in Figma'), clearly stating the tool's function. It distinguishes itself from sibling tools like move_node or clone_node by specifying the resize action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 or any prerequisites/context. The description only states the action without indicating suitable scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'create or update' with no mention of side effects, overwrite behavior, permissions, or return value. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase with no redundancy or irrelevant detail. It is front-loaded and efficient, though it may be too brief for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no output schema, and no annotations. The description does not explain update semantics via annotationId, return values, or how it differs from set_multiple_annotations. It is incomplete for a mutation tool of this scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the baseline is 3. The description adds no additional meaning beyond the schema; it does not clarify relationships between parameters or provide usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create or update) and the resource (an annotation). It implies singular annotation operation, which hints at distinction from set_multiple_annotations, though not explicitly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_multiple_annotations, or on when to update versus create. No context or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to rely on, the description bears full responsibility for behavioral disclosure. It only says 'parallelly,' which is vague and does not mention whether annotations are created or updated, how failures are handled, or the relationship between the parent nodeId and per-annotation nodeId. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the verb and object. It is concise and direct, though 'parallelly' is slightly awkward and the brevity leaves out useful detail. Still, it earns high marks for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the nested annotations array and lack of output schema or annotations, the description is too minimal. It fails to explain key behaviors like whether annotationId indicates update mode, what properties are for, or how errors are returned. The schema helps but does not compensate for the missing contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with detailed parameter descriptions, so the description does not need to add much. However, it adds nothing beyond the schema—no examples, no clarification of the nested annotation structure, or hints about required fields. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Set') and specific resource ('multiple annotations') with a location ('in a node'), effectively conveying the batch operation. However, it does not explicitly distinguish itself from the sibling tool 'set_annotation', relying on the word 'multiple' as the differentiator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'set_annotation'. It does not mention scenarios such as updating existing annotations, creating new ones, or when parallelism is beneficial, leaving usage context entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention that this is a mutating operation (beyond the verb 'set'), does not state whether existing padding is overwritten, whether the frame must already be auto-layout, or what happens if invoked on a non-auto-layout frame. It also omits any side effects or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, eight-word sentence that is concise and front-loaded. It contains no redundant phrases or filler, making it easy to parse and directly communicates the core purpose. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutating nature, lack of annotations, and absence of an output schema, the description is insufficiently complete. It does not explain the return value, error conditions, or the critical requirement that the target frame be an auto-layout. For a tool with five parameters, the description leaves the agent without key operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has complete descriptions for all five parameters (100% coverage), so the baseline is 3. The description itself adds no additional semantic meaning beyond the schema, such as relationships between padding values, units, or constraints. Schema already covers parameter meaning adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (setting padding values) and the target resource (an auto-layout frame), using a specific verb and resource. While it doesn't explicitly contrast with sibling tools, 'padding' is a distinct attribute from the spacing, alignment, and layout mode operations handled by siblings. It could be slightly more explicit about scope, but it is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as the frame being an auto-layout. It only states what the tool does, leaving the agent to infer appropriate usage from the tool name and schema. There is no explicit exclusions or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Get detailed information' without explaining what data is returned, whether the node must exist, or what happens on errors. This provides minimal transparency about the tool's actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words. It is front-loaded with the action and target, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and lack of output schema, the description is minimally adequate. However, it fails to clarify what 'detailed information' includes or how it relates to sibling tools, leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes nodeId as 'The ID of the node to get information about' with 100% coverage. The description adds no extra semantic meaning beyond this, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Get') and target ('detailed information about a specific node in Figma'), which distinguishes it from plural sibling tools like get_nodes_info. However, 'detailed information' is vague and doesn't specify what fields or data will be returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_nodes_info or get_selection. The description does not mention exclusions or scenarios where this tool is preferred over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It merely restates the tool's purpose without disclosing any behavioral details such as whether the move is absolute, affects auto-layout, is reversible, or requires specific permissions. This adds no transparency beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and is efficiently worded. It is appropriately sized for a simple tool, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (3 simple parameters) and 100% schema coverage, the description is minimally adequate. However, without annotations or an output schema, it would benefit from clarifying whether the move is absolute or relative and any side effects, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents all three parameters (x, y, nodeId) with brief descriptions, and schema coverage is 100%. The tool description adds no additional parameter details, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Move') and resource ('a node') and specifies the action's scope ('to a new position in Figma'). It clearly distinguishes from sibling tools like resize_node or delete_node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as clone_node or resize_node. The description only states the action without any context on 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries full behavioral disclosure burden. It states the tool reads the current selection, implying a read-only operation, but it does not describe return format, potential errors (e.g., empty selection), or depth of detail. The phrase 'all node details' is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded. It avoids unnecessary words and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool has no parameters and is simple, the description fails to provide enough context to differentiate it from many sibling tools such as get_selection or get_node_info. It also does not describe what 'detailed information' includes, leaving the agent uncertain about the tool's full capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the description does not need to elaborate. The baseline of 4 applies since there is no parameter information to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving detailed information about the current Figma selection, using specific terms like 'current selection' and 'node details.' However, it does not distinguish itself from sibling tools like get_selection or get_node_info, so it lacks clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 over alternatives. The description does not mention any context or exclusions, leaving the agent to guess which of the many sibling tools is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Create a new rectangle' without mentioning return values, default behavior, permissions, or side effects. For a mutation tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that states the action with zero filler or redundant wording. It is front-loaded and perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the schema covering parameters, the description lacks critical context for a mutation tool with no output schema and no annotations. It does not explain what happens when a rectangle is created, what the return value is, or how it integrates with the Figma document. The description is too minimal to fully inform an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 6 parameters with descriptions, achieving 100% coverage. The description adds no parameter-specific detail, so the baseline score of 3 is appropriate since the schema already handles parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Create' and resource 'rectangle in Figma', clearly indicating the action and object. It distinguishes itself from sibling creation tools like create_frame, create_text, and create_component_instance by naming the shape type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like create_frame or create_text. There is no mention of prerequisites, context, or when one creation tool should be preferred over another.
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 transparency. It does not disclose return format, side effects, required permissions, or behavior around scale/format handling. The agent would not know what the export produces (e.g., a URL, base64, or file path) without additional 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the core purpose without any unnecessary words. It is well-structured and front-loaded, earning a high score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description should explain what the tool returns or any important behavioral details. It does not mention the response format, upload behavior, or any constraints. This is insufficient for an AI agent to fully understand the tool's capabilities and expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters (nodeId, scale, format), so the description does not need to add parameter details. The description does not add extra meaning beyond the schema, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Export') and resource ('a node') with a clear output ('as an image'), making the tool's function unambiguous. It distinguishes itself from sibling tools like get_node_info (which reads info) and create_rectangle (which creates) by focusing on the export action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. With many sibling tools, explicit usage context is missing, leaving the agent without direction on choosing this export tool.
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 exist, so the description carries full burden. It only says 'Set', which implies mutation, but fails to disclose side effects, node-type restrictions, reversibility, or return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single declarative sentence, concise and front-loaded with the key verb and object. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema documents parameters well, the description lacks behavioral context, usage guidance, and node-type constraints. For a mutation tool with no annotations, this is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for all three parameters, and the description adds no additional parameter information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Set' and resource 'corner radius of a node in Figma', clearly indicating the exact action and target. It distinguishes itself well from sibling tools like set_fill_color or set_layout_mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, prerequisites, or alternatives. It doesn't mention which node types support corner radius or when to prefer this over other setter tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It does not mention side effects, preconditions (e.g., node must be a frame), or what happens when layoutMode is NONE or when layoutWrap is set with NONE. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes to the meaning, and it is appropriately sized for a simple setter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the schema fully documents parameters, the description lacks usage context, behavioral details (e.g., constraints on layoutWrap), and any mention of expected outcomes or side effects. With no annotations and no output schema, this minimal description is incomplete for an agent to invoke the tool confidently in diverse scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions and enums. The description echoes 'layout mode and wrap behavior' but adds no new semantic details beyond what the schema already provides, so it stays at the baseline for effective schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states clearly that the tool sets layout mode and wrap behavior on a frame in Figma, using a specific verb and resource. The mention of 'layout mode and wrap behavior' distinguishes it from other set_* sibling tools like set_padding or set_layout_sizing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no when-to-use guidance, no exclusions, and no references to alternative tools. It does not mention conditions like 'use when the frame has auto-layout enabled' or contrast with other layout-related setters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without revealing side effects on existing stroke settings, potential permission requirements, or what happens if the node lacks a stroke. This is insufficient for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently communicates the core action. It wastes no words on filler, though it could include additional operational context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple setter with well-documented parameters, but the description lacks usage context and behavioral details. With no output schema, the agent gets no information about return values or success indicators. The description is minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes all 6 parameters with 100% coverage, including ranges and descriptions. The tool description adds no parameter-specific semantics beyond what the schema already provides, which meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and resource ('stroke color') with a clear target ('a node in Figma'). It distinguishes itself from sibling tools like set_fill_color by naming the stroke property, making the purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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_fill_color or set_corner_radius. It does not mention prerequisites, exclusions, or contexts where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only restates the basic purpose and does not disclose return format, side effects (though likely read-only), permission requirements, or how the 'current document' mode works. The ambiguity about 'current document or specific node' is not resolved by the schema, which marks nodeId as required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, concise and front-loaded with the action. However, the phrase 'current document or specific node' is slightly ambiguous, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain more about expected output and usage nuances. It fails to clarify how to request document-wide annotations when nodeId is required, and does not mention return structure or includeCategories behavior, leaving the tool under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds some context by suggesting nodeId can target either the document or a specific node, but this is vague and slightly inconsistent with the required nodeId. It does not clarify includeCategories beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 'annotations', and identifies the scope 'in the current document or specific node'. This distinguishes it from sibling write tools like set_annotation and set_multiple_annotations, and from get_figma_comments which targets comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the tool retrieves annotations for a document or node, but it does not explicitly name alternatives or state when not to use this tool. It lacks guidance on choosing between get_annotations and get_figma_comments, or when to use the 'current document' mode given nodeId is required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden of disclosing behavior. It mentions node type constraints but does not state whether existing fills are replaced, how multiple fills are handled, what happens for unsupported node types, or what the return behavior is.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and front-loaded with the action. However, the grammar is slightly awkward ('can be TextNode or FrameNode' lacks a relative pronoun), making it less fluid but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 lacks critical context about return values, fill replacement behavior, and error conditions. It is minimal and not adequate for fully informed agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters (r, g, b, a, nodeId) are already documented. The description adds no parameter-specific meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set) and resource (fill color), with explicit node type constraints (TextNode or FrameNode). It distinguishes from sibling set_stroke_color by specifying 'fill' rather than 'stroke'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied when the user wants to change fill color, but no explicit guidance is given about when to choose this vs set_stroke_color or other mutation tools. 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only reveals that the tool uses the default connector style, but does not mention return values, error behavior (e.g., invalid node IDs), side effects (e.g., overwriting existing connections), or permissions. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core purpose. It is concise, but it may be slightly underspecified for a mutation tool, leaving gaps that additional context would fill.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter, no output schema, and no annotations, the description is minimally adequate. It does not explain behavior on failure, whether multiple connections can be created in a single call (though the schema implies this), or what happens if the default style is not set. More context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides descriptions for all parameters (startNodeId, endNodeId, text) with 100% coverage. The description adds no additional parameter semantics beyond what the schema already offers, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create connections between nodes') and the resource ('connections'), and the phrase 'using the default connector style' distinguishes this from the sibling tool set_default_connector, which concerns styles rather than creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating connections with the current default style, but it does not explicitly state when to use this tool versus alternatives like set_default_connector, nor does it mention any exclusions or prerequisites. The reference to 'default connector style' is an indirect hint rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'delete', which is inherently destructive, but gives no details about reversibility, partial failures, error handling, permissions, or whether deletion is atomic. This is a minimal disclosure that adds little beyond the tool's name and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant words. Every word earns its place, and the message is immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is adequate but not complete. It covers the core action but omits important context like what happens when a node ID is invalid, whether the operation is atomic, or whether there is any confirmation. Given the lack of annotations and output schema, more detail would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add any extra meaning to the nodeIds parameter beyond what the schema already provides. It names the parameter but provides no additional context about ID formats or expected values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action (delete) on a specific resource (nodes from Figma), with the scoping word 'multiple' distinguishing it from the sibling delete_node tool. It is immediately obvious what the tool does and how it differs from the singular delete variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use when you need to delete multiple nodes in one call. However, it does not explicitly state when NOT to use it, nor does it mention the alternative delete_node for single deletions. The guidance is inferred from the name and wording rather than explicitly spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read operation via 'Get' but does not disclose what information is returned, whether any permissions are needed, or any other behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler. It is front-loaded with the verb and object, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description leaves the return contents unspecified. 'Detailed information' is adequately scoped to the document but does not enumerate what the agent should expect, which is a clear but acceptable gap for a simple no-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline of 4 applies. There are no parameter semantics to explain, and the schema coverage is trivially complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('current Figma document'), clearly distinguishing it from sibling tools like get_node_info and get_selection. The scope is explicit 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or contrast with sibling tools, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully convey behavioral characteristics, but it does not. It does not state whether the scan is recursive or only direct children, whether it is read-only (though 'scan' hints so), or how the 'selected' node relates to the nodeId parameter. The scope of 'child nodes' remains ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It communicates the core action and target efficiently, which is appropriate for a tool with only two parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (2 params, no output schema), but the description leaves gaps. It does not explain what the function returns (e.g., matching child nodes) or clarify whether scanning is limited to direct children or includes all descendants. The phrase 'selected Figma node' is ambiguous given the explicit nodeId parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage for both nodeId and types, so the baseline is 3. The description does not add extra meaning beyond the schema; it simply restates the purpose. No additional syntax, formatting, or edge-case info is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Scan'), the resource ('child nodes'), and the scope ('with specific types in the selected Figma node'). It distinguishes itself from siblings like scan_text_nodes by being general over types, and from get_node_info/get_nodes_info which retrieve node data rather than searching descendants.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage: use this tool when you need to find child nodes of certain types. However, it provides no explicit guidance on when to use it versus alternatives like get_node_info or scan_text_nodes, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description carries the full burden of behavioral disclosure. It does not explicitly state that this is a read-only operation, nor does it describe the return format or any potential side effects. While 'scan' is generally safe, the lack of any safety or behavioral context is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant information. It is concise and front-loaded, stating exactly what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter and no output schema, the description gives a basic understanding of scope (text nodes within a node) but does not explain what the tool actually returns (e.g., a list of text node IDs or contents). The ambiguity around 'selected Figma node' versus the nodeId parameter also reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes nodeId as 'ID of the node to scan', which fully covers the parameter's semantics (100% schema coverage). The description adds no additional parameter detail, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Scan all text nodes') on a specific resource ('the selected Figma node'), which is distinct from sibling tools like scan_nodes_by_types which covers other node types. It precisely names what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to find text nodes within a specific node, but there is no explicit guidance on when to use this over alternatives like scan_nodes_by_types or get_node_info. No exclusions or alternative tools are mentioned, so it falls at 'implied usage'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without mentioning side effects (e.g., that it mutates the frame) or important constraints such as itemSpacing being ignored when primaryAxisAlignItems is SPACE_BETWEEN. The description is too terse to adequately inform the agent about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler and is front-loaded with the verb and resource. It is exactly as concise as needed for the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple setter, but the description omits mention of counterAxisSpacing and the SPACE_BETWEEN/WRAP interactions that affect behavior. However, the schema covers these details, so the description is adequate for initial selection but not fully complete on its own.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with detailed descriptions for itemSpacing and counterAxisSpacing. The description adds no parameter-level information beyond the general concept of setting spacing, so it meets the baseline but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Set' with a clear resource 'distance between children' and scope 'in an auto-layout frame', making it distinct from sibling layout tools like set_padding or set_axis_align. This clarity allows an agent to immediately understand the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage on auto-layout frames but does not explicitly state when to use this tool over alternatives, name any exclusion cases, or mention prerequisites. No guidance is given on when not to use it, though the auto-layout context provides some implied direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of disclosing behavior. It simply says 'Set' without mentioning side effects, constraints (e.g., FILL only for auto-layout children, HUG only for frames/text), or potential errors when applied to non-auto-layout frames. The schema provides some parameter constraints, but the description itself adds no behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It efficiently communicates the tool's purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool with 3 parameters and no output schema, the description is adequate but leaves gaps. It lacks usage guidance, behavioral side effects, and error conditions. The schema covers parameter details well, but the overall tool context is under-specified relative to its complexity and sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds minimal semantic value by clarifying the target is an 'auto-layout frame', which constrains the nodeId parameter. It also maps 'horizontal and vertical' to the two sizing parameters, but does not extend beyond the schema's enum descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the specific resource 'horizontal and vertical sizing modes for an auto-layout frame in Figma'. It distinguishes from sibling tools like set_layout_mode by focusing on sizing modes rather than layout type, padding, or spacing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for auto-layout frames but does not explicitly state when to prefer this over related tools such as set_layout_mode, set_padding, or set_axis_align. No exclusions or alternative guidance is provided, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It indicates a mutation ('set text content') but does not mention side effects, such as whether it replaces all text or preserves formatting, what happens if the node is not a text node, or any permissions required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no superfluous words. It immediately conveys the verb and resource, making it highly scannable and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter mutation tool, the description is adequate but lacks details about failure modes, return values (no output schema), and prerequisites beyond 'existing'. It covers the core operation but leaves gaps that may require the agent to infer or experiment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both schema parameters (text and nodeId) already have descriptions, so schema coverage is 100%. The description adds no additional parameter context beyond what the schema provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('set text content') and the target ('existing text node in Figma'), which distinguishes it from creation tools like create_text and from bulk operations like set_multiple_text_contents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing text node' implies the tool is for modifying existing nodes, not creating new ones, but it does not explicitly mention alternatives or exclusions (e.g., for multiple nodes use set_multiple_text_contents). Usage context is implied rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It does not disclose what 'information' includes (e.g., node IDs, types, properties), whether it returns a single object or array for multiple selections, or what happens if nothing is selected. This lack of detail makes it hard for an agent to anticipate the return format or edge-case behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, succinct sentence that is front-loaded with the verb and resource. Every word earns its place with no unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is minimal but slightly under-specified. It does not describe the return value structure or error behavior, which would be needed for an agent to fully understand what to expect after invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is 100% and the baseline is 4. The description adds contextual meaning about the 'current selection' (a stateful concept) that is not in the schema, which is useful, though no parameter-specific details are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly names the resource ('information about the current selection in Figma'). It distinguishes itself from sibling tools like set_selections (which sets selection) and get_node_info (which targets a specific node).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it should be used when you need to read the current selection state, but it does not explicitly state when to use it versus alternatives like get_node_info or get_document_info. No exclusions or alternative guidance is provided beyond the implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only says 'Set... alignment,' which is a mutation, but does not disclose preconditions (e.g., node must be an auto-layout frame), side effects, error behavior, or reversibility. The absence of any such detail leaves the agent underinformed about the operation's 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, correctly front-loaded sentence that concisely states the action and object. There is no wasted text or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema covers parameter meanings, the overall tool context is thin. There is no output schema, no annotations, and no mention of expected failure modes or preconditions (e.g., requiring an auto-layout frame). For a simple setter, this is adequate but leaves gaps in understanding conditions or return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the schema itself includes detailed descriptions for both enum parameters, including orientation-specific meanings and SPACE_BETWEEN behavior. The tool description adds no additional parameter information, so it meets the baseline of 3 for relying on schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Set primary and counter axis alignment for an auto-layout frame in Figma.' It uses a specific verb ('Set'), identifies the resource ('primary and counter axis alignment'), and adds context ('auto-layout frame'). This distinguishes it from sibling tools like set_padding or set_item_spacing, which target 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by specifying 'for an auto-layout frame,' which implies the tool is appropriate when the target node is an auto-layout frame. However, it does not explicitly state when not to use it or name alternatives (e.g., set_layout_mode for enabling auto-layout). This is a clear but unexcluded usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action ('Set') without mentioning side effects, mutability, permissions, reversibility, or what happens if the node is not a copied connector.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler words. It efficiently states the action and the object.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter, no annotations, and no output schema, the description covers the basic purpose and a prerequisite, but it omits context such as what 'default connector' affects and what the tool returns. It is adequate for a simple setter but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes connectorId fully, but the description adds the 'copied' qualifier, which is an important precondition not present in the schema. This enriches the parameter semantics by clarifying that the node must be a copy rather than an arbitrary connector.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Set') and a specific resource ('copied connector node as the default connector'), clearly indicating the operation's target and outcome. It distinguishes itself from sibling tools by uniquely naming the 'default connector' concept.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'copied connector node' implies a prerequisite: the node must have been copied first, which provides some usage context. However, there is no explicit when-to-use guidance, no mention of alternatives, and no exclusions relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions 'parallelly' (concurrency) but fails to disclose whether existing text is replaced, the atomicity of the operation, error handling, or any side effects. For a mutation tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, concise, and front-loaded with the key action and scope. There is no wasted wording, though 'parallelly' is an unconventional adverb. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool signature with fully documented schema and no output schema, the description is minimally adequate. It conveys the core purpose but omits important operational context such as the effect on existing text contents and failure behavior. The lack of annotations and output schema makes this a clear gap, but the schema compensates for parameter understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with descriptions for both parameters (nodeId and text array). The description adds minimal semantic value beyond the schema, only indicating that multiple contents are set in parallel. The baseline of 3 applies because the schema already fully documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (set), the resource (multiple text contents), the scope (multiple), and the location (in a node). It distinguishes itself from the sibling tool 'set_text_content' by explicitly stating 'multiple' and 'parallelly'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a clear use case: when you need to update several text nodes at once in a single node. However, it does not explicitly name alternatives or state when not to use it, though the 'multiple' and 'parallelly' wording provides clear context.
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 must carry the burden of behavioral disclosure. The verb 'Get' implies a read-only operation, and the phrase 'all local components' suggests a comprehensive return, but no details about potential failures, rate limits, or return format are given. For a simple getter, this is minimally transparent but still lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that wastes no words. It clearly states the action and resource without filler, 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool with no output schema, the description is mostly complete: it tells the agent exactly what the tool does. However, it does not specify the structure or format of the returned components, which would be helpful since no output schema exists. Still, the tool's simplicity keeps the gap modest.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (trivially). Per the baseline rule for 0 parameters, a score of 4 is appropriate. The description adds no parameter details because none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') with a clear resource ('all local components') and scope ('from the Figma document'). It precisely distinguishes this tool from siblings like get_styles or get_annotations by naming a unique resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention exclusions or prerequisites. It simply states what it does without contextual cues, so an agent would not know when to prefer it over other getter tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. 'Get' implies a read operation with no side effects, but the description does not disclose what 'detailed information' includes, response format, or any limitations. It is not misleading but is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is appropriately sized for the tool's simplicity and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is adequate but has gaps. It does not mention what 'detailed information' includes, any node count limits, or the return format, leaving the agent to infer these from the tool name and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—the parameter 'nodeIds' is described as 'Array of node IDs to get information about'. The description adds no additional parameter semantics, but the schema already provides clear meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get detailed information about multiple nodes in Figma' uses a specific verb ('get'), names the resource ('nodes'), and explicitly indicates plurality ('multiple'), which distinguishes it from the sibling tool get_node_info. It clearly states the tool's primary function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool ('multiple nodes') but does not explicitly mention the alternative get_node_info for single nodes or state exclusions. The context is clear, but it lacks explicit when-not/alternative 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?
With no annotations provided, the description carries the full burden. It discloses important behavioral details: x/y default to parent-relative, positionMode 'frame' converts absolute canvas coordinates to parent local space, and the response returns both parent-relative and absolute bounding box positions. This goes beyond a simple tautological description, though it does not mention potential side effects (e.g., whether the clone is selected).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loaded with the core action. It explains the default behavior and the alternative mode in a clear, efficient manner without wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, but the description states what the response returns (parent-relative position and absolute bounding box), partially filling that gap. It explains the coordinate systems and positionMode, covering the main behavioral complexity. It does not discuss error cases or prerequisites (e.g., existence of the node), but the description is otherwise complete for a moderate-complexity clone operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 four parameters. The description adds context about the coordinate interpretation (parent-relative vs. frame) but this is largely redundant with the parameter descriptions. No new syntax or format details beyond the schema are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Clone an existing node in Figma' — a specific verb and resource. It also distinguishes itself from sibling creation tools (create_rectangle, create_frame, etc.) by focusing on cloning an existing node, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you want to clone a node and explains coordinate behavior, but it does not explicitly compare with alternatives or state when not to use this tool. There are no exclusions or 'instead of' guidance, so the usage context is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey safety and behavior. 'Get' implies a read-only operation, but the description does not explicitly state that it makes no modifications or disclose any side effects, permissions, or return format details. It adds the context that overrides can be applied elsewhere, but this is more about usage than tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundant information. The first states the core function, the second explains the value of the output. Excellent front-loading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one optional parameter, no output schema), the description covers the essential purpose and usage. It lacks explicit return structure details, but this is a simple getter and the sibling set_instance_overrides implies how the result is used. Slightly more detail on the output would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single optional parameter nodeId with a clear description, so schema coverage is 100%. The description adds no further meaning about the parameter, thus the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all override properties from a selected component instance' with a specific verb and resource. It also explains the purpose of the overrides (applying to other instances), distinguishing this getter tool from its sibling set_instance_overrides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the usage context: retrieve overrides so they can be applied to other instances. This suggests the workflow of getting then setting overrides, though it does not explicitly name set_instance_overrides or state when not to use this tool.
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. 'Get' suggests a read-only operation, and 'all styles' indicates comprehensive retrieval, but it does not explicitly state that it is non-mutating, describe the return format, or note any limitations (e.g., only certain style types).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the action and scope. Every word contributes value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's minimal complexity (no parameters, no output schema, no annotations), the description is complete enough for an agent to understand the operation. It could be enhanced by enumerating style types (e.g., fill, text, effect), but this is not strictly necessary for a basic retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description has no parameter semantics to clarify. The baseline for zero-parameter tools is 4, and the description adequately explains what is being retrieved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all styles from the current Figma document' clearly identifies the action (get), the resource (styles), and the scope (current Figma document). It distinguishes itself from sibling tools, none of which target styles specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this should be used when an agent needs to retrieve styles from the current document, but it does not explicitly state when to use it versus alternatives or provide any exclusions. For a simple getter, this implied usage is sufficient 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?
With no annotations, the description carries the full transparency burden. It discloses the primary action (setting selection) and the side effect (scrolling the viewport). However, it does not explicitly state that the selection replaces the existing one, nor does it mention any prerequisites (e.g., nodes must be on the same page). The scroll behavior is a useful disclosure beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that communicates both the action and a key side effect. Every word is informative with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one fully-documented parameter and no output schema, the description covers the core purpose and a relevant side effect. It could be improved by explicitly mentioning that the selection replaces the previous one, but it is sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter nodeIds, and the description's 'multiple nodes' aligns with the array type. The description does not add any additional semantic detail beyond what the schema already provides, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('set') and resource ('selection to multiple nodes in Figma'), and adds a distinct behavior ('scroll viewport to show them'). This clearly distinguishes the tool from read-only siblings like get_selection and other selection-related tools like set_focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context that this is for selecting multiple nodes and bringing them into view. It does not explicitly name alternatives or exclusions, but the presence of get_selection and other setter tools implies this is the setter for multi-selection. It lacks explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavioral traits. It explains the two-component-type behavior (local vs library) and the corresponding parameter usage, which is valuable. However, it does not disclose potential errors, whether the operation is reversible, or what the return value is. For a mutation tool, this is moderate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary action, and then concisely explains the two parameter usage cases. Every sentence adds necessary information with no repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (5 params, no output schema, no annotations), the description covers the main usage distinction well. It does not explicitly warn that one of componentId or componentKey is required despite neither being listed as required in the schema, which could lead to misuse. However, the description implies a component source is needed, and the schema covers positional details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explicitly mapping componentId to the 'id field' and componentKey to the 'publishedKey field' from get_local_components, which is not present in the schema descriptions. This helps the agent select the correct parameter for the component type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb and resource: 'Create an instance of a component in Figma.' It clearly distinguishes from sibling creation tools like create_rectangle, create_frame, and create_text by focusing on component instances. It also adds a critical distinction between local and library components, which fully clarifies the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear guidance on when to use componentId vs componentKey based on whether the component is local or published. It references get_local_components, providing actionable context. However, it does not explicitly state 'use this instead of create_rectangle or create_frame,' relying on implicit differentiation from sibling names.
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 burden. It states 'Get' which implies read-only, but does not disclose potential limitations, authentication requirements, or return format. The critical transform requirement adds useful behavioral context, but overall detail is sparse for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first states purpose, the second delivers a critical workflow instruction. No filler, front-loaded, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool feeding an external pipeline, the description supplies the vital next step (processing with 'reaction_to_connector_strategy') and its destination ('create_connections'). However, without an output schema or return description, the raw reaction format is undocumented. The critical instruction compensates, making it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with 'nodeIds' described as 'Array of node IDs to get reactions from'. The tool description's 'multiple nodes' adds no meaningful detail beyond the schema. Baseline 3 is appropriate since schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get Figma Prototyping Reactions from multiple nodes' – a specific verb, resource, and scope. This distinguishes it from sibling tools like get_node_info or get_selection by focusing on reactions. The purpose is unambiguous and action-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit, critical instruction: output MUST be processed via 'reaction_to_connector_strategy' to generate parameters for 'create_connections'. This establishes the exact workflow and when the tool should be used. While no alternatives are mentioned, there are no reaction-specific sibling tools, so this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals a key side effect: target instances will be swapped to the source component, which is not obvious from the tool name. It also confirms that all copied override properties will be applied, giving a clear outcome. Missing details like error handling or prerequisite failure are not critical for this simple 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose and then the detailed behavior. No extraneous information or repetition of structured data. It is highly concise and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two fully documented parameters and a simple action, the description is mostly complete. It explains the input and outcome, but could be stronger by explicitly stating that a prior copy operation is required and how selection works (though the schema mentions 'currently selected instances'). The absence of an output schema is fine since the description doesn't promise a return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters fully (sourceInstanceId as the source component, targetNodeIds as target instance IDs). The description adds a bit of relationship context ('Target instances will be swapped to the source component') but does not add meaningful semantic detail beyond the schema. With 100% schema coverage, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: applying previously copied overrides to component instances. It uses a specific verb ('apply') and resource ('overrides to component instances'), and the second sentence clarifies the swap behavior, distinguishing it from just reading overrides (get_instance_overrides) or creating instances (create_component_instance).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the context of use: it only makes sense after overrides have been copied ('previously copied overrides') and when instances are selected ('selected component instances'). It does not explicitly name alternative tools or provide when-not-to-use guidance, but the context is clear enough for an agent to infer the intended workflow.
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?
It openly discloses that this is a stub and that the message parameter is ignored, adding context beyond the neutral annotations. It does not specify the exact runtime behavior (e.g., whether it throws an error or silently does nothing), but the stub nature is clearly communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with 'Stub' to immediately signal unsupported status. It efficiently conveys the limitation without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a stub tool, the description is complete: it explains why the tool exists, the external dependency, and that no plugin equivalent is possible. No output schema is needed, and the minimal schema aligns with the stub nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full coverage for the single parameter 'message' with an explanatory description that it is ignored. The tool description does not add additional parameter detail, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a stub for posting Figma comments, explicitly stating that the REST API is disabled and there is no plugin-based equivalent. It distinguishes itself from get_figma_comments by indicating that posting is unsupported while getting may be available.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states that posting comments requires the REST API which is disabled, making it clear that this tool should not be relied upon for creating comments. It explains that there is no plugin-based alternative, giving users context to avoid this tool, though it does not explicitly name an alternative within the plugin.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It transparently discloses two key behaviors: selecting the node and scrolling the viewport to it. This is meaningful beyond simply 'set focus'. It does not mention failure modes or permissions, but for a simple viewport control tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that states the operation and its two component actions without any fluff or repetition. Every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple, one-parameter tool with no output schema. The description fully conveys the purpose, actions, and target. For its complexity, it is complete. No missing information is critical for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (nodeId is described as 'The ID of the node to focus on'). The tool description repeats the same concept without adding extra syntax, format, or examples. Since the schema already documents the parameter well, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Set focus on a specific node in Figma by selecting it and scrolling viewport to it'. This distinguishes it from sibling tools like get_selection (read-only) and set_selections (likely only changes selection without scrolling). The verb+resource+scoping is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: use this tool when you need to focus a node by both selecting it and scrolling the viewport. However, there is no explicit when-not-to-use or comparison to alternatives like set_selections, which might also select nodes. The implied usage is strong but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It discloses that Inter is the default font family and implies that relying on defaults may not match design-system layers. This is useful for the agent to anticipate the tool's behavior. However, it does not mention the return value (e.g., the created node's ID) or any side effects beyond creating a node. Still, the default font and override guidance add meaningful 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences: the first states the core function, the second offers a focused tip. There is no redundant wording or restating of schema details. Every sentence earns its place, making it highly concise and well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (15 parameters) and lack of an output schema, the description is reasonably complete. It clearly states the action and provides a real-world workflow tip. It does not explain return values or interaction with parentId, but these are less central for a create operation. The detailed schema and the practical example compensate for missing context, though a brief note on what the tool returns would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers 100% of parameters with detailed descriptions, so the baseline is 3. The description adds value by identifying a specific subset of parameters (fontFamily, fontStyle, textAlignHorizontal, width, lineHeight) and explaining their combined purpose when matching a design-system layer. This strategic guidance helps the agent decide which parameters to set, going beyond the schema's individual property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a new text element in Figma,' using a specific verb and resource that clearly identifies the tool's function. It distinguishes itself from sibling tools like create_rectangle and set_text_content by focusing on text creation rather than other shapes or updates. The additional guidance about matching a design-system layer further clarifies its intended use.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear contextual guidance: when the goal is to match an existing design-system layer, set specific properties (fontFamily, fontStyle, textAlignHorizontal, width, lineHeight) rather than relying on Inter defaults. However, it does not explicitly state when to use this tool over alternatives like set_text_content, nor does it mention exclusions or prerequisites. This is strong context but lacks explicit alternative comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description transparently discloses that the tool is a stub, that the parameter is ignored, and that no plugin-based equivalent exists. This goes far beyond the annotations (readOnlyHint, openWorldHint) by explaining the underlying reason and expected behavior, which is crucial for an agent to avoid invoking it expecting results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, immediately starts with 'Stub', and packs essential information without any fluff. Every word contributes value, 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.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a stub tool with one parameter, no output schema, and read-only annotations, the description is fully complete. It covers the tool's unavailability, the cause, and the consequence, leaving no ambiguity about what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema description already covers the 'ignored' nature of fileKey at 100% coverage, the tool description adds rationale by explaining that the REST API is disabled. This gives the agent a deeper understanding of why the parameter is ignored, slightly elevating it above the schema-only baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states that this is a stub for reading Figma comments and that the REST API is disabled, making it clear the tool does not actually retrieve comments. It identifies the resource (Figma comments) and the tool's non-functional role, distinguishing it from working siblings like get_document_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool should not be used for actually getting comments because the required REST API is disabled, but it does not explicitly say 'when to use' or suggest alternatives like using the REST API outside this build. The guidance is clear enough to avoid false expectations, but no direct comparison to sibling tools is 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the server auto-joins the default channel on startup and that this tool is only a fallback. This is valuable context, though it doesn't mention edge cases like invalid channel names or side effects on the current channel.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence. It leads with the purpose ('Optional: switch...'), then adds conditional usage context. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description provides complete context: what it does, why it exists, and when to use it. The auto-join behavior and recovery scenario fully explain the tool's niche, leaving no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter, so the baseline is 3. The description adds some context (default channel name and recovery use case) but does not add new parameter-specific semantics beyond what the schema already states ('The name of the channel to join').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('switch') and resource ('Figma communication channel'), clearly distinguishing it from all sibling tools. It also clarifies the tool's role relative to the default channel, leaving no ambiguity about what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: the tool is optional, only needed for non-default channels or recovery after connection issues. It also explains the auto-join behavior, so the agent knows when to invoke it and when to avoid it. No alternatives are mentioned, but no real alternatives exist among sibling tools.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/mhue26/figma-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server