Skip to main content
Glama

Set layer visible

set_layer_visible
Destructive

Show or hide a layer at every frame, exactly as the eye in the Layers panel does: sets or clears the layer's hidden flag. Its opacity, static or animated, is left as it is, so showing it again restores what it was. Hiding a group hides everything in it. describe_video marks a hidden layer hidden: true. Refuses the canvas backdrop.

Input Schema

NameRequiredDescriptionDefault
visibleYes
elementIdYes
projectIdYesOpaque project id (a v4 UUID, from list_projects/create_project). Selects which existing project this call mutates.

Output Schema

NameRequiredDescriptionDefault
okYesWhether the call succeeded.
dataNoThe payload, shaped by the tool.
noteNoWhat to do next when not ready.
errorNoWhy it failed.
statusNoFor cache-backed readers: whether the answer was ready.
editorUrlNoOpens this project in the editor.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedInput schema / properties / anonymousToken
      Removed value: -{
      -  "description": "The token create_anonymous_account returned. This connection has no Morpha key, so every call carries it.",
      -  "type": "string"
      -}
    • changedInput schema / required
      Previous value: -[
      -  "elementId",
      -  "visible",
      -  "projectId",
      -  "anonymousToken"
      -]New value: +[
      +  "elementId",
      +  "visible",
      +  "projectId"
      +]
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "description": "The result envelope every Morpha tool returns.",
      +  "properties": {
      +    "data": {
      +      "description": "The payload, shaped by the tool.",
      +      "type": [
      +        "object",
      +        "array",
      +        "string",
      +        "number",
      +        "boolean",
      +        "null"
      +      ]
      +    },
      +    "editorUrl": {
      +      "description": "Opens this project in the editor.",
      +      "type": "string"
      +    },
      +    "error": {
      +      "description": "Why it failed.",
      +      "type": "string"
      +    },
      +    "note": {
      +      "description": "What to do next when not ready.",
      +      "type": "string"
      +    },
      +    "ok": {
      +      "description": "Whether the call succeeded.",
      +      "type": "boolean"
      +    },
      +    "status": {
      +      "description": "For cache-backed readers: whether the answer was ready.",
      +      "enum": [
      +        "ready",
      +        "not-ready"
      +      ],
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "ok"
      +  ],
      +  "type": "object"
      +}
  3. Changed2 schema fields changed
    • addedInput schema / properties / anonymousToken
      Added value: +{
      +  "description": "The token create_anonymous_account returned. This connection has no Morpha key, so every call carries it.",
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "elementId",
      -  "visible",
      -  "projectId"
      -]New value: +[
      +  "elementId",
      +  "visible",
      +  "projectId",
      +  "anonymousToken"
      +]
  4. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses that opacity (static or animated) is preserved so the change is reversible, that hiding a group cascades to its children, that the canvas backdrop is refused, and that describe_video reports `hidden: true`. These are exactly the side effects and edge cases an agent needs before calling a mutating tool.

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?

Front-loads the core action, then layers in the reversibility, group cascade, and backdrop refusal in tight clauses. No sentence is filler and each adds a distinct behavioral fact.

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?

With an output schema present, return values need no explanation, and the description covers side effects, cascade behavior, and the backdrop edge case thoroughly. The only shortfall is the undocumented elementId, which matters for a 3-required-param tool.

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 only 33% (only projectId is documented), so the description must compensate. It implicitly defines `visible` via 'sets or clears the hidden flag' but never explains `elementId` (what a layer id is or where to get it), leaving a real gap for a required parameter.

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+resource ('Show or hide a layer') and pins the exact mechanism ('sets or clears the layer's `hidden` flag'), which cleanly separates it from siblings like set_layer_fill, set_layer_block, or set_layer_transition that also mutate a layer.

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

Usage Guidelines4/5

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

The 'exactly as the eye in the Layers panel does' analogy gives a clear mental model for when to use it, and the note that opacity is untouched clarifies the boundary versus opacity-related tools. It stops short of naming an explicit alternative or exclusion, so it is clear context rather than full when/when-not routing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources