Enables programmatic interaction with Figma designs, providing tools for reading document structure, manipulating nodes, updating text with formatting preservation, managing auto-layout properties, creating connections and prototypes, handling annotations, and performing batch operations for design automation.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Figma Copilot replace all placeholder text in the selected frames with our new brand copy"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that enables AI assistants to interact with Figma designs programmatically. Compatible with any MCP client including Cursor, Claude Desktop, and other MCP-enabled applications. Features advanced text handling, batch operations, and comprehensive design automation capabilities.
This project is based on cursor-talk-to-figma-mcp by Sonny Lazuardi.
Related MCP server: Claude Talk to Figma MCP
This is an independent project and is not affiliated with, officially maintained, authorized, endorsed, or sponsored by Figma, Inc. All product and company names are trademarks™ or registered® trademarks of their respective holders.
Text Formatting Preservation - Text updates no longer lose formatting (bold, italic, colors, fonts). See Enhanced Text Operations Guide.
Batch Operations - 50-90% performance improvement for bulk operations. See Batch Operations Guide.
Enhanced Error Handling - Specific, actionable error messages with suggestions
Timeout Solutions - New scanning options with depth control and partial results
Smart Text Operations - Find/replace with formatting preservation
Fixed "Cannot unwrap symbol" error when working with mixed fonts. See Font Handling Documentation.
Improved font loading with getRangeAllFontNames() API
Better error handling with Promise.allSettled() for font loading
Safe value returns to avoid serialization issues
Enhanced logging for debugging font issues
src/talk_to_figma_mcp/ - TypeScript MCP server for Figma integration
src/figma_copilot_plugin/ - Figma plugin for communicating with MCP clients
src/socket.ts - WebSocket server that facilitates communication between the MCP server and Figma plugin
Install Bun if you haven't already:
curl -fsSL https://bun.sh/install | bashRun setup to configure MCP
bun setupStart the Websocket server
bun socketMCP server
bunx figma-copilotNEW Install Figma plugin from Figma community page or install locally
Video tutorials coming soon!
Bulk text content replacement
Thanks to @dusskapark for contributing the bulk text replacement feature.
Instance Override Propagation Another contribution from @dusskapark Propagate component instance overrides from a source instance to multiple target instances with a single command. This feature dramatically reduces repetitive design work when working with component instances that need similar customizations.
Based on real production usage with bulk infographic creation:
Operation | Before v0.3.2 | After v0.3.2 | Improvement |
Clone 20 nodes | 50 seconds | 5 seconds | 90% faster |
Update 112 text nodes | 15 minutes | 30 seconds | 96% faster |
Scan large document | Timeout after 30s | 3 seconds | No timeouts |
Text + formatting update | 2 separate calls | 1 combined call | 50% fewer API calls |
Add the server to your MCP client configuration. For example, in Cursor's ~/.cursor/mcp.json or Claude Desktop's configuration:
{
"mcpServers": {
"figma-copilot": {
"command": "bunx",
"args": ["figma-copilot@latest"]
}
}
}Start the WebSocket server:
bun socketIn Figma, go to Plugins > Development > New Plugin
Choose "Link existing plugin"
Select the src/figma_copilot_plugin/manifest.json file
The plugin should now be available in your Figma development plugins
Install bun via powershell
powershell -c "irm bun.sh/install.ps1|iex"Uncomment the hostname 0.0.0.0 in src/socket.ts
// uncomment this to allow connections in windows wsl
hostname: "0.0.0.0",Start the websocket
bun socketStart the WebSocket server
Install the MCP server in your MCP client
Open Figma and run the Figma Copilot Plugin
Connect the plugin to the WebSocket server by joining a channel using join_channel
Use your MCP client to communicate with Figma using the MCP tools
The MCP server provides the following tools for interacting with Figma:
get_document_info - Get information about the current Figma document
get_current_context - Get comprehensive context including selection, focused slide (if in Slides mode), and optionally document info
get_selectionget_current_context instead
read_my_design - Get detailed node information about the current selection without parameters
get_nodes - Get detailed information about one or more nodes (accepts single ID or array)
get_node_infoget_nodes with single node ID instead
get_nodes_infoget_nodes with array of node IDs instead
get_focused_slideget_current_context with includeSlideDetails option
get_slides_modeget_current_context with includeSlideDetails option
get_annotations - Get all annotations in the current document or specific node
set_annotation - Create or update an annotation with markdown support
set_multiple_annotations - Batch create/update multiple annotations efficiently
scan_nodes_by_types - Scan for nodes with specific types (useful for finding annotation targets)
get_reactions - Get all prototype reactions from nodes with visual highlight animation
set_default_connector - Set a copied FigJam connector as the default connector style for creating connections (must be set before creating connections)
create_connections - Create FigJam connector lines between nodes, based on prototype flows or custom mapping
create_rectangle - Create a new rectangle with position, size, and optional name
create_frame - Create a new frame with position, size, and optional name
create_text - Create a new text node with customizable font properties
scan_text_nodesscan_nodes_with_options with nodeTypes: ['TEXT'] instead
scan_nodes_with_options - Enhanced scanning with depth control, timeout handling, and partial results
set_text_content - Set the text content of a single text node (Note: loses formatting)
set_multiple_text_contents - Batch update multiple text nodes efficiently (Note: loses formatting)
See Enhanced Text Operations Guide for an overview.
update_text_preserve_formatting - Update text while preserving all character formatting (bold, italic, colors, fonts)
smart_text_replace - Find and replace text while preserving formatting of unchanged portions
set_multiple_text_contents_with_styles - Batch update text with formatting in a single operation
See Text Styling Guide for detailed usage.
set_text_style_range - Apply text styling (bold, italic, underline, strikethrough) to specific character ranges
get_text_style_range - Get text styling for a specific range
set_text_decoration_range - Set advanced text decoration properties
get_text_decoration_range - Get text decoration properties for a range
set_range_font - Change font family and style for a text range
set_range_font_size - Change font size for a text range
set_range_fills - Set text color for a specific range
get_styled_text_segments - Get detailed information about text segments and their properties
set_component_description - Set component description using Markdown
get_component_description - Get component description in Markdown format
normalize_markdown - Normalize Markdown text to Figma's supported subset
set_layout_mode - Set the layout mode and wrap behavior of a frame (NONE, HORIZONTAL, VERTICAL)
set_padding - Set padding values for an auto-layout frame (top, right, bottom, left)
set_axis_align - Set primary and counter axis alignment for auto-layout frames
set_layout_sizing - Set horizontal and vertical sizing modes for auto-layout frames (FIXED, HUG, FILL)
set_item_spacing - Set distance between children in an auto-layout frame
set_fill_color - Set the fill color of a node (RGBA)
set_stroke_color - Set the stroke color and weight of a node
set_corner_radius - Set the corner radius of a node with optional per-corner control
move_node - Move a node to a new position
resize_node - Resize a node with new dimensions
delete_node - Delete a node
delete_multiple_nodes - Delete multiple nodes at once efficiently
clone_node - Create a copy of an existing node with optional position offset
See Batch Operations Guide for best practices.
clone_multiple_nodes - Clone a node to multiple positions in one operation (50-90% faster than individual clones)
get_multiple_nodes_infoget_nodes with array of node IDs instead
set_multiple_nodes_property - Set the same property value on multiple nodes at once
execute_batch - Execute multiple different commands in sequence with a single round-trip
get_connection_status - Get current connection status and statistics
get_styles - Get information about local styles
get_local_components - Get information about local components
create_component_instance - Create an instance of a component
get_instance_overrides - Extract override properties from a selected component instance
set_instance_overrides - Apply extracted overrides to target instances
extract_slide_content - Extract all content from a Figma slide including text, tables, and optionally images (supports raw or structured output)
get_presentation_summary - Generate an overview of a Figma presentation including slide count, slide titles, and optionally an outline summarizing key points
get_table_data - Extract data from a Figma table node in various formats (array, object, or CSV) with customizable header handling
export_node_as_image - Export a node as an image (PNG, JPG, SVG, or PDF) - limited support on image currently returning base64 as text
join_channel - Join a specific channel to communicate with Figma
The MCP server includes several helper prompts to guide you through complex design tasks:
design_strategy - Best practices for working with Figma designs
read_design_strategy - Best practices for reading Figma designs
text_replacement_strategy - Systematic approach for replacing text in Figma designs
annotation_conversion_strategy - Strategy for converting manual annotations to Figma's native annotations
swap_overrides_instances - Strategy for transferring overrides between component instances in Figma
reaction_to_connector_strategy - Strategy for converting Figma prototype reactions to connector lines using the output of 'get_reactions', and guiding the use 'create_connections' in sequence
batch_operations_guide - Best practices for efficient bulk operations in Figma (v0.3.2)
error_recovery_guide - How to handle common errors and timeouts in Figma operations (v0.3.2)
text_formatting_guide - Best practices for updating text while preserving formatting (v0.3.2)
Navigate to the Figma plugin directory:
cd src/figma_copilot_pluginEdit code.js and ui.html
When working with the Figma MCP:
Always join a channel before sending commands
Get document overview using get_document_info first
Check current context with get_current_context before modifications
Use appropriate creation tools based on needs:
create_frame for containers
create_rectangle for basic shapes
create_text for text elements
Verify changes using get_node_info
Use component instances when possible for consistency
Handle errors appropriately as all commands can throw exceptions
For large designs:
Use scan_nodes_with_options with appropriate timeout and depth settings
Monitor progress through WebSocket updates
Implement appropriate error handling
For text operations:
Use batch operations when possible
Consider structural relationships
Verify changes with targeted exports
For converting legacy annotations:
Scan text nodes to identify numbered markers and descriptions
Use scan_nodes_by_types to find UI elements that annotations refer to
Match markers with their target elements using path, name, or proximity
Categorize annotations appropriately with get_annotations
Create native annotations with set_multiple_annotations in batches
Verify all annotations are properly linked to their targets
Delete legacy annotation nodes after successful conversion
Visualize prototype noodles as FigJam connectors:
Use get_reactions to extract prototype flows,
set a default connector with set_default_connector,
and generate connector lines with create_connections for clear visual flow mapping.
If you encounter "Cannot unwrap symbol" errors when updating text, this is likely due to mixed fonts in text nodes. See Font Handling Documentation for details on how the plugin handles mixed fonts and available strategies.
For large documents that cause timeouts, use scan_nodes_with_options with depth limiting and partial results. See Batch Operations Guide for optimization strategies.
Batch Operations Guide - Learn how to use batch operations for massive performance gains
Enhanced Text Operations Guide - Preserve formatting while updating text
Text Styling Guide - Apply and manage text styles
Font Handling Documentation - Handle mixed fonts and font loading strategies
Changelog v0.3.2 - Latest release notes
MIT
Clone a node to multiple positions in one operation. Significantly faster than multiple individual clone operations.
| Name | Required | Description | Default |
|---|---|---|---|
| parentId | No | Parent node ID for all clones (optional) | |
| positions | Yes | Array of positions where clones should be placed | |
| sourceNodeId | Yes | The ID of the node to clone |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It indicates a mutation operation (creating clones) but omits details about permissions, error states, or side effects. The description is minimal and lacks depth 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loading the core purpose and key benefit. Every word adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 parameters, no output schema, no annotations), the description provides basic context but lacks details on parameter behavior (e.g., parentId optionality) and explicit relation to sibling clone_node. It is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with clear descriptions for all three parameters (sourceNodeId, positions, parentId). The description does not add new information beyond the schema, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action (clone), the resource (node), and the scope (multiple positions in one operation), clearly distinguishing it from the sibling clone_node tool which clones to a single position.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the primary use case by highlighting that it is faster than multiple individual clone operations, which suggests using this tool for batch cloning. However, it does not explicitly exclude other scenarios or mention alternatives besides the implied individual clone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clone an existing node in Figma
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | New X position for the clone | |
| y | No | New Y position for the clone | |
| nodeId | Yes | The ID of the node to clone |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It fails to mention side effects, whether original node is modified, permissions required, or what happens to children/styles. The single sentence provides zero 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence), which is concise but lacks necessary detail. It is not structured to front-load key information, and the brevity undermines completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters and no output schema or annotations. The description does not explain the return value, whether the clone is created in-place, or how it relates to existing nodes. It is insufficient 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The description adds no additional meaning beyond the schema; it does not explain coordinate context or how cloning interacts with parameters. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'clone' and resource 'node', making the basic action clear. However, it does not differentiate from other node manipulation tools like 'create_component_instance' or 'move_node', leaving ambiguity about what cloning entails (e.g., deep copy, children).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'duplicate' or 'copy/paste'. No mention of prerequisites, context, or exclusions. The description offers no help in decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create an instance of a component in Figma
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | X position | |
| y | Yes | Y position | |
| componentKey | Yes | Key of the component to instantiate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided and the description does not disclose any behavioral traits beyond the basic action. Missing details on side effects (e.g., does it replace selection?), error conditions (invalid componentKey), or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is easy to parse. It could include more structured behavioral hints without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a moderate number of sibling tools, the description is too minimal. It does not explain coordinate system, what 'component' means (master component), or how the instance is placed (e.g., relative to current selection or page origin).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no extra meaning beyond what the schema already provides. Baseline 3 is appropriate; no bonus for additional context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates an instance of a component in Figma, with a specific verb and resource. However, it does not explicitly differentiate from sibling tools like 'clone_node' which might create instances from existing nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as clone_node or create_rectangle. The description does not mention prerequisites, context (e.g., selection), or when it's appropriate to instantiate a component.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create connections between nodes using the default connector style
| Name | Required | Description | Default |
|---|---|---|---|
| connections | Yes | Array of node connections to create |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It only states creation with default style but does not mention error handling, what happens on duplicate connections, or the impact of missing nodes. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every word contributes to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one array parameter), the description is adequate but lacks details on return values or side effects. No output schema exists, so completeness is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents parameter structure. The description adds no extra meaning beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates connections between nodes using the default connector style. The verb 'create' and resource 'connections' are specific, and it distinguishes from sibling tools like create_rectangle or clone_node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when connecting nodes but does not provide explicit guidance on when to use versus alternatives, such as set_default_connector for styling. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new frame in Figma
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | X position | |
| y | Yes | Y position | |
| name | No | Optional name for the frame | |
| width | Yes | Width of the frame | |
| height | Yes | Height of the frame | |
| parentId | No | Optional parent node ID to append the frame to | |
| fillColor | No | Fill color in RGBA format | |
| layoutMode | No | Auto-layout mode for the frame | |
| layoutWrap | No | Whether the auto-layout frame wraps its children | |
| paddingTop | No | Top padding for auto-layout frame | |
| itemSpacing | No | Distance between children in auto-layout frame. Note: This value will be ignored if primaryAxisAlignItems is set to SPACE_BETWEEN. | |
| paddingLeft | No | Left padding for auto-layout frame | |
| strokeColor | No | Stroke color in RGBA format | |
| paddingRight | No | Right padding for auto-layout frame | |
| strokeWeight | No | Stroke weight | |
| paddingBottom | No | Bottom padding for auto-layout frame | |
| layoutSizingVertical | No | Vertical sizing mode for auto-layout frame | |
| counterAxisAlignItems | No | Counter axis alignment for auto-layout frame | |
| primaryAxisAlignItems | No | Primary axis alignment for auto-layout frame. Note: When set to SPACE_BETWEEN, itemSpacing will be ignored as children will be evenly spaced. | |
| layoutSizingHorizontal | No | Horizontal sizing mode for auto-layout frame |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only indicates creation, but fails to disclose any behavioral traits such as required context (e.g., existing document), default values, or what happens when optional parameters are omitted. With no annotations provided, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but overly minimal for a complex tool with 20 parameters. It lacks any structured detail or front-loading of key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (20 parameters, nested objects) and lack of output schema, the description does not provide sufficient context about default behavior, error conditions, or expected outcomes, making it incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter already has a description. The tool description adds no additional semantics or constraints beyond the schema, resulting in a baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new frame in Figma'), but it does not differentiate this tool from siblings like create_rectangle or create_text, which could be confusing for the agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or context (e.g., whether a parent page is needed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a GIF (available in Figma Slides and FigJam)
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | X position | |
| y | No | Y position | |
| url | Yes | URL of the GIF | |
| name | No | Name of the GIF | |
| width | No | Width | |
| height | No | Height | |
| parentId | No | Parent node ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It only states the purpose and availability, but does not disclose what happens during creation (e.g., return value, side effects, validation of URL, size constraints).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is single sentence with no wasted words. It is front-loaded with purpose. However, it is so brief that it sacrifices informativeness, slightly below ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool creates a GIF but lacks output schema, so the description should explain return behavior. With 69 sibling tools and no output schema, more details are needed for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documentation covers 100% of parameters with descriptions (x, y, url, name, width, height, parentId). The description adds no additional meaning beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a GIF') and the resource ('GIF'). It also provides context on availability (Figma Slides and FigJam). However, it does not differentiate this tool from siblings like 'create_frame' or 'create_rectangle', which are also creation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. No prerequisites, when-not-to-use, or context for when a GIF creation is appropriate are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new rectangle in Figma
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | X position | |
| y | Yes | Y position | |
| name | No | Optional name for the rectangle | |
| width | Yes | Width of the rectangle | |
| height | Yes | Height of the rectangle | |
| parentId | No | Optional parent node ID to append the rectangle to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states 'Create a new rectangle', which implies a mutation, but omits details like side effects, required permissions, or what happens on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that immediately conveys the tool's purpose with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 6 parameters and no output schema or annotations, the description adds no additional context such as return values, constraints, or behavior for complex inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds no extra meaning beyond what the schema already provides. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Create', the resource 'rectangle', and the context 'in Figma'. It is specific enough to distinguish from sibling tools like create_frame or create_shape_with_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, no exclusions, and no examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a shape with text (available in Figma Slides and FigJam)
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | X position | |
| y | No | Y position | |
| name | No | Name of the shape | |
| text | No | Text content | |
| width | No | Width | |
| height | No | Height | |
| fontSize | No | Font size | |
| parentId | No | Parent node ID | |
| fillColor | No | Fill color | |
| fontColor | No | Text color | |
| shapeType | No | Shape type (e.g., RECTANGLE, ELLIPSE) | |
| fontWeight | No | Font weight | |
| strokeColor | No | Stroke color | |
| strokeWeight | No | Stroke weight |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only mentions the basic function and availability, but does not explain important behaviors such as whether the shape is created on the current page, how text is handled (e.g., overflow, alignment), or if any default values apply. The description carries the full burden but falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, perfectly concise and front-loaded. Every word earns its place, with no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 14 parameters (including nested objects) and no output schema, the description provides no details on default behavior, prerequisites, or return values. It does not clarify how the shape and text are combined, what happens if parentId is omitted, or if there are any constraints. For a tool of this complexity, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning all 14 parameters have descriptions in the schema. The description does not add additional meaning beyond the schema; it only restates the tool's purpose. Per guidelines, high coverage sets a baseline of 3, and no extra value is provided beyond that baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a shape with text'), identifies the resource (a shape with text), and adds context about availability in Figma Slides and FigJam, which helps differentiate from potentially similar tools. The verb is specific and the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like create_rectangle or create_text. With many sibling tools that create shapes or text separately, the lack of usage context (e.g., 'Use this to create a shape with embedded text in one step') is a notable gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new slide in Figma Slides
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional name for the slide | |
| parentId | No | Optional parent SLIDE_ROW ID to append the slide to | |
| fillColor | No | Fill color in RGBA format | |
| strokeColor | No | Stroke color in RGBA format | |
| strokeWeight | No | Stroke weight |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It merely states the action without mentioning side effects, required permissions, or what happens if no parameters are provided. This is insufficient for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence, front-loading the essential action. However, it may be too brief, omitting necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and five optional parameters, the description is incomplete. It does not explain return values, default behavior, or any constraints, leaving the agent without critical context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to add much. The parameters are well-documented in the schema, and the description adds no extra meaning. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new slide in Figma Slides' clearly states the action (create) and the resource (slide), making the purpose apparent. However, it does not differentiate from sibling tools like create_slide_row, which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as create_slide_row for creating rows. There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new slide row in Figma Slides
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Optional name for the slide row | |
| parentId | No | Optional parent node ID to append the slide row to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only states 'Create' (implying mutation) but does not mention side effects, permissions, or what happens if parentId is omitted. Lacks transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it lacks structure and potentially useful front-loaded details. It is minimal but not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 optional parameters, no output schema, and no annotations, the description is too brief. It does not explain the concept of a slide row, the effect of the operation, or what constitutes success, making it incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both 'name' and 'parentId'. The tool description adds no additional meaning beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('slide row in Figma Slides'), distinguishing it from sibling tools like create_slide or create_frame. However, it doesn't elaborate on what a slide row is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., create_slide, create_frame). No explicit context, 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.
Create a table (available in Figma Design and Slides)
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | X position | |
| y | No | Y position | |
| name | No | Name of the table | |
| rows | No | Number of rows | |
| columns | No | Number of columns | |
| parentId | No | Parent node ID | |
| cellWidth | No | Width of each cell | |
| cellHeight | No | Height of each cell |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavior. It simply states 'Create a table' without indicating side effects, destructive nature, permission requirements, or output. The agent cannot assess risks or invariants.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core purpose. It is efficiently structured with no superfluous text, though additional details could be added without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8 parameters, no annotations, no output schema), the description is insufficient. It does not explain the return value, dependency on parentId, behavior differences between Design and Slides, or how parameters like cellWidth/cellHeight affect the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 8 parameters have schema descriptions (100% coverage), so the schema already defines their meaning. The tool description adds no additional semantic context beyond the schema, which is adequate but does not elevate the score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a table') and specifies the context ('available in Figma Design and Slides'), which distinguishes it from sibling tools like create_frame or create_shape_with_text. However, it lacks a definition of what a table is (e.g., a grid of cells).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use create_table versus alternatives such as create_frame or create_text. The description does not mention prerequisites, limitations, or contextual cues for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new text element in Figma
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | X position | |
| y | Yes | Y position | |
| name | No | Semantic layer name for the text node | |
| text | Yes | Text content | |
| fontSize | No | Font size (default: 14) | |
| parentId | No | Optional parent node ID to append the text to | |
| fontColor | No | Font color in RGBA format | |
| fontWeight | No | Font weight (e.g., 400 for Regular, 700 for Bold) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'Create', omitting critical details like permissions, effect on selection, return value, or whether the element is appended to a specific parent (despite the optional parentId parameter).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys the core purpose without extraneous information. It is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no output schema, and no annotations, the description is insufficient. It does not explain return behavior, side effects, or contextual requirements like whether the text is created in the current document or frame.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds no extra meaning beyond the schema, earning the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool creates a new text element in Figma, specifying the verb 'Create' and the resource 'text element'. This distinguishes it from sibling tools like create_rectangle or create_frame.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or relative scenarios compared to similar tools like set_text_content or update_text_preserve_formatting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete multiple nodes from Figma at once
| Name | Required | Description | Default |
|---|---|---|---|
| nodeIds | Yes | Array of node IDs to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says 'delete' without detailing destructive nature, reversibility, or edge cases (e.g., non-existent nodes). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy. Efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Functionally complete for a simple delete operation, but lacks behavioral details and usage guidance that would help an agent choose this tool appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with description for 'nodeIds'. The tool description adds no extra meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete' and resource 'multiple nodes', and 'from Figma at once' adds scope. It distinguishes from sibling 'delete_node'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like delete_node, no prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a node from Figma
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | The ID of the node to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose any behavioral details beyond the fact of deletion. It omits information about irreversibility, side effects on children, permissions needed, or what happens on success/failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence). It earns its place but could be more informative without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and minimal description, the tool lacks completeness. It doesn't explain what the tool returns, error handling, or any post-deletion behavior, making it insufficient for a destructive action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of the single parameter (nodeId) with a clear description. The tool description adds no extra meaning beyond what the schema already provides, so score is at baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a node from Figma' clearly states the verb (delete) and resource (Figma node). It is straightforward and the name itself distinguishes it from the sibling 'delete_multiple_nodes', though explicit differentiation would improve it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'delete_multiple_nodes'. No prerequisites, conditions, or context for when deletion is appropriate are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute multiple commands in sequence with a single round-trip. Ideal for complex operations that require multiple steps.
| Name | Required | Description | Default |
|---|---|---|---|
| commands | Yes | Array of commands to execute in sequence | |
| stopOnError | No | Stop execution if a command fails (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'execute multiple commands in sequence' and 'single round-trip' but does not disclose important behavioral traits such as partial execution on failure, order guarantees, or side effects. The existence of 'stopOnError' is not mentioned in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the main action. No wasted words, and the key benefit (single round-trip) is mentioned early. Despite its brevity, it covers the core purpose effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's batch execution nature and lack of output schema, the description is insufficient. It does not explain what 'commands' refer to (e.g., names of other tools), how errors are handled, or what the return value is. The agent lacks enough context to use it correctly without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does 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 no additional meaning beyond what the schema already provides for the parameters. It does not explain the relationship between commands or what valid command values are.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it executes multiple commands in sequence with a single round-trip, which is a specific verb+resource. It also mentions it's ideal for complex operations with multiple steps. However, it doesn't explicitly differentiate from sibling tools like 'clone_multiple_nodes' or 'delete_multiple_nodes', which also handle multiple steps but are more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only says 'Ideal for complex operations that require multiple steps,' implying when to use, but provides no guidance on when not to use or what alternatives exist. It does not mention trade-offs like error handling or atomicity, which are crucial for batch operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export a node as an image from Figma
| Name | Required | Description | Default |
|---|---|---|---|
| scale | No | Export scale | |
| format | No | Export format | |
| nodeId | Yes | The ID of the node to export |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fails to disclose behavioral aspects such as whether the export is read-only, what happens to the node, or the format of the output (e.g., file download vs. URL). This lack of detail reduces transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that is concise and contains no wasted words. It efficiently conveys the core action, though it could be slightly more informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks details about the return value, such as whether it returns image data or a URL. Given the absence of an output schema and the tool's complexity (multiple format options, scale), the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does 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). The tool description adds no additional semantic meaning beyond the schema, so it meets the baseline but does not improve comprehension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Export' and resource 'node' with output 'image from Figma', effectively distinguishing it from siblings like clone_node or create_gif. However, it adds little beyond the tool's name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any prerequisites or exclusion criteria. The description provides no context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract all content from a Figma slide including text, tables, and optionally images
| Name | Required | Description | Default |
|---|---|---|---|
| slideId | Yes | ID of the slide to extract content from | |
| textOnly | No | Extract only text content, skip tables and images (default: false) | |
| outputFormat | No | Output format: raw text or structured JSON (default: structured) | |
| includeImages | No | Include image data in extraction (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It does not disclose behavioral traits such as read-only nature, performance implications, error handling, or prerequisites like slide existence. Merely stating 'extract' is insufficient for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It captures the essential purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should explain what the tool returns and in what format. It does not mention return structure, success indicators, or how the outputFormat parameter affects results. Incomplete for a tool with four parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters thoroughly. The description adds high-level context ('including text, tables, and optionally images') but does not directly enhance understanding of parameters like outputFormat or includeImages beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'extract' and resource 'content from a Figma slide including text, tables, and optionally images'. It distinguishes itself from sibling tools like get_table_data or get_node_info by targeting comprehensive extraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like get_table_data, get_annotations, or get_node_info. The description lacks when-not-to-use or context for choosing between this and similar extraction tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all annotations in the current document or specific node
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | No | Optional node ID to get annotations for specific node | |
| includeCategories | No | Whether to include category information |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states 'Get all annotations', implying a read operation but lacks details on side effects, performance, or return format. This is minimal and does not add value 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no superfluous words. It front-loads the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity, the description does not explain the return format, pagination, or how it differs from similar get tools (e.g., get_node_info). Without an output schema, this is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters documented. The description does not add any meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get' and the resource 'annotations', and specifies the scope as 'current document or specific node'. It effectively distinguishes from sibling tools like set_annotation and set_multiple_annotations which are write operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use this tool (to get annotations) and hints at variability by node, but does not explicitly contrast with similar read tools like get_reactions or provide exclusion criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the description of a component in Markdown format
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | The ID of the component node |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, idempotency, or error handling. While the tool is a getter, the lack of explicit transparency 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. Every part is essential and efficiently conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the output format (Markdown) but does not mention what happens if the nodeId is invalid or if the component has no description. Given the tool's simplicity, these omissions reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter 'nodeId' with a clear description. The tool description does not add additional parameter meaning, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a component description and specifies the output format (Markdown). It uses a specific verb and resource, and distinguishes itself from the sibling tool 'set_component_description'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for reading a component's description, but it does not provide explicit guidance on when to use it versus alternatives like 'set_component_description'. No context on prerequisites or exclusions is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current connection status and statistics for the Figma plugin connection
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It implies a read operation but does not explicitly state read-only, auth needs, or any side effects. For a simple get, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, completely clear, no unnecessary words. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description is minimal but sufficient for a simple status retrieval. Could mention return format, but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (schema coverage 100%), so baseline 4 applies. Description adds no parameter info, but no info needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'connection status and statistics', distinguishing it from sibling tools that deal with nodes, text, or other operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. However, since siblings are all different, it's implicitly clear that this is for connection status checks, but lacks when-not-to-use or alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive context about the current state including selection, focused slide (if in Slides mode), and optionally document info
| Name | Required | Description | Default |
|---|---|---|---|
| includeDocument | No | Include document information (default: false) | |
| includeSlideDetails | No | Include detailed slide information if in Slides mode (default: true) | |
| includeSelectionDetails | No | Include detailed selection information (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the main components returned (selection, slide, document info) but does not mention performance implications, read-only nature, or other behavioral traits. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose with specific detail. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, yet the description only vaguely mentions what is included. It lacks details on the return format or structure, which is necessary for an AI agent to understand what to expect. More information about the response would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds context about the overall purpose but does not explicitly map parameters to aspects beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns comprehensive context about the current state, mentioning selection, focused slide (in Slides mode), and optional document info. This distinguishes it from more specific sibling tools like get_selection or 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for broad state retrieval but does not explicitly state when to use this tool over alternatives or when not to use it. 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.
Get detailed information about the current Figma document
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'detailed information' without specifying what that includes, and fails to mention side effects, auth requirements, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no extraneous words, efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, description is adequate but lacks detail on what 'detailed information' entails. Could be more explicit about return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, and schema coverage is 100%. Baseline per rules is 4; description adds no parameter info but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and resource 'Figma document', with 'current' narrowing scope. It distinguishes from sibling tools like get_node_info or get_selection by focusing on the overall document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention prerequisites, when to avoid it, or provide context for selecting it over other 'get' tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[DEPRECATED] Get the currently focused slide in Figma Slides. Use 'get_current_context' instead.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the function without detailing any behavioral traits, side effects, or return value. For a simple getter, this is minimal but still lacks clarity on what 'focused slide' means.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with deprecation marker and replacement, no wasted words. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deprecated tool with no parameters and no output schema, the description is sufficient: it states purpose and alternative. However, it lacks details on the return format or what 'focused' means, though this is mitigated by the deprecation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description does not add parameter information, but none is needed. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the currently focused slide, explicitly marks it as deprecated, and provides a replacement. This fully communicates purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly directs users to use 'get_current_context' instead, providing unambiguous guidance on 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.
Get all override properties from a selected component instance. These overrides can be applied to other instances, which will swap them to match the source component.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | No | Optional ID of the component instance to get overrides from. If not provided, currently selected instance will be used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that overrides can be applied elsewhere, but does not describe other behaviors like idempotency, authentication, or side effects. For a read operation, it is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant information. The purpose is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not describe the return format or structure of the override properties. This leaves the agent uncertain about what data to expect. For a getter, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description repeats the schema's description for nodeId verbatim, adding no new semantics beyond what the schema already provides. With 100% schema coverage, baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves override properties from a component instance, using 'Get all override properties' as the verb-resource pair. It distinguishes from sibling set_instance_overrides by focusing on reading rather than writing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for applying overrides to other instances, but does not explicitly state when to avoid or alternatives. Sibling tools include set_instance_overrides which is complementary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all local components from the Figma document
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 only states what it returns without mentioning side effects, permissions, rate limits, or output nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with no unnecessary words. It is front-loaded and immediately informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (0 params, no output schema), the description is adequate but lacks details about the output format (e.g., list of IDs or objects). It could be more complete for an agent to understand the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters (100% coverage), so per guidelines the baseline is 4. The description adds no parameter details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('all local components') from the Figma document. It is specific and easily distinguishes from sibling tools like get_component_description or get_annotations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks any when-to-use, when-not-to-use, or contextual hints for agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[DEPRECATED] Get information for multiple nodes in a single request. Use 'get_nodes' instead.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeIds | Yes | Array of node IDs to get information for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavioral traits like read-only nature. 'Get information' implies reading but does not explicitly state it is a read operation or mention any auth, rate limits, or side effects. Minimal but acceptable for a deprecated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with the deprecation warning front-loaded, followed by the purpose. Every character earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given 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) and deprecation status, the description is sufficient. It lacks return-value details but is complete enough for a deprecated tool that users should avoid.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds no additional meaning beyond the schema's parameter description. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves information for multiple nodes and explicitly marks it as deprecated, directing users to 'get_nodes' instead. This distinguishes it from siblings like 'get_node_info' and 'get_nodes'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly advises using 'get_nodes' instead, providing clear when-not-to-use guidance and an alternative. This is perfect for a deprecated tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[DEPRECATED] Get detailed information about a specific node in Figma. Use 'get_nodes' instead.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | The ID of the node to get information about |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'Get detailed information' without revealing any behavioral traits (e.g., read-only, error conditions, rate limits). The deprecation note is about usage, not behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and front-loads the important deprecation notice. It is efficient but could include slightly more detail about the information returned without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deprecated tool with one parameter and no output schema, the description is largely complete: it states the deprecation and alternative. However, it doesn't explain what 'detailed information' entails, which could be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter `nodeId` is described in the schema with a clear purpose. The description adds no extra meaning beyond what the schema already provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool gets detailed information about a specific node in Figma, and distinguishes it from sibling `get_nodes` by marking it as deprecated. The verb 'Get' and resource 'node info' are clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit deprecation warning and directly tells the agent to use `get_nodes` instead, providing clear when-not-to-use and alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about one or more nodes in Figma. Accepts either a single node ID or array of IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeIds | Yes | Node ID(s) to retrieve - can be a single string ID or an array of string IDs | |
| maxDepth | No | Maximum depth for child traversal (-1 for unlimited, default: -1) | |
| includeChildren | No | Whether to include child nodes (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'detailed information' but does not disclose behavioral traits like read-only nature, rate limits, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters and no output schema, the description is adequate but could benefit from explaining what 'detailed information' includes or any performance considerations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%. The description adds little beyond the schema, which already explains the nodeIds parameter. It does not provide deeper semantic context for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'nodes', and specifies it accepts single or multiple IDs. However, it does not differentiate from sibling tools like get_node_info or get_nodes_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_node_info or get_nodes_info. It only states the function without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[DEPRECATED] Get detailed information about multiple nodes in Figma. Use 'get_nodes' instead.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeIds | Yes | Array of node IDs to get information about |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses deprecation but no other behavioral traits like read-only nature or required permissions. For a simple get operation, this is acceptable but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words: deprecation notice, function, and alternative. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is deprecated, the description adequately tells the agent to avoid it and use the replacement. Lack of output schema or return value details is mitigated by the deprecation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as the only parameter 'nodeIds' has a description. Description adds no extra meaning beyond the schema, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it gets detailed information about multiple nodes in Figma, and explicitly marks as deprecated with direction to replacement 'get_nodes', distinguishing it from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs the agent not to use this tool and to use 'get_nodes' instead, providing a clear alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an overview of a Figma presentation including slide count, slide titles, and optionally an outline summarizing key points
| Name | Required | Description | Default |
|---|---|---|---|
| includeOutline | No | Include an outline with key points from each slide (default: true) | |
| maxTextPreview | No | Maximum characters of text to include per slide in outline (default: 200) | |
| includeEmptySlides | No | Include slides with no content in the summary (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the output components but does not state that the tool is read-only (likely safe), does not mention performance limits, error conditions, or how the outline is generated. Partial transparency, adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the main action, and contains no superfluous words. It efficiently conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately lists what the tool returns: slide count, titles, and optionally an outline. It could mention return format or limits but is sufficient for a tool with few parameters and no nested objects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter described. The description adds no new meaning beyond what is in the schema (e.g., default values already present). Baseline 3 is appropriate; no extra value but no deficiency.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'generate' and specific resource 'overview of a Figma presentation', clearly stating that the tool returns slide count, titles, and optionally an outline. This distinguishes it from sibling tools like 'extract_slide_content' or 'get_slide_grid'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for getting a summary but provides no explicit guidance on when to use it versus alternatives, nor any exclusions or prerequisites. The context is implied but not directly addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Figma Prototyping Reactions from multiple nodes. CRITICAL: The output MUST be processed using the 'reaction_to_connector_strategy' prompt IMMEDIATELY to generate parameters for connector lines via the 'create_connections' tool.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeIds | Yes | Array of node IDs to get reactions from |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral load. It discloses the critical dependency on post-processing but does not reveal side effects, idempotency, or authentication requirements. Partial transparency is achieved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences; the first is concise, the second provides crucial workflow instruction. Slightly verbose due to the imperative second sentence, but appropriate for the context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given 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), the description covers the core action and mandatory downstream step. It omits details like output structure or limits, but these may be inferred from the required prompt.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter. The schema description already defines 'Array of node IDs to get reactions from'. The tool description adds no additional parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'Figma Prototyping Reactions from multiple nodes'. It distinguishes itself effectively from sibling tools, as no other tool retrieves reactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to immediately process the output with a specific prompt and tool, providing clear post-processing guidance. However, it does not mention scenarios where the tool should or should not be used relative to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[DEPRECATED] Get information about the current selection in Figma. Use 'get_current_context' instead.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool is deprecated, which is a key behavioral trait, but does not describe what happens when called (e.g., still works, returns error, or returns stale data). This partial disclosure earns a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal, consisting of two short sentences. The deprecation note is front-loaded, making the critical fact immediately visible. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema) and its deprecated status, the description is fully complete. It tells the agent everything needed: what it did, that it's deprecated, and what to use instead.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is fully covered. The description adds no parameter information, which is appropriate since none exist. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get information about the current selection in Figma.' The deprecation tag distinguishes it from active tools, and the alternative 'get_current_context' is explicitly named, providing clear differentiation from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs not to use this tool due to deprecation and directs to 'get_current_context' as the replacement. This provides perfect guidance on when and when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current slide grid arrangement in Figma Slides
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only states a read operation without disclosing side effects, permission requirements, or details about what 'grid arrangement' includes (e.g., rows, columns, spacing).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no redundancy, ideal for a simple parameterless tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (no parameters, no output schema), the description is minimal but fails to explain the return value or any prerequisites. Sibling tools like get_slide_transition likely have similar brevity, but this lacks important details about the output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and the description adds no extra meaning beyond the schema. Since there are no parameters to document, a baseline of 4 is appropriate, though additional context about the output could have been provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Get' and the resource 'current slide grid arrangement' in the context of Figma Slides. It accurately conveys the tool's function and distinguishes it from siblings like set_slide_grid.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it does not mention that this should be used before set_slide_grid to inspect current settings or that it is read-only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[DEPRECATED] Get the current viewport mode in Figma Slides. Use 'get_current_context' instead.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. The description indicates it is a read operation ('Get') and states deprecation, implying it may be removed or unsupported. It does not describe side effects or permissions, but for a simple getter the behavioral insight is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single informative sentence plus a deprecation warning. The '[DEPRECATED]' tag is front-loaded, instantly informing the agent. No redundant words; every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description adequately covers functionality and deprecation. However, it could improve by briefly describing the return format (e.g., 'returns a string mode'), but the deprecation makes this less critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters (100% schema coverage by default), so the description does not need to add parameter meaning. Baseline score of 4 applies for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: getting the current viewport mode in Figma Slides. It distinguishes itself from sibling tools by explicitly declaring deprecation and recommending 'get_current_context' as a replacement, providing unambiguous purpose differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns that the tool is deprecated and instructs the agent to use 'get_current_context' instead. This provides clear when-to-use and when-not-to-use guidance, with a direct alternative named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the transition settings for a slide in Figma Slides
| Name | Required | Description | Default |
|---|---|---|---|
| slideId | Yes | The ID of the slide |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fails to disclose behavioral traits. It only states it 'gets' transition settings but omits details like whether it returns default settings if none are set, error conditions, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the action and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter, the description is adequate but lacks information about the return value or any default behavior, especially since there is no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the description adds no extra meaning beyond the schema. Baseline score of 3 is appropriate as per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'transition settings for a slide in Figma Slides', which is specific and distinct from sibling tools like set_slide_transition or get_slide_grid.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as when to retrieve settings vs. modify them. The description is silent on usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed text segments with all their styling properties
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | Optional end index | |
| start | No | Optional start index | |
| fields | Yes | Text properties to retrieve | |
| nodeId | Yes | The ID of the text node |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states only the basic function, with no mention of read-only nature, performance implications, or required permissions. Minimal transparency beyond the core action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no wasted words. It achieves clarity but lacks structure; a brief list or additional context could improve it without significant bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no sibling differentiation, the description omits critical context: what a 'text segment' is, how start/end indices relate to segments, and the return format. The tool's role among 70+ siblings is unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds little beyond, repeating 'styling properties' without explaining key parameters like 'start' and 'end' indices. The agent must infer their meaning from the schema descriptions, which are brief. The description adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it retrieves text segments with styling properties, matching the tool's name. However, it says 'all their styling properties' while the schema requires a 'fields' parameter to select specific properties, creating slight ambiguity. It does not distinguish from siblings like 'get_text_style_range' or 'get_text_decoration_range'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus related siblings such as 'get_text_style_range', 'get_text_decoration_range', or 'scan_text_nodes'. The agent receives no context about appropriate use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all styles from the current Figma document
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, performance considerations, or required permissions. It only states the action without elaboration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential purpose without any wasted words. It is highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description leaves ambiguity about what 'styles' entails (e.g., names, properties, references). It provides the bare minimum context for a no-parameter tool but could be improved by clarifying the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since there are no parameters, the schema coverage is complete, and the description does not need to add parameter details. It implicitly defines the scope (current document) which adds context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets all styles from the current Figma document, using a specific verb and resource. It distinguishes from sibling tools like get_annotations or get_components by explicitly mentioning 'styles'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_local_components or scan_nodes_by_types. The agent must infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract data from a Figma table node in various formats (array, object, or CSV)
| Name | Required | Description | Default |
|---|---|---|---|
| tableId | Yes | ID of the table node to extract data from | |
| headerRow | No | Which row to use as headers (0-based index, default: 0) | |
| outputFormat | No | Output format for the table data (default: array) | |
| includeHeaders | No | Whether to include the first row as headers (default: true) | |
| cleanEmptyCells | No | Remove empty cells from output (default: true) |
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 does not disclose whether the tool modifies data, requires specific permissions, or handles errors, leaving behavioral traits unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that efficiently conveys purpose and key variable aspects (formats). No superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so the description should explain return structure. It only says 'extract data' without details on output format, error handling, or node requirements, making it incomplete for an extraction tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The mention of formats aligns with the outputFormat parameter but adds no deeper semantics. No additional explanation beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (extract data), the resource (Figma table node), and the output formats (array, object, CSV), making it distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description is purely functional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the text decoration properties for a specific text range
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | End index of the range (exclusive) | |
| start | Yes | Start index of the range (inclusive) | |
| nodeId | Yes | The ID of the text node |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose that this is a read-only operation, nor does it detail what 'text decoration properties' entails. The description is too minimal for behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise and front-loaded. However, it could be slightly more informative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema and the presence of many sibling tools, the description is incomplete. It does not specify what is returned or how this tool relates to similar ones. More context is needed for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and all parameters are described in the schema. The description adds no additional meaning or context beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('text decoration properties'), and it clearly distinguishes from siblings like 'set_text_decoration_range' and 'get_text_style_range'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_text_style_range' or 'set_text_decoration_range'. The description does not mention any preconditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the text styling (bold, italic, underline, strikethrough) for a specific range of text
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | End index of the range (exclusive) | |
| start | Yes | Start index of the range (inclusive) | |
| nodeId | Yes | The ID of the text node |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states it's a get operation but does not disclose return format, error handling, range validation, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, front-loaded with purpose, no superfluous words. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks output format details (e.g., returns boolean per style) and does not address edge cases or differentiate adequately from similar tools given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 3 parameters with descriptions (100% coverage). The description reiterates 'for a specific range' but adds no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves text styling (bold, italic, underline, strikethrough) for a specific range. It distinguishes from siblings like get_text_decoration_range, which focuses only on decoration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., get_styled_text_segments). No mention of preconditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Join a specific channel to communicate with Figma
| Name | Required | Description | Default |
|---|---|---|---|
| channel | No | The name of the channel to join |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description does not disclose any behavioral traits beyond the basic action, such as permissions or state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no waste, but it is very terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple parameter, the description is minimally adequate but lacks behavioral context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds no meaning beyond the schema's parameter description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool joins a channel for communication, with a specific verb and resource. It distinguishes itself from sibling tools, none of which are join actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a node to a new position in Figma
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | New X position | |
| y | Yes | New Y position | |
| nodeId | Yes | The ID of the node to move |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states it moves a node but does not disclose behavioral traits like whether it changes the node's position absolutely or relatively, or if the operation is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words, allowing quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and behavioral guidance, the description is too minimal. It does not help an agent decide if this tool is appropriate compared to other node manipulation tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds no additional meaning beyond the schema, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (move), the resource (node), and the domain (Figma). It effectively distinguishes from siblings 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., resize_node, set_position). The description lacks context about prerequisites or specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Normalize Markdown text to match Figma's supported subset
| Name | Required | Description | Default |
|---|---|---|---|
| markdown | Yes | Markdown text to normalize |
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. It does not disclose what happens during normalization (e.g., error handling, unsupported elements stripped or rejected), nor any side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is appropriately sized and front-loaded with the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description lacks critical information such as what the tool returns (e.g., normalized markdown string, or an error object). No output schema exists, so the description should compensate, but does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the sole parameter 'markdown' as text to normalize (100% coverage). The description adds value by specifying the target ('Figma's supported subset'), which provides context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool normalizes Markdown text to Figma's supported subset, using a specific verb and resource, and distinguishes it from sibling tools which are mostly node operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when markdown needs normalization or what happens if it's not normalized. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about the current selection in Figma, including all node details
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states the tool returns detailed information but does not explain what 'detailed' means, whether it is read-only, has side effects, or requires any prior actions. Behavioral expectations are vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no extraneous words. It is front-loaded and efficiently conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is mostly complete. It explains what the tool does (get info about current selection). However, it does not describe the output format or any potential limitations (e.g., size of selection, types of nodes). A slightly more detailed description would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so description does not need to add parameter semantics. However, it does add meaning by specifying the scope ('current selection'), which clarifies what the tool acts upon. Baseline 4 for zero parameters is justified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves detailed information about the current selection in Figma, including all node details. It is specific and distinguishes itself from sibling tools like get_selection (which may return only IDs) and get_node_info (which requires a node ID). However, it does not explicitly differentiate from get_multiple_nodes_info or other info tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, limitations, or context (e.g., only works when there is a selection). With many sibling tools that also retrieve node information, usage guidelines are lacking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resize a node in Figma
| Name | Required | Description | Default |
|---|---|---|---|
| width | Yes | New width | |
| height | Yes | New height | |
| nodeId | Yes | The ID of the node to resize |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as side effects, constraints, or permissions. The agent is left unaware of potential impacts beyond the explicit action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise but at the cost of completeness. It lacks necessary detail while being one short sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (3 parameters, no output schema, no annotations), the description should provide more context about constraints, return values, or typical usage scenarios, which it fails to do.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and descriptions within the schema adequately define each parameter. The description adds no additional meaning, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (resize), resource (node), and platform (Figma), effectively distinguishing it from sibling tools like move_node or clone_node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use or when not to use this tool, nor any mention of alternatives. The single sentence provides no contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan for child nodes with specific types in the selected Figma node
| Name | Required | Description | Default |
|---|---|---|---|
| types | Yes | Array of node types to find in the child nodes (e.g. ['COMPONENT', 'FRAME']) | |
| nodeId | Yes | ID of the node to scan |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The term 'scan' suggests a read operation, but the description does not confirm it as non-destructive, disclose return format, or explain edge cases. This leaves behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. It efficiently conveys the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's simplicity, the description omits critical details such as whether scanning is recursive, what is returned (e.g., node IDs or objects), and if there are limits. Given no output schema or annotations, more completeness is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are already well-described in the input schema (100% coverage). The description adds minimal extra context ('in the selected Figma node'), which is mildly helpful but not essential. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'scan', the resource 'child nodes', and the filter 'specific types' in the selected Figma node. It distinguishes from sibling tools like 'scan_text_nodes' which focus on text nodes, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like 'scan_text_nodes' or 'get_nodes'. The description implies a specific use case but does not provide context, exclusions, or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan for nodes with advanced options including depth limit, timeout control, and partial results. Use this when scan_text_nodes times out.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | Root node ID to start scanning from | |
| options | No | Scanning options |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions partial results on timeout and advanced options, but does not state whether the operation is read-only or destructive, nor does it clarify side effects. Some behavioral context is given, but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no extraneous information. The first sentence states purpose and key features, the second gives usage guidance. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides useful context about when to use (timeout scenario) and mentions partial results. It covers the core functionality adequately, though it could mention the return type or format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does 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 summarizes the key parameters but adds no meaning beyond what the schema already provides for each property.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans nodes with advanced options like depth limit, timeout control, and partial results. It also distinguishes itself from the sibling tool scan_text_nodes by noting it should be used when that tool times out.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when scan_text_nodes times out,' providing clear guidance on when to choose this tool over an alternative. This is a precise usage hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
[DEPRECATED] Scan all text nodes in the selected Figma node - Use scan_nodes_with_options instead
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | ID of the node to scan |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions deprecation, a significant behavioral trait, but does not disclose other behaviors like side effects, permissions, or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single sentence with a clear deprecation warning. It is front-loaded and contains no unnecessary words, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description could have explained the return value or behavior of the tool. It fails to do so, although the deprecation note partially compensates by directing users to an alternative. The input is fully covered by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage with a description for 'nodeId'. The tool description does not add any additional meaning beyond 'ID of the node to scan', so it 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scans all text nodes within a selected Figma node. It uses a specific verb ('scan') and resource ('text nodes'), and distinguishes itself from sibling tools like 'scan_nodes_by_types' by being deprecated and focusing on text nodes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly marks the tool as deprecated and directs users to use 'scan_nodes_with_options' instead, providing clear guidance on when not to use this tool and what alternative to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or update an annotation
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | The ID of the node to annotate | |
| categoryId | No | The ID of the annotation category | |
| properties | No | Additional properties for the annotation | |
| annotationId | No | The ID of the annotation to update (if updating existing annotation) | |
| labelMarkdown | Yes | The annotation text in markdown format |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral details. It only states 'create or update' but doesn't explain the conditional logic (e.g., when annotationId is provided, it updates; otherwise creates). No mention of side effects, permissions, or overwrite behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise and front-loaded: one sentence with clear verb and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 5 parameters and no output schema, the description provides minimal context. It doesn't explain the create-vs-update distinction or the behavior of optional fields like 'categoryId' and 'properties', leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. Description adds no additional parameter information beyond what's already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Create or update an annotation' with a specific verb and resource. It distinguishes from sibling 'get_annotations' (read) and 'set_multiple_annotations' (batch), though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives like 'set_multiple_annotations' or 'get_annotations'. Missing context for choosing single vs. batch annotation operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set primary and counter axis alignment for an auto-layout frame in Figma
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | The ID of the frame to modify | |
| counterAxisAlignItems | No | Counter axis alignment (MIN/MAX = top/bottom in horizontal, left/right in vertical) | |
| primaryAxisAlignItems | No | Primary axis alignment (MIN/MAX = left/right in horizontal, top/bottom in vertical). Note: When set to SPACE_BETWEEN, itemSpacing will be ignored as children will be evenly spaced. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose behavioral traits like failure conditions (e.g., if frame is not auto-layout) or side effects. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no waste. Clearly front-loaded with the action and target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is too brief. It omits context like the requirement for the node to be an auto-layout frame, what happens on failure, or return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already describes the parameters with enum meanings and notes (e.g., SPACE_BETWEEN behavior). The description adds no additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets primary and counter axis alignment for an auto-layout frame, using specific verb and resource. It distinguishes from siblings like set_layout_mode and set_item_spacing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives (e.g., set_layout_mode). It implies it's for auto-layout frames but doesn't explicitly state prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the description of a component with Markdown formatting support
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | The ID of the component node | |
| descriptionMarkdown | Yes | Component description in Markdown format. Supports: paragraphs (\n), lists (-, *), headings (##), bold (**), italic (*), strikethrough (~~), links [text](url), code (`code`), code blocks (```code```) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist. The description only mentions the operation and Markdown support but does not disclose behavioral traits such as overwriting behavior, permission requirements, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no fluff. Front-loaded with purpose and key detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema and no annotations, the description lacks behavioral context (e.g., idempotency, return value, side effects). It is minimal for effective decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully described in the schema. The description of 'descriptionMarkdown' adds detailed Markdown syntax support, going beyond the schema's basic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set', the resource 'description of a component', and adds value with 'Markdown formatting support'. It differentiates from sibling tools like 'get_component_description'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., other set tools). No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the corner radius of a node in Figma
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | The ID of the node to modify | |
| radius | Yes | Corner radius value | |
| corners | No | Optional array of 4 booleans to specify which corners to round [topLeft, topRight, bottomRight, bottomLeft] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the mutation action without disclosing behavioral traits such as whether the change is undoable, if it applies only to specific node types, or any permission requirements. The description does not add value beyond the schema in this dimension.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of a single, clear sentence that immediately conveys the tool's purpose. It is appropriately concise with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with three parameters and no output schema, the description is minimally sufficient. However, it lacks context about what happens if the node does not support corner radius, or how the corners parameter interacts with the radius. With no annotations, more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all properties, so the description does not need to add parameter details. The baseline score of 3 is appropriate as the description does not enhance understanding of the parameters beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set the corner radius of a node in Figma' clearly specifies the action (set), the resource (corner radius), and the context (Figma). It distinguishes itself from other setter tools like set_fill_color or set_stroke_color by focusing on a specific property.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as when a node supports corner rounding or when other tools like reshape would be more appropriate. There is no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a copied connector node as the default connector
| Name | Required | Description | Default |
|---|---|---|---|
| connectorId | No | The ID of the connector node to set as default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It only says 'set as default' without explaining side effects, prerequisites (e.g., node must be a copy), impact on other connectors, or whether it is a safe operation. Insufficient for an agent to understand consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but slightly vague. It could be restructured to front-load the core action, but it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given 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 minimally complete but lacks context about the 'copied' requirement and what setting a default entails. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has a clear description for the single parameter 'connectorId'. The tool description adds no additional meaning beyond the schema. With 100% schema description coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Set a copied connector node as the default connector') and the resource, but the term 'copied' is ambiguous and unexplained. It is not a tautology but lacks precision for a sibling-differentiated purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other set_ tools or when not to use it. There are no explicit or implied usage conditions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the fill color of a node in Figma can be TextNode or FrameNode
| Name | Required | Description | Default |
|---|---|---|---|
| a | No | Alpha component (0-1) | |
| b | Yes | Blue component (0-1) | |
| g | Yes | Green component (0-1) | |
| r | Yes | Red component (0-1) | |
| nodeId | Yes | The ID of the node to modify |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry full burden. It mentions applicability to TextNode or FrameNode but does not disclose behavior for other node types (error? no-op?) or any other side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but grammatically flawed ('can be TextNode or FrameNode' missing punctuation). It is concise but at the expense of clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal for a tool with 5 parameters and no output schema. It does not explain return values or provide context on what happens after setting the color. Given no annotations, more information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters described. The description adds no additional meaning beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action (set fill color) and resource (node in Figma), and specifies allowed node types (TextNode or FrameNode). However, the phrasing is grammatically awkward and does not fully distinguish from sibling tools like set_stroke_color.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With many sibling tools for colors and fills, the description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply previously copied overrides to selected component instances. Target instances will be swapped to the source component and all copied override properties will be applied.
| Name | Required | Description | Default |
|---|---|---|---|
| targetNodeIds | Yes | Array of target instance IDs. Currently selected instances will be used. | |
| sourceInstanceId | Yes | ID of the source component instance |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden for behavioral disclosure. It explicitly states the effects: 'Target instances will be swapped to the source component and all copied override properties will be applied.' This communicates the mutation adequately, though it could mention side effects or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the action, the second elaborates the effect. Information is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers input (applies overrides to selected instances) and effect (swap and apply properties). It does not discuss return values or error conditions, but for a mutation tool of this complexity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description does not add new parameter information beyond what is in the schema (the schema already notes that targetNodeIds uses currently selected instances). No extra semantic value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Apply') and clearly identifies the resources ('previously copied overrides' to 'selected component instances'). It distinguishes from siblings by focusing on applying overrides, which is distinct from other mutation tools like set_text_content or clone_node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it applies copied overrides to target instances. It implies a prerequisite (prior copy operation) but does not explicitly state when not to use or list alternatives. This meets the 'clear context, no exclusions' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set distance between children in an auto-layout frame
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | The ID of the frame to modify | |
| itemSpacing | Yes | Distance between children. Note: This value will be ignored if primaryAxisAlignItems is set to SPACE_BETWEEN. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits beyond what is in the input schema. It does not mention side effects, required permissions, or error conditions. The tool is a mutation, but this is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, effectively communicating the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and no output schema, the description is adequate. However, it could mention that the frame must be in auto-layout mode, which is a key context given the sibling tool 'set_layout_mode' exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description adds minimal additional meaning, as it largely echoes the schema's description of 'distance between children'. The note about the ignored condition is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set distance between children') and the resource ('auto-layout frame'). It distinguishes from siblings like set_padding or set_axis_align by specifying the exact property being modified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool over alternatives, nor does it mention prerequisites like the frame needing auto-layout. However, the input schema includes a note about the spacing being ignored if primaryAxisAlignItems is SPACE_BETWEEN, providing some usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the layout mode and wrap behavior of a frame in Figma
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | The ID of the frame to modify | |
| layoutMode | Yes | Layout mode for the frame | |
| layoutWrap | No | Whether the auto-layout frame wraps its children |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It only states 'set' without mentioning side effects, permissions, or that it modifies the node in place. The mutation aspect is implied but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is efficient and front-loaded. However, it could include additional clarifying context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is too brief. It does not explain the effect of setting layout mode, the relationship between layoutMode and layoutWrap, or any constraints (e.g., node must be a frame with auto-layout).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no extra meaning beyond what the schema already provides. The description simply repeats 'layout mode and wrap behavior', which is already clear from the enum names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'set' and the resource 'layout mode and wrap behavior of a frame'. It distinguishes from sibling tools like set_fill_color or set_axis_align by specifying the exact property being modified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention prerequisites, such as requiring the frame to have auto-layout enabled, nor does it differentiate from similar set_ tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set horizontal and vertical sizing modes for an auto-layout frame in Figma
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | The ID of the frame to modify | |
| layoutSizingVertical | No | Vertical sizing mode (HUG for frames/text only, FILL for auto-layout children only) | |
| layoutSizingHorizontal | No | Horizontal sizing mode (HUG for frames/text only, FILL for auto-layout children only) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behavior on non-auto-layout frames, error handling, or side effects. Minimal transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 14 words, front-loaded. Every word contributes meaning. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, 2 enums, no output schema, and no annotations, the description is too sparse. It omits necessary context about auto-layout prerequisites, return values, and error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The tool description adds no extra meaning beyond restating the purpose. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Set'), target ('horizontal and vertical sizing modes'), and context ('auto-layout frame in Figma'). It distinguishes from sibling tools like 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. No mention of prerequisites (e.g., frame must be auto-layout) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set multiple annotations parallelly in a node
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | The ID of the node containing the elements to annotate | |
| annotations | Yes | Array of annotations to apply |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behaviors like atomicity, error handling, or concurrency. 'Parallelly' hints at concurrent execution but lacks details on whether partial failures are tolerated or if the operation is transactional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) and front-loads the core purpose. It could be expanded slightly to provide more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a complex array parameter, the description omits critical context: how the top-level nodeId relates to the per-annotation nodeIds, what happens on validation errors, and whether annotations are created or updated. This makes it difficult for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are documented in the schema. The description adds no additional context beyond the schema, such as explaining the relationship between the top-level nodeId and the nodeId inside each annotation item.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets multiple annotations in a node, implying a batch operation. It implicitly distinguishes from the singular set_annotation sibling, but does not explicitly contrast or mention the alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like set_annotation or other annotation-related tools. Does not specify use cases or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the same property value on multiple nodes at once. Useful for bulk updates like visibility, opacity, or position.
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | Value to set for the property | |
| nodeIds | Yes | Array of node IDs to update | |
| property | Yes | Property name to set (e.g., 'visible', 'opacity', 'x', 'y') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states that it sets a property, which implies mutation, but it omits important details such as error handling for invalid nodeIds or property names, whether the operation is atomic, any permissions needed, or rate limits. This lack of behavioral context is a significant gap for a mutation tool without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, 19 words. It front-loads the action in the first sentence and provides usage context in the second. Every word contributes meaning without repetition or filler. This is an excellent example of efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the core action and typical use cases. However, it lacks details on return values (no output schema, so the description should hint at what happens after execution) and error handling. It also does not mention any constraints like maximum number of nodeIds. While adequate for a straightforward setter, it leaves some gaps for an AI agent to fully understand behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all three parameters described. The property parameter includes examples (e.g., 'visible', 'opacity'), which adds slight value beyond the schema. The value parameter only says 'Value to set for the property,' which is generic but adequate given the dynamic nature. As baseline is 3 due to high coverage, the description does not significantly enhance meaning, so 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: setting a property value on multiple nodes simultaneously. It provides concrete examples of properties like visibility, opacity, or position, and the verb 'Set' plus resource 'multiple nodes' is specific and unambiguous. The name itself reinforces this, and it distinguishes from single-node or different property tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Useful for bulk updates like visibility, opacity, or position,' which implies when to use it—for bulk operations. However, it does not specify when not to use it (e.g., for complex conditional updates) or offer alternatives like execute_batch or individual setters. The guidance is implicit rather than explicit, scoring 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set multiple text contents parallelly in a node
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Array of text node IDs and their replacement texts | |
| nodeId | Yes | The ID of the node containing the text nodes to replace |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the tool sets multiple texts 'parallelly' (implying concurrent execution) but fails to mention mutation behavior, error handling, atomicity, or authorization requirements. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at 8 words, but this brevity sacrifices necessary detail. While there is no wasted text, it is under-specified for the complexity of a batch operation. It could be restructured to include key behavioral notes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a batch mutation with no output schema, the description should explain the effect on the node, ordering guarantees, error behavior, and limitations. It provides none of this, leaving significant gaps for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema documents both parameters thoroughly. The description adds minimal value beyond 'multiple' and 'parallelly', not clarifying the parameter semantics further. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set multiple text contents parallelly in a node' clearly indicates the action (set) and resource (multiple text contents within a node). It effectively distinguishes from sibling tool 'set_text_content' which sets a single text, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'set_text_content' for single updates or other batch operations. No context on prerequisites, performance benefits, or scenarios where this tool is preferred is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update multiple text nodes with content and optional styling in a single operation. More efficient than separate text and style updates.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | The parent node ID containing the text nodes | |
| updates | Yes | Array of text updates with optional styling |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden of behavioral disclosure. It does not mention whether the operation is atomic, destructive, or has specific authorization needs. The description is too brief to provide sufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence that front-loads the action and purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not mention the return value, error handling, or side effects. For a write operation that updates multiple nodes, such details are important. The lack of output schema amplifies the need for this information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents all parameters. The description adds only the efficiency note, which does not enhance parameter understanding beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates multiple text nodes with content and optional styling, and highlights efficiency compared to separate updates. It distinguishes from sibling tools like set_text_content and 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use it (for combined text and style updates), but does not explicitly state when not to use it or name alternative tools. However, the efficiency framing implies preference over separate calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set padding values for an auto-layout frame in Figma
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | The ID of the frame to modify | |
| paddingTop | No | Top padding value | |
| paddingLeft | No | Left padding value | |
| paddingRight | No | Right padding value | |
| paddingBottom | No | Bottom padding value |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as whether the tool modifies the frame, requires permissions, or has side effects. For a mutation tool, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no extraneous words. It is concise and appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is insufficient for complete context. It lacks information about behavior, side effects, and when to use it, leaving gaps for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description adds no additional meaning beyond what is in the schema, achieving the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set padding values') and the specific resource ('auto-layout frame in Figma'). It is specific and distinguishable from sibling tools like set_item_spacing 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives, nor any mention of prerequisites or exclusions. The description is a single sentence with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the text color for a specific text range
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | End index of the range (exclusive) | |
| color | Yes | Text color | |
| start | Yes | Start index of the range (inclusive) | |
| nodeId | Yes | The ID of the text node |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear all behavioral details. It only states the action but does not disclose side effects (e.g., overwrites existing color, no undo, whether the node type is validated), permissions needed, or behavior on invalid input. This is insufficient for an AI agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, very concise and front-loaded. However, it sacrifices necessary detail for brevity. While efficient, it lacks context that could be added without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should explain more about the operation (e.g., return value, validation, error handling). It only describes the action, leaving the agent to infer behavior. For a mutation tool with 4 required params, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all parameters. The description adds no new semantic information beyond what the schema provides, so it does not enhance understanding. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('set') and resource ('text color for a specific text range'). It differentiates from sibling tools like set_range_font, set_range_font_size, etc., by specifying 'color' rather than font or decoration. However, the term 'fills' might cause confusion with set_fill_color (which sets shape fill), but the description clarifies it's text color.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., set_fill_color for shapes, set_range_font for font). It does not mention prerequisites, such as the node must be a text node, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the font family and style for a specific text range
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | End index of the range (exclusive) | |
| start | Yes | Start index of the range (inclusive) | |
| nodeId | Yes | The ID of the text node | |
| fontStyle | No | Font style (e.g., 'Regular', 'Bold', 'Italic') | Regular |
| fontFamily | Yes | Font family name (e.g., 'Inter', 'Roboto') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It fails to mention if the operation is additive or overwriting, what happens with invalid fonts, or any side effects. Only a basic mutation description is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Could be expanded slightly to include more context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 5 parameters (4 required), the description is minimal. It explains the basic operation but lacks details on return values, error conditions, or behavior. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds that it sets both font family and style, but fontStyle is optional in the schema and the description doesn't clarify that nuance. Minimal extra value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Set), resource (font family and style), and scope (specific text range). It differentiates from sibling tools like set_range_font_size and set_text_style_range.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. For example, it doesn't contrast with set_text_style_range which could also modify font properties.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the font size for a specific text range
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | End index of the range (exclusive) | |
| start | Yes | Start index of the range (inclusive) | |
| nodeId | Yes | The ID of the text node | |
| fontSize | Yes | Font size in pixels |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'set the font size' but does not disclose side effects, permissions, undo behavior, range validation, or any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is efficient, though brevity limits informativeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 required parameters and no output schema, the description lacks crucial details like range constraints, return behavior, and edge cases. It is incomplete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with each parameter described. The description adds no new meaning beyond what is in the schema. Baseline 3 is appropriate as the schema already documents the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and resource 'font size for a specific text range'. It identifies the core function but does not explicitly distinguish from siblings like 'set_range_font' which may also modify font size.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, no conditions, and no context. It simply states the action without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rearrange slides into a grid layout in Figma Slides
| Name | Required | Description | Default |
|---|---|---|---|
| slides | Yes | 2D array of slide IDs representing the grid layout. Each inner array represents a row of slides. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only says 'rearrange' without explaining whether the operation is destructive, preserves slide content, or what happens to slides not in the grid. This leaves significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. However, it is so concise that it omits important details, balancing efficiency with informativeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given 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), the description is minimally complete. However, it lacks behavioral details and return value information, which may leave an agent uncertain about the tool's full operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'slides' has 100% schema description coverage, so the schema already provides clear meaning. The tool description adds no extra semantic value beyond what the schema states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('rearrange') and the resource ('slides into a grid layout'), making the purpose understandable. However, it does not explicitly distinguish from sibling tools like 'create_slide_row' or 'get_slide_grid'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., 'create_slide_row' or manual slide arrangement). The description fails to provide any usage context or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the viewport mode in Figma Slides
| Name | Required | Description | Default |
|---|---|---|---|
| mode | Yes | Viewport mode |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It only states it sets a mode, without mentioning side effects, mutability, or impact on the UI, which is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no extraneous information, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given 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), the description is minimally adequate but lacks completeness in explaining effects or usage context, leaving gaps for a tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, with 'mode' having an enum and description. The description adds no additional semantic value beyond the schema, 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'viewport mode in Figma Slides', making the tool's purpose specific and distinct from sibling tools like get_slides_mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives or any context about prerequisites or best practices, leaving ambiguity about its appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the transition for a slide in Figma Slides
| Name | Required | Description | Default |
|---|---|---|---|
| slideId | Yes | The ID of the slide | |
| transition | Yes | Transition configuration |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the action is destructive, requires specific permissions, or has side effects. For a mutation tool, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the purpose. It is concise for a simple setter, though it could potentially include more context without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or annotations exist, and the description does not explain return values or side effects. However, parameters are fully documented in the schema, making the description minimally adequate for a straightforward mutation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all parameters with descriptions (100% coverage). The tool description adds no additional meaning beyond 'transition configuration'. Baseline is 3 with high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set the transition') and the resource ('a slide in Figma Slides'). It distinguishes from the sibling 'get_slide_transition' (read vs write).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for changing a slide's transition, but provides no explicit guidance on when to use this tool versus alternatives like 'get_slide_transition' or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the stroke color of a node in Figma
| Name | Required | Description | Default |
|---|---|---|---|
| a | No | Alpha component (0-1) | |
| b | Yes | Blue component (0-1) | |
| g | Yes | Green component (0-1) | |
| r | Yes | Red component (0-1) | |
| nodeId | Yes | The ID of the node to modify | |
| weight | No | Stroke weight |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description alone should disclose behavioral traits. It does not mention that this is a write operation, whether it modifies the node permanently, or what happens if the node lacks a stroke stroke. The brief description fails to provide critical behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core purpose with no extraneous words, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 6 parameters and no output schema or annotations, the description is too sparse. It does not explain return values, error conditions (e.g., invalid nodeId), or the relationship between stroke color and weight. The agent lacks sufficient information to use the tool reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter. The description adds no additional semantic value beyond the schema, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'stroke color of a node', which is specific and distinct from sibling tools like set_fill_color. It immediately conveys 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., set_fill_color) or on prerequisites (e.g., node must exist and have a stroke property). The agent must infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the text content of an existing text node in Figma
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | New text content | |
| nodeId | Yes | The ID of the text node to modify |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full behavioral disclosure burden. It only states basic action without detailing side effects (e.g., whether it preserves existing formatting), permissions required, or error conditions. This is a significant gap 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, concise and front-loaded. However, it omits important behavioral context that could be added without disrupting conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple parameters, the description is minimal. It does not distinguish behavior from siblings like update_text_preserve_formatting, nor explains output or limitations. For a tool with 2 required params and common use case, more context is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as both parameters have descriptions. The tool description adds no additional meaning beyond what the schema already provides, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'set', resource 'text content', and scope 'existing text node in Figma'. It distinguishes from siblings like create_text (creates new node) and set_multiple_text_contents (bulk operation) by specifying single node modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like set_multiple_text_contents or update_text_preserve_formatting. The description implies usage for changing text of a single node but does not explain exclusion cases (e.g., bulk edits or formatting preservation).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set advanced text decoration properties (style, color, thickness, offset) for a text range
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | End index of the range (exclusive) | |
| color | No | Decoration color | |
| start | Yes | Start index of the range (inclusive) | |
| style | No | Decoration style | |
| nodeId | Yes | The ID of the text node | |
| offset | No | Decoration offset | |
| skipInk | No | Whether decoration skips over descenders | |
| thickness | No | Decoration thickness |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description lacks disclosure of side effects (e.g., replaces existing decorations?), destructive nature, permissions, or return value. No annotations provided, so full burden on description, which fails to deliver.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise and front-loads purpose. Could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (8 params, nested object, no output schema), description is minimal. Fails to explain interaction of parameters, required params, or result of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 8 parameters. Description adds no extra meaning beyond listing properties, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Set', resource 'advanced text decoration properties', and scope 'for a text range'. It distinguishes from sibling tools like set_text_style_range.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, no prerequisites or scenarios provided. Agent must infer usage from name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Apply text styling (bold, italic, underline, strikethrough) to a specific range of text in a text node
| Name | Required | Description | Default |
|---|---|---|---|
| end | Yes | End index of the range (exclusive) | |
| bold | No | Apply bold styling | |
| start | Yes | Start index of the range (inclusive) | |
| italic | No | Apply italic styling | |
| nodeId | Yes | The ID of the text node | |
| underline | No | Apply underline styling | |
| strikethrough | No | Apply strikethrough styling |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description should disclose behavioral traits. Only states basic action; does not mention if styling is additive or overwriting, error handling, or permissions. Minimal behavioral description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundant words. Efficiently conveys key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so agent lacks knowledge of return value. No mention of error scenarios, prerequisite (e.g., node must be text), or indexing details. Incomplete for a range-based styling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters with descriptions (100% coverage). Description does not add extra meaning beyond listing styles. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Apply', resource 'text styling' (bold, italic, underline, strikethrough) and scope 'range of text in a text node'. It differentiates from siblings like set_text_content and get_text_style_range.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use vs alternatives (e.g., set_text_decoration_range, set_text_content). No exclusions or context about 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.
Replace specific text in a node while preserving the formatting of unchanged portions. Only replaced text gets default formatting.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | The ID of the text node | |
| replacements | Yes | Array of find/replace operations to perform |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides clear behavioral details: formatting of unchanged portions is preserved, and only replaced text gets default formatting. This is sufficient for a simple find/replace operation, though it does not cover edge cases like sequential vs. parallel replacement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences that front-load the core action and key behavior without any unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description covers the essential behavior. It could mention limitations or ordering of replacements, but it is largely complete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for nodeId and replacements. The description adds context about formatting behavior that goes beyond the schema, though it does not provide additional detail on individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Replace' and the resource 'specific text in a node', and distinguishes its behavior by highlighting that formatting of unchanged portions is preserved, which sets it apart from sibling tools like set_text_content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (partial text replacement with formatting preservation), but lacks explicit guidance on when not to use it or how it compares to alternatives like update_text_preserve_formatting or set_text_content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update text content while preserving existing character formatting. Choose a strategy for handling formatting when text length changes.
| Name | Required | Description | Default |
|---|---|---|---|
| nodeId | Yes | The ID of the text node to update | |
| newText | Yes | The new text content | |
| preserveFormattingStrategy | No | Strategy for handling formatting when text length changes: 'stretch' proportionally extends formatting, 'repeat' repeats the pattern, 'reset_overflow' keeps existing formatting and uses defaults for new characters |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the key behavioral aspect: preservation of formatting and the strategy parameter for handling length changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description covers all necessary aspects given no output schema and low parameter count. Could mention return type but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description adds value by explaining the purpose of the strategy parameter beyond its enum values, giving context for when to choose each.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates text content while preserving formatting, distinguishing it from sibling tools like set_text_content that likely overwrite formatting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when formatting preservation is needed, but lacks explicit guidance on when not to use it or alternatives among many text-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
There are many overlapping tools for similar purposes, such as deprecated node info functions (get_node_info, get_nodes_info, get_nodes) and multiple text update tools (set_text_content, smart_text_replace, update_text_preserve_formatting, set_multiple_text_contents, etc.). This makes it difficult for an agent to select the correct tool without confusion.
Tool names generally follow a consistent verb_noun snake_case pattern (e.g., create_frame, delete_node, set_fill_color). Minor deviations exist, such as 'read_my_design' which uses a different structure, but overall naming is predictable.
With 75 tools, the server is significantly over-sized for typical MCP usage. This large number overwhelms agents and includes many deprecated or redundant tools that could be consolidated.
The tool set covers a wide range of Figma operations including creation, modification, reading, and batch operations. However, some common tasks like grouping nodes or advanced layout properties are missing, leaving minor gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The Figma MCP server brings Figma design context directly into your AI workflow.
Generate, inspect, and manage Flowstep UI designs directly from your AI assistant.
Build and manage your design system with AI: tokens, themes, components, icons, Figma and code.
Give your AI agents the tools to build, manage, and run automation workflows.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/xlzuvekas/figma-copilot'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
