MorphaReels

Group layers

group_layers

Destructive

Wrap sibling elements in a new group, which the Layers panel shows as one named row the person can select, move and animate as one thing (a butterfly assembled from wings + body + antennae, an icon built from primitives, a card + its title + badge, a lower-third). name is that row's label. The group composes its x/y/scale/rotation/opacity onto its descendants (so one track flies/spins/fades the whole thing) and pivots rotate/scale at its (pivotX, pivotY), seeded to the centroid of its children at create time. The group's x/y track values are translation offsets applied around the pivot — groups have no static body of their own. All listed elementIds must currently share the same parent (root, or one existing group).

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	Optional human-readable label.
`projectId`	Yes	Opaque project id (a v4 UUID, from list_projects/create_project). Selects which existing project this call mutates.
`elementIds`	Yes	Element ids of the elements to wrap. Must all share the same parent.

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes	Whether the call succeeded.
`data`	No	The payload, shaped by the tool.
`note`	No	What to do next when not ready.
`error`	No	Why it failed.
`status`	No	For cache-backed readers: whether the answer was ready.
`editorUrl`	No	Opens this project in the editor.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 17, 2026

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: -[
-  "elementIds",
-  "projectId",
-  "anonymousToken"
-]New value: +[
+  "elementIds",
+  "projectId"
+]

Changed1 schema field changedSep 15, 2026

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"
+}

Changed2 schema fields changedSep 11, 2026

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: -[
-  "elementIds",
-  "projectId"
-]New value: +[
+  "elementIds",
+  "projectId",
+  "anonymousToken"
+]

First observedSep 7, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations declare readOnlyHint=false and destructiveHint=true but say nothing about mechanics; the description supplies the non-obvious behavior: transforms compose onto descendants, pivot rotates/scales at (pivotX, pivotY) seeded to the child centroid, and group x/y track values are translation offsets around that pivot with no static body. This is substantive disclosure well beyond what the annotations carry and does not contradict them.

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?

The core action is front-loaded in the first clause, and the paragraph is dense but mostly earns its length through pivot and composition semantics. The four illustrative examples and some re-explanation of the parent constraint are slightly redundant and could be trimmed.

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

Completeness5/5

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

For a complex structural mutation with an output schema present (so return values need not be explained), the description covers the action, the required precondition, pivot seeding, transform composition, and translation semantics. An agent has everything needed to invoke it correctly.

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 elementIds and projectId are already documented, and the description's parent-sharing constraint restates the schema text. It adds mild meaning for `name` (the label of the new panel row) but no format or edge-case detail beyond the schema, so the baseline of 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 ('Wrap sibling elements in a new group') and immediately clarifies the observable result in the Layers panel, distinguishing it from unrelated mutations. The parenthetical examples (butterfly, icon, card, lower-third) make the operation concrete without ambiguity.

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?

It provides a real precondition (all elementIds must share the same parent, root or one existing group), which is genuine usage context. However, it never names alternatives such as ungroup_layers or set_group_parent, nor states when a group should be preferred over another structural operation, leaving usage implied rather than directed.

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

All MorphaReels tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?