Morpha

Clip processing status

clip_processing_status

Read-only

Report whether a clip — or every video clip in the project, if clip is omitted — has been through the browser-side video-processing pipeline: proxy build, audio split, transcription, OCR (text regions). Processing never runs on the server. The preview proxy is mandatory: every processing run builds it (client.addVideo / client.processClip / client.processProject in the morphareels-sdk npm client, which drive local Chrome), and the Morpha editor builds any missing proxy for every page's clip when the project is opened. The other steps run through the same npm client or in the editor. Returns { ok: true, data: { clips: [{ clip, processed, steps: { proxy, audio_split, transcript, text_regions } }], allProcessed } }, where each step is 'ready' | 'pending' | 'running' | 'unavailable' | 'cancelled' | 'error'. 'cancelled' is a transcript the user stopped in the editor: it stays stopped across opens, and only the editor's Re-run starts it again. audio_split stays 'pending' until the user splits the clip's audio into its own track in the editor (Inspector → Audio → Split audio) or the SDK's audio_split step runs; it never gates processed, and an unsplit clip plays its own sound. Use it to know whether transcribe_clip / detect_text_regions will return data, and to surface an 'unprocessed' state to the user.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`clip`	No	Optional clip filename (video.<id>.clip). Omit to report every video clip in the project.
`projectId`	Yes	Project the clip(s) belong to.

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

First observedSep 7, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already mark the tool read-only and non-destructive, and the description adds substantial context: client-side execution, mandatory preview proxy, editor behavior, state semantics including 'cancelled' persistence, and audio_split not gating `processed`. There is no contradiction with annotations.

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?

The description is long but front-loaded with the core purpose and scope. Every subsequent sentence earns its place by explaining states, client/editor execution, audio_split caveats, and the tool's use case. There is no filler or redundant repetition.

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?

The tool is complex enough to need the detailed state model, and the description covers it fully: output shape, allowed step values, cancellation behavior, audio_split semantics, and the relationship to transcribe_clip/detect_text_regions. The output schema exists and is complemented, not replaced, by the description.

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 the schema already documents both `projectId` and `clip`. The description reinforces the omission behavior of `clip` and adds pipeline context, but it does not add new parameter syntax or format details beyond what the schema provides.

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?

The description states a specific verb and resource: 'Report whether a clip — or every video clip in the project, if `clip` is omitted — has been through the browser-side video-processing pipeline.' It enumerates the pipeline steps and explicitly names sibling tools (transcribe_clip, detect_text_regions), making its purpose unmistakable.

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

Usage Guidelines5/5

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

It gives explicit when-to-use guidance: 'Use it to know whether transcribe_clip / detect_text_regions will return data, and to surface an unprocessed state to the user.' It also clarifies processing never runs on the server and explains audio_split behavior, preventing incorrect assumptions about when to call this tool.

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

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