Skip to main content
Glama
Sign In

Vidova

by ai.vidova
OverviewDiscussionsAdmin

Pin a moment to its frame

pin_moment
Read-onlyIdempotent

Find the exact frame of a moment in a ready video near a time you know roughly. Transcripts, search_video_moments and contact sheets place a moment to about half a second. A cut, a slow-down or a sound on an action needs its frame: a knife meeting the crust, a foot striking the ball, a door starting to open. It reads every frame and the sound around that time, a model picks the first frame that shows the moment, and a sound that starts right there sets the frame. Answers the source second (to the millisecond), the frame and the frame rate, what the frame shows and whether its sound starts on it, with a numbered sheet of the frames around it. Pin every cut, slow-down and sound that must land on an action. Uses about 0.43 credits a call.

Input Schema

NameRequiredDescriptionDefault
whatYesThe moment as it looks, in a few words: "the spatula first cuts into the crust".
aroundYesRoughly where the moment is, in source seconds of the asset: the time a transcript, search_video_moments or a contact sheet gave.
clipIdYesThe film clip that plays this asset, when space or atSpace needs one and several clips play it. null picks the clip that shows the asset at that time.
windowYesThe seconds to search, centred on around: 0.5 to 4, or null for 2.
assetIdYes
atSpaceYesWhat this call's times are. null or source: seconds into the asset file. timeline: seconds of the film, read through the clip that plays the asset then (clipId to pick one).
projectIdYesThe project this call runs on without changing the open project. null (or leaving it out) uses the open project. wait_for_jobs takes the projectId of the calls that started the jobs.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / around / description
      Previous value: -"Roughly where the moment is, in source seconds of the asset: the time its brief, a transcript, search_video_moments or a contact sheet gave."New value: +"Roughly where the moment is, in source seconds of the asset: the time a transcript, search_video_moments or a contact sheet gave."
  2. Changed3 schema fields changed
    • addedInput schema / properties / atSpace
      Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "source",
+        "timeline"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "What this call's times are. null or source: seconds into the asset file. timeline: seconds of the film, read through the clip that plays the asset then (clipId to pick one)."
+}
    • addedInput schema / properties / clipId
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "The film clip that plays this asset, when space or atSpace needs one and several clips play it. null picks the clip that shows the asset at that time."
+}
    • changedInput schema / required
      Previous value: -[
-  "assetId",
-  "around",
-  "what",
-  "window",
-  "projectId"
-]New value: +[
+  "assetId",
+  "around",
+  "what",
+  "window",
+  "clipId",
+  "atSpace",
+  "projectId"
+]
  3. Added

TDQS

A4.4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered; the description adds real value with the mechanism (frame scan plus audio, model picks first matching frame), the cost (about 0.43 credits per call) and the returned fields including sub-second time and frame rate. However, with no output schema, a stronger definition would say more about response shape and failure cases (e.g. what happens when no frame matches).

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 first sentence is front-loaded with the core purpose and the rest flows from precision limits to mechanics to output to usage rule. Some phrasing is redundant, such as the closing 'Pin every cut, slow-down and sound that must land on an action', which restates guidance given earlier, and the prose is denser than needed.

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 seven-parameter, no-output-schema tool, the description covers what it returns (source second to the millisecond, frame, frame rate, frame content, sound alignment, numbered sheet) and the cost of calling it. Nothing an agent needs in order to decide to call it or interpret the result is missing.

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 86%, so the baseline is 3, and the description earns above that by explaining where 'around' should come from (the time a transcript, search or contact sheet gave) and what 'what' is meant to capture. It does not add anything about 'window' beyond the schema's 0.5-4 range or the clipId/atSpace interaction already documented inline.

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 names a specific verb and resource: 'Find the exact frame of a moment in a ready video near a time you know roughly.' It directly contrasts itself with transcripts, search_video_moments and contact sheets, so an agent can pick it over those siblings without reading a schema.

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 lays out the alternative tools and their precision limit ('about half a second') and the condition that selects this one: cuts, slow-downs or sounds that must land on an action. It also gives a directive to use it for every such event, leaving little to inference.

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

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