Skip to main content
Glama

Morpha

by ai.morphareels
OverviewDiscussionsAdmin

Add shape

add_shape

Add a shape layer. kind selects the primitive: rect | ellipse | triangle | star | pentagon | hexagon | arrow | heart | rounded-rect | diamond | parallelogram | trapezoid | semicircle | ring | pill | cross | heptagon | octagon | star-4 | star-6 | sparkle | burst | arrow-left | double-arrow | chevron | block-arrow-up | curve | lightning | speech-bubble | location-pin | checkmark | x-mark | shield | cloud | crescent | teardrop | banner. All are native vector shapes; never substitute an image layer for one. Default-positioned in canvas centre if x/y/w/h omitted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xNo
yNo
kindYes
blockNoOPTIONAL timeline window — {start, duration} in composition frames. OMIT IT (the default) and the layer is ALWAYS PRESENT: a persistent overlay that holds for the whole composition, which is what an agent-placed watermark / lower-third almost always wants. Pass it to place a bounded CLIP instead (what the editor's own add does: 5 s at the playhead). Keyframes on a blocked layer are sampled RELATIVE to `start`.
colorNoFill colour as #rrggbb.
widthNo
heightNo
projectIdYesOpaque project id (a v4 UUID, from list_projects/create_project). Selects which existing project this call mutates.

Output Schema

TableJSON 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: -[
-  "kind",
-  "projectId",
-  "anonymousToken"
-]New value: +[
+  "kind",
+  "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: -[
-  "kind",
-  "projectId"
-]New value: +[
+  "kind",
+  "projectId",
+  "anonymousToken"
+]
  4. First observed

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already indicate non-read-only and non-destructive, and the description adds default positioning behavior plus the native-shape caveat. It does not disclose mutation consequences, reversibility, or return format, but the annotations carry the safety profile, so a mid score is appropriate.

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

Conciseness2/5

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

The description is bloated by a full enum list that duplicates the input schema, consuming most of the text. The genuinely useful guidance—native vector shapes, don't substitute an image, default centering—is buried at the end, so it is not lean or front-loaded.

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?

For an 8-parameter tool with a nested block object and no visible output schema, the description omits coordinate units, width/height semantics, and return value behavior. It is not complete enough for an agent to call it correctly without opening the schema and guessing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 38%; the description compensates by mentioning x/y/w/h default behavior, but it does not explain coordinate units, origin, or width/height semantics. It also repeats the entire kind enum already present in the schema, adding no new meaning for those parameters.

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?

"Add a shape layer" is a specific verb+resource and the note that these are native vector shapes (never substitute an image layer) differentiates it from add_image_layer. However, it doesn't explicitly name the sibling tools like add_text_layer or add_video_layer, so it's clear but not fully differentiated.

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 description implies usage for vector primitives and warns against using an image layer instead, which is a when-to-use signal. It also states default centering when x/y/w/h are omitted. But it never names alternative tools or gives explicit when-not-to-use conditions, so guidance is partial.

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

All Morpha toolsInspect
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