Skip to main content
Glama

set_effect_style_id

Apply a specific effect style to a design element in Figma by providing the node ID and effect style ID to modify visual properties.

Instructions

Apply an effect style to a node in Figma

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nodeIdYesThe ID of the node to modify
effectStyleIdYesThe ID of the effect style to apply

Implementation Reference

  • MCP tool handler registration for set_effect_style_id, including input schema (nodeId, effectStyleId) and execution logic that delegates to Figma's set_effect_style_id command via sendCommandToFigma.
    server.tool(
      "set_effect_style_id",
      "Apply an effect style to a node in Figma",
      {
        nodeId: z.string().describe("The ID of the node to modify"),
        effectStyleId: z.string().describe("The ID of the effect style to apply")
      },
      async ({ nodeId, effectStyleId }) => {
        try {
          const result = await sendCommandToFigma("set_effect_style_id", {
            nodeId,
            effectStyleId
          });
    
          const typedResult = result as { name: string, effectStyleId: string };
    
          return {
            content: [
              {
                type: "text",
                text: `Successfully applied effect style to node "${typedResult.name}"`
              }
            ]
          };
        } catch (error) {
          return {
            content: [
              {
                type: "text",
                text: `Error setting effect style: ${error instanceof Error ? error.message : String(error)}`
              }
            ]
          };
        }
      }
    );
  • Zod input schema for the set_effect_style_id tool.
    {
      nodeId: z.string().describe("The ID of the node to modify"),
      effectStyleId: z.string().describe("The ID of the effect style to apply")
    },
  • Registration of the set_effect_style_id tool on the MCP server using server.tool.
    server.tool(
      "set_effect_style_id",
      "Apply an effect style to a node in Figma",
      {
        nodeId: z.string().describe("The ID of the node to modify"),
        effectStyleId: z.string().describe("The ID of the effect style to apply")
      },
      async ({ nodeId, effectStyleId }) => {
        try {
          const result = await sendCommandToFigma("set_effect_style_id", {
            nodeId,
            effectStyleId
          });
    
          const typedResult = result as { name: string, effectStyleId: string };
    
          return {
            content: [
              {
                type: "text",
                text: `Successfully applied effect style to node "${typedResult.name}"`
              }
            ]
          };
        } catch (error) {
          return {
            content: [
              {
                type: "text",
                text: `Error setting effect style: ${error instanceof Error ? error.message : String(error)}`
              }
            ]
          };
        }
      }
    );
  • Type definition for FigmaCommand union including 'set_effect_style_id' used internally for websocket commands.
    export type FigmaCommand =
      | "get_document_info"
      | "get_selection"
      | "get_node_info"
      | "create_rectangle"
      | "create_frame"
      | "create_text"
      | "create_ellipse"
      | "create_polygon"
      | "create_star"
      | "create_vector"
      | "create_line"
      | "set_fill_color"
      | "set_stroke_color"
      | "move_node"
      | "resize_node"
      | "delete_node"
      | "get_styles"
      | "get_local_components"
      | "get_team_components"
      | "create_component_instance"
      | "export_node_as_image"
      | "join"
      | "set_corner_radius"
      | "clone_node"
      | "set_text_content"
      | "scan_text_nodes"
      | "set_multiple_text_contents"
      | "set_auto_layout"
      | "set_font_name"
      | "set_font_size"
      | "set_font_weight"
      | "set_letter_spacing"
      | "set_line_height"
      | "set_paragraph_spacing"
      | "set_text_case"
      | "set_text_decoration"
      | "get_styled_text_segments"
      | "load_font_async"
      | "get_remote_components"
      | "set_effects"
      | "set_effect_style_id"
      | "group_nodes"
      | "ungroup_nodes"
      | "flatten_node"
      | "insert_child";

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose if this is a mutation (implied by 'Apply'), permission requirements, error conditions, or side effects, which is inadequate for a tool that likely modifies data.

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

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded and appropriately sized for its purpose, with no wasted content.

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

Completeness2/5

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

Given no annotations, no output schema, and a mutation tool with two parameters, the description is incomplete. It lacks behavioral context, error handling, or result details, making it insufficient for safe and effective use by an agent.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents both parameters. The description adds no additional meaning beyond implying 'nodeId' and 'effectStyleId' are used together, but doesn't explain parameter relationships or constraints, meeting the baseline for high coverage.

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

Purpose4/5

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

The description clearly states the action ('Apply') and target ('effect style to a node in Figma'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'set_effects' or 'set_fill_color' that also modify node properties, so it's not fully specific to sibling context.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. The description lacks context about prerequisites (e.g., needing existing effect styles or node IDs) or comparisons to similar tools like 'set_effects', leaving usage unclear.

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