Vidova

Track faces

track_faces

Find and follow every face in a source-time range of a ready video. Returns a track id per face, most seen first, with when and where each is on screen, and a sheet with the faces numbered. Specify startTime, endTime and fps (normally 10). A shot change starts new tracks. Uses about 9.7 credits a minute of the range, billed by the second. Bind a track with . 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>",
      "projectId": "<projectId>"
    },
    "name": "track_faces"
  }
}

Input Schema

Name	Required	Description
`fps`	Yes
`assetId`	Yes
`endTime`	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.

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

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the annotations, it discloses cost and billing granularity ('about 9.7 credits a minute of the range, billed by the second'), the shot-change behavior that splits tracks, the ordering of results, and the extra output artifact (a numbered face sheet). These are material operational traits an agent could not infer from readOnlyHint=false and destructiveHint=false.

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 what/return/cost/prerequisite information is front-loaded in tight sentences with no filler. The middle sentences are somewhat list-like, but each carries distinct information an agent needs, so nothing is genuinely wasteful.

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?

With five required parameters, no output schema, and no idempotency, the description covers the return format, cost, ordering, track-splitting behavior, and the prerequisite doc read. The main remaining gap is that assetId's requirements (what makes a video 'ready') are only hinted at.

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 low at 20%, and the description compensates for some of that: it explains startTime/endTime as a source-time range and gives a realistic value for fps. However, assetId and its 'ready video' precondition are only implied, and projectId semantics are left entirely to the schema, so compensation is partial.

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 opens with a specific verb+resource: 'Find and follow every face in a source-time range of a ready video,' and it names the scope (source-time range, ready video) that separates it from unrelated siblings like track_box or track_points. It also previews the return shape (track id per face, most-seen-first), so an agent knows what it gets without opening 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 Guidelines4/5

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

It gives a concrete prerequisite ('Read builtin-object-tracking first') and a practical default for fps ('normally 10'), plus a hint on downstream binding ('Bind a track with <follow>'). It stops short of explicit when-not guidance or naming an alternative tracking tool, so it is strong context rather than full routing.

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.