Vidova

Track a found object

track_detection

Track a numbered detection from the latest find_objects result on this asset. Specify the source-time range (or a film range with atSpace timeline), fps (null samples every frame of the footage, for a follow or a cover; 8 to look), and label; do not lower fps or split a long clip. Uses about 9.7 credits a minute of the range, billed by the second. Read builtin-object-tracking first.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "assetId": "<assetId>",
      "startTime": "<startTime>",
      "endTime": "<endTime>",
      "fps": "<fps>",
      "label": "<label>",
      "detail": "<detail>",
      "detection": "<detection>",
      "clipId": "<clipId>",
      "atSpace": "<atSpace>",
      "projectId": "<projectId>"
    },
    "name": "track_detection"
  }
}

Input Schema

Name	Required	Description
`fps`	Yes	Samples a second, 1 to 30. null samples every frame of the footage on its own frame times (every second frame of 50 or 60 fps footage): use it for a pin, a cover or a follow. 8 is enough to look. An fps above the footage's repeats frames.
`label`	Yes
`clipId`	Yes	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.
`detail`	Yes	brief: the track id, its verdict and the flagged ranges, with no contact sheet. normal (null): the answer and its contact sheet. full: the same, as normal for now.
`assetId`	Yes
`atSpace`	Yes	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).
`endTime`	Yes
`detection`	Yes
`projectId`	Yes	The 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.
`startTime`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedOct 25, 2026

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

addedInput schema / properties / detail

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "brief",
+        "normal",
+        "full"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "brief: the track id, its verdict and the flagged ranges, with no contact sheet. normal (null): the answer and its contact sheet. full: the same, as normal for now."
+}

addedInput schema / properties / fps / anyOf

Added value: +[
+  {
+    "maximum": 30,
+    "minimum": 1,
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / fps / description

Added value: +"Samples a second, 1 to 30. null samples every frame of the footage on its own frame times (every second frame of 50 or 60 fps footage): use it for a pin, a cover or a follow. 8 is enough to look. An fps above the footage's repeats frames."

removedInput schema / properties / fps / maximum
```
Removed value: -30
```
removedInput schema / properties / fps / minimum
```
Removed value: -1
```
removedInput schema / properties / fps / type
```
Removed value: -"integer"
```

changedInput schema / required

Previous value: -[
-  "assetId",
-  "startTime",
-  "endTime",
-  "fps",
-  "label",
-  "detection",
-  "projectId"
-]New value: +[
+  "assetId",
+  "startTime",
+  "endTime",
+  "fps",
+  "label",
+  "detail",
+  "detection",
+  "clipId",
+  "atSpace",
+  "projectId"
+]

Changed1 schema field changedOct 21, 2026
- changedInput schema / properties / fps / maximum
```
Previous value: -15New value: +30
```
First observedOct 19, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations only say the call is mutating and non-destructive; the description adds substantive context the annotations cannot: a cost model (about 9.7 credits a minute of the range, billed by the second), a required prior read, and operational limits on fps and clip length. It does not explain whether an existing track is replaced or duplicated, which is the main remaining behavioral gap.

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?

Purpose is front-loaded in the first sentence, followed by constraints, then cost, then the prerequisite read — a sensible order. The parenthetical on fps repeats the schema description almost verbatim, and the semicolon chain makes the middle sentence dense, but nothing is truly extraneous.

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

Completeness4/5

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

For a 10-required-parameter mutation with no output schema, the description covers purpose, input provenance, cost, prerequisite documentation, and key usage limits. The gaps (meaning of label, behavior when a track already exists, staleness of the referenced detection) are real but narrow.

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?

With 50% schema coverage, the description compensates partially: it clarifies startTime/endTime as a source-time range (or film range when atSpace is timeline) and ties detection to a numbered entry from find_objects. However, label and assetId get no added meaning, and the fps parenthetical largely restates what the schema already documents.

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?

"Track a numbered detection from the latest find_objects result on this asset" gives a specific verb (track), a specific resource (a numbered detection), and the provenance of its input, which cleanly separates it from find_objects and from the region/pattern/face trackers. An agent can identify the operation without opening the schema.

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?

The description states the precondition (must come from the latest find_objects result), a prerequisite reading ("Read builtin-object-tracking first"), and two constraints ("do not lower fps or split a long clip"). It stops short of naming alternatives such as track_box or track_pattern when no detection exists, so the routing guidance is clear but not exhaustive.

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

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