Skip to main content
Glama
Guddion Figma

Guddion Figma

by TheGudwinn

move_node

Reposition an existing Figma node by updating its x/y coordinates and/or parent node. Use it to place nodes within or across frames.

Instructions

Перемещает существующую ноду — меняет родителя и/или позицию x/y.

Input Schema

NameRequiredDescriptionDefault
xNo
yNo
nodeIdYesID ноды для перемещения
operationIdNoЕсли передан — повторный вызов с тем же значением вернёт закэшированный результат вместо повторного выполнения. Используй при ретраях после таймаута.
parentNodeIdNoНовый родитель; если не задан — родитель не меняется

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?

No annotations exist, so the description carries the full behavioral burden, yet it only says the node moves. It does not disclose whether x/y are absolute or relative coordinates, coordinate space, whether moving is reversible/undoable, what happens to child nodes of the old parent, or required permissions for a mutation.

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

Conciseness4/5

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

A single compact sentence, front-loaded with the verb and resource, with zero filler. It is efficient, though its brevity is partly the source of the missing behavioral detail.

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?

This is a mutation tool with five parameters, no annotations, and no output schema, so the description is the only source of behavioral context — and it supplies almost none. Nothing is said about return values, error cases (invalid parent, cycle creation), permission requirements, or coordinate semantics.

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 60%: nodeId, parentNodeId, and operationId (including retry/caching semantics) are documented in the schema. The description names parent and x/y as changeable fields but adds no meaning about the two undocumented numeric parameters — whether x/y are absolute coordinates, relative offsets, or optional independent of each other.

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 states a specific verb and resource ('Перемещает существующую ноду') and clarifies the exact scope of the change: parent reassignment and/or x/y position. This lets an agent infer it is narrower than update_node or write_node, though no sibling is named explicitly.

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 when-to-use or when-not-to-use guidance is given, and no alternative tool is mentioned. The agent is left to infer on its own whether to call move_node versus update_node or clone_node for a given task, and no prerequisites (permissions, node state) are stated.

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