Skip to main content
Glama
Sign In

cuttingfloor

by io.github.Mvp2o-ai
OverviewDiscussionsAdmin

Sync offset

media.correlate
Idempotent

Find how far one recording sits from another: the sync offset of b against a, by cross-correlating their sound, with how strongly they match. Use it to line up a camera with a separate microphone, two cameras of the same moment, or a re-recorded line against the original. Each side is imported media or an edit's mix (timeline_id), over its own from_seconds to until_seconds, so you can match a short stretch of b against a longer stretch of a. offset_seconds: b's moment t lines up with a's moment t + offset_seconds, each in its own seconds. To line them up on a timeline, place b's clip so it starts offset_seconds later than a's (earlier when negative), source starts being equal. strength is the correlation of the overlapping sound at that offset, -1 to 1: near 1 the same sound, near 0 unrelated; next_best is the best offset outside the winning peak, and a strength close to it means the match is unclear (repetitive sound, or not the same moment). Offsets are searched up to max_offset_seconds either way, where at least half of the shorter sound overlaps the other. Up to 600 s read from each side. A side with no sound in its range (no audio stream, a range past its end, or digital silence) fails with no_audio, naming which side. Short reads answer at once; longer ones return a task or job.

Input Schema

NameRequiredDescriptionDefault
aYesThe sound to line up against: the reference
bYesThe sound whose offset you want
idempotency_keyNo
max_offset_secondsYesSearch offsets up to this far either way

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / anyOf
      Previous value: -[
-  {
-    "properties": {
-      "next_best": {
-        "anyOf": [
-          {
-            "properties": {
-              "offset_seconds": {
-                "type": "number"
-              },
-              "strength": {
-                "type": "number"
-              }
-            },
-            "required": [
-              "offset_seconds",
-              "strength"
-            ],
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "description": "The best offset outside the winning peak: close to strength means an unclear match"
-      },
-      "offset_seconds": {
-        "description": "b's moment t lines up with a's moment t + offset_seconds, each in its own seconds; null when the sounds can't overlap by half within max_offset_seconds",
-        "type": [
-          "number",
-          "null"
-        ]
-      },
-      "overlap_seconds": {
-        "description": "How much sound overlaps at that offset",
-        "type": [
-          "number",
-          "null"
-        ]
-      },
-      "placement": {
-        "description": "offset_seconds as where to place b on a timeline, in plain words",
-        "type": [
-          "string",
-          "null"
-        ]
-      },
-      "strength": {
-        "description": "Correlation of the overlapping sound at that offset, -1 to 1: near 1 the same sound, near 0 unrelated",
-        "type": [
-          "number",
-          "null"
-        ]
-      }
-    },
-    "required": [
-      "offset_seconds",
-      "strength",
-      "overlap_seconds",
-      "next_best"
-    ],
-    "type": "object"
-  },
-  {
-    "properties": {
-      "hint": {
-        "type": "string"
-      },
-      "job_id": {
-        "description": "Job handle; the same value is the MCP task id",
-        "pattern": "^j_[0-9a-z]{26}$",
-        "type": "string"
-      },
-      "media_id": {
-        "description": "The media it is making; usable in edits once processing",
-        "pattern": "^m_[0-9a-z]{26}$",
-        "type": "string"
-      },
-      "status": {
-        "enum": [
-          "working",
-          "completed",
-          "failed",
-          "cancelled"
-        ],
-        "type": "string"
-      },
-      "status_uri": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "job_id",
-      "status",
-      "status_uri",
-      "hint"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "properties": {
+      "next_best": {
+        "anyOf": [
+          {
+            "properties": {
+              "offset_seconds": {
+                "type": "number"
+              },
+              "strength": {
+                "type": "number"
+              }
+            },
+            "required": [
+              "offset_seconds",
+              "strength"
+            ],
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "description": "The best offset outside the winning peak: close to strength means an unclear match"
+      },
+      "offset_seconds": {
+        "description": "b's moment t lines up with a's moment t + offset_seconds, each in its own seconds; null when the sounds can't overlap by half within max_offset_seconds",
+        "type": [
+          "number",
+          "null"
+        ]
+      },
+      "overlap_seconds": {
+        "description": "How much sound overlaps at that offset",
+        "type": [
+          "number",
+          "null"
+        ]
+      },
+      "placement": {
+        "description": "offset_seconds as where to place b on a timeline, in plain words. Trust it only once strength and next_best agree: two unrelated files still come back with a placement",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "strength": {
+        "description": "Correlation of the overlapping sound at that offset, -1 to 1: near 1 the same sound, near 0 unrelated",
+        "type": [
+          "number",
+          "null"
+        ]
+      }
+    },
+    "required": [
+      "offset_seconds",
+      "strength",
+      "overlap_seconds",
+      "next_best"
+    ],
+    "type": "object"
+  },
+  {
+    "properties": {
+      "hint": {
+        "type": "string"
+      },
+      "job_id": {
+        "description": "Job handle; the same value is the MCP task id",
+        "pattern": "^j_[0-9a-z]{26}$",
+        "type": "string"
+      },
+      "media_id": {
+        "description": "The media it is making; usable in edits once processing",
+        "pattern": "^m_[0-9a-z]{26}$",
+        "type": "string"
+      },
+      "status": {
+        "enum": [
+          "working",
+          "completed",
+          "failed",
+          "cancelled"
+        ],
+        "type": "string"
+      },
+      "status_uri": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "job_id",
+      "status",
+      "status_uri",
+      "hint"
+    ],
+    "type": "object"
+  }
+]
  2. Changed1 schema field changed
    • changedOutput schema / anyOf
      Previous value: -[
-  {
-    "properties": {
-      "next_best": {
-        "anyOf": [
-          {
-            "properties": {
-              "offset_seconds": {
-                "type": "number"
-              },
-              "strength": {
-                "type": "number"
-              }
-            },
-            "required": [
-              "offset_seconds",
-              "strength"
-            ],
-            "type": "object"
-          },
-          {
-            "type": "null"
-          }
-        ],
-        "description": "The best offset outside the winning peak: close to strength means an unclear match"
-      },
-      "offset_seconds": {
-        "description": "b's moment t lines up with a's moment t + offset_seconds, each in its own seconds; null when the sounds can't overlap by half within max_offset_seconds",
-        "type": [
-          "number",
-          "null"
-        ]
-      },
-      "overlap_seconds": {
-        "description": "How much sound overlaps at that offset",
-        "type": [
-          "number",
-          "null"
-        ]
-      },
-      "strength": {
-        "description": "Correlation of the overlapping sound at that offset, -1 to 1: near 1 the same sound, near 0 unrelated",
-        "type": [
-          "number",
-          "null"
-        ]
-      }
-    },
-    "required": [
-      "offset_seconds",
-      "strength",
-      "overlap_seconds",
-      "next_best"
-    ],
-    "type": "object"
-  },
-  {
-    "properties": {
-      "hint": {
-        "type": "string"
-      },
-      "job_id": {
-        "description": "Job handle; the same value is the MCP task id",
-        "pattern": "^j_[0-9a-z]{26}$",
-        "type": "string"
-      },
-      "media_id": {
-        "description": "The media it is making; usable in edits once processing",
-        "pattern": "^m_[0-9a-z]{26}$",
-        "type": "string"
-      },
-      "status": {
-        "enum": [
-          "working",
-          "completed",
-          "failed",
-          "cancelled"
-        ],
-        "type": "string"
-      },
-      "status_uri": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "job_id",
-      "status",
-      "status_uri",
-      "hint"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "properties": {
+      "next_best": {
+        "anyOf": [
+          {
+            "properties": {
+              "offset_seconds": {
+                "type": "number"
+              },
+              "strength": {
+                "type": "number"
+              }
+            },
+            "required": [
+              "offset_seconds",
+              "strength"
+            ],
+            "type": "object"
+          },
+          {
+            "type": "null"
+          }
+        ],
+        "description": "The best offset outside the winning peak: close to strength means an unclear match"
+      },
+      "offset_seconds": {
+        "description": "b's moment t lines up with a's moment t + offset_seconds, each in its own seconds; null when the sounds can't overlap by half within max_offset_seconds",
+        "type": [
+          "number",
+          "null"
+        ]
+      },
+      "overlap_seconds": {
+        "description": "How much sound overlaps at that offset",
+        "type": [
+          "number",
+          "null"
+        ]
+      },
+      "placement": {
+        "description": "offset_seconds as where to place b on a timeline, in plain words",
+        "type": [
+          "string",
+          "null"
+        ]
+      },
+      "strength": {
+        "description": "Correlation of the overlapping sound at that offset, -1 to 1: near 1 the same sound, near 0 unrelated",
+        "type": [
+          "number",
+          "null"
+        ]
+      }
+    },
+    "required": [
+      "offset_seconds",
+      "strength",
+      "overlap_seconds",
+      "next_best"
+    ],
+    "type": "object"
+  },
+  {
+    "properties": {
+      "hint": {
+        "type": "string"
+      },
+      "job_id": {
+        "description": "Job handle; the same value is the MCP task id",
+        "pattern": "^j_[0-9a-z]{26}$",
+        "type": "string"
+      },
+      "media_id": {
+        "description": "The media it is making; usable in edits once processing",
+        "pattern": "^m_[0-9a-z]{26}$",
+        "type": "string"
+      },
+      "status": {
+        "enum": [
+          "working",
+          "completed",
+          "failed",
+          "cancelled"
+        ],
+        "type": "string"
+      },
+      "status_uri": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "job_id",
+      "status",
+      "status_uri",
+      "hint"
+    ],
+    "type": "object"
+  }
+]
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: the search constraint that at least half of the shorter sound must overlap, the 600 s read cap per side, the no_audio failure mode with the failing side named, and the short-read-vs-task/job response split. It also explains how to interpret strength vs next_best to detect ambiguous matches, which the annotations cannot convey.

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?

Front-loads the purpose and use cases, then moves through the offset semantics, strength interpretation, search limits, and failure modes in a logical order. It is dense and slightly long, but nearly every clause carries operational information; only the placement note about nudging b's clip is arguably extra.

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 nested-object, async-capable tool with an output schema, the description covers inputs, sign conventions, search bounds, ambiguity detection, error behavior, and sync-vs-async returns. An agent has everything needed to invoke it and interpret the outcome.

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

Parameters4/5

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

Schema coverage is 75%, and the description fills the important gaps: it defines offset_seconds sign convention (b's t aligns with a's t + offset_seconds), explains that each side may be media or timeline_id with its own from/until range, and clarifies what max_offset_seconds actually constrains. The idempotency_key parameter is left unexplained, but it is a conventional field.

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: cross-correlate two recordings' sound to find the sync offset of b against a, plus a match strength. No sibling tool does this, and the description names the exact operation (cross-correlation) rather than a vague 'compare'.

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?

Gives three concrete use cases (camera with a separate mic, two cameras of the same moment, a re-recorded line against the original), which tells the agent when this is the right call. It stops short of naming alternatives or exclusion conditions, so it is clear context rather than full when/when-not guidance.

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

All cuttingfloor 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