Skip to main content
Glama
southleft

figma-console-mcp

by southleft

figma_delete_variable_collection

Deletes a Figma variable collection and all its variables in one destructive operation. Use it to remove obsolete token groups; the action cannot be undone except through Figma undo.

Instructions

Delete a Figma variable collection and ALL its variables. WARNING: This is a destructive operation that deletes all variables in the collection and cannot be undone (except with Figma's undo). Requires the Desktop Bridge plugin to be running.

Input Schema

NameRequiredDescriptionDefault
collectionIdYesThe collection ID to delete (e.g., 'VariableCollectionId:123:456'). Get this from figma_get_variables.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.46.0

TDQS

A4/5.0
Behavior4/5

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

With no annotations present, the description carries the full burden and does a solid job: it warns this is destructive, that it removes every variable in the collection, that it cannot be undone except via Figma's undo, and that the Desktop Bridge plugin must be running. It stops short of describing the response or permission requirements, but the key behavioral risks are disclosed.

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

Conciseness5/5

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

Two sentences, zero waste. The destructive scope is front-loaded in sentence one and the WARNING plus prerequisite follow immediately, so the most critical information is read first.

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

Completeness4/5

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

For a single-parameter destructive tool with no annotations and no output schema, the description covers scope, irreversibility, and the plugin prerequisite. Only the return behavior is unaddressed, which is a minor gap given the simplicity.

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 coverage is 100% and the sole parameter is fully documented in the schema, including an example ID format and a pointer to figma_get_variables. The description adds nothing beyond the schema here, so the baseline 3 applies.

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

Purpose5/5

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

States a specific verb and resource ('Delete a Figma variable collection'), and adds scope ('and ALL its variables') that separates it from sibling figma_delete_variable, which removes a single variable. An agent can tell which deletion tool to reach for without opening the schema.

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

Usage Guidelines3/5

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

The phrase 'and ALL its variables' implies the bulk-delete context versus a single-variable delete, and the schema points to figma_get_variables for obtaining the ID. However, there is no explicit when-to-use/when-not guidance or named alternative, so routing is left to inference.

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

Deploy Server

Other Tools