Skip to main content
Glama
Sign In
Figxel

Figxel

by AvYour
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Set visibility

figma_set_visible
Idempotent

Hide or show nodes. Returns per-item results: items: [{ id, ok, error? }] — one node failing does not fail the call. Editors: Design; unverified: FigJam, Slides.

Instructions

Hide or show nodes. Returns per-item results: items: [{ id, ok, error? }] — one node failing does not fail the call. Editors: Design; unverified: FigJam, Slides.

Input Schema

NameRequiredDescriptionDefault
forceNoOverwrite on purpose. A write to a node someone changed after you last read it is refused (STALE); read it again and resend instead. Pass true only when the person said to overwrite their edit.
nodeIdsYes
sessionNoOptional sessionId or file name, to pick a Figma file when more than one is connected.
visibleYes
idempotencyKeyNoCaller-owned retry key, ≤128 chars. Re-calling with the same key never executes twice: it returns the existing result, or waits for the op still in flight. Supply your own for anything large — if the MCP client times out (rather than the bridge), only a key you chose can be used to retry safely.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.3.0
    • addedInput schema / properties / force
      Added value: +{
+  "description": "Overwrite on purpose. A write to a node someone changed after you last read it is refused (STALE); read it again and resend instead. Pass true only when the person said to overwrite their edit.",
+  "type": "boolean"
+}
  2. First observedv0.1.1

TDQS

A3.8/5.0
Behavior4/5

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

Adds real behavior beyond annotations: per-item result shape (`items: [{ id, ok, error? }]`) and the crucial partial-failure contract that one failing node does not fail the call. Also discloses editor/platform coverage. It does not explain permission requirements or edge behavior (e.g. nodes hidden by ancestors or locked nodes), keeping it below 5.

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 tight sentences: the operation front-loaded, then the return contract, then a terse environment caveat. No filler sentences at all.

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?

Covers the essentials for a batch mutation: what it changes, that partial failures are expected and returned per id, and where the editor support stands, though there is no output schema. Missing only limits like the 500-node cap (in schema) and interactions with locked/hidden ancestor state.

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?

The description says nothing about nodeIds, visible, session, force or idempotencyKey; the schema carries descriptions for force, session and idempotencyKey (60% coverage) and the two undocumented params are self-explanatory. With schema doing most of the work, baseline 3 is correct.

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?

States a specific verb pair and resource ('Hide or show nodes'), which is clearly distinct from sibling mutation tools like figma_set_locked, figma_set_opacity or figma_delete_nodes. It does not explicitly name a sibling it might be confused with, so it stops short of 5.

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?

Usage is implied by the operation name rather than stated; there is no 'use this instead of X' routing to alternatives such as figma_set_locked. The one piece of context given – 'Editors: Design; unverified: FigJam, Slides' – is environment applicability rather than when-to-use guidance.

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