Skip to main content
Glama

Vidova

by ai.vidova
OverviewDiscussionsAdmin

Read an object track

read_track
Read-onlyIdempotent

Read an object track: its corners and box on each frame in any space (source pixels by default, or film, film_norm, clip), each frame's state (tracked, carried, lost) and quality score, and the track's quality verdict with its flagged ranges, e.g. "top right corner drifts off the surface from 4.30s". Use it to see which frames to fix before you pin to a track, and after a fix. Free.

Input Schema

NameRequiredDescriptionDefault
rangeYes[from, to] seconds to read (atSpace says what they are). null reads the whole track.
spaceYesThe space of the corners in the answer. null or source: pixels of the asset. source_norm: 0 to 1 of the asset. film: scene pixels from the frame's centre. film_tl: scene pixels from its top left. film_norm: 0 to 1 of the frame. clip: the clip's own picture. Film spaces need a clip that plays the asset at that second; a frame no clip shows has source corners only.
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.
detailYesHow many frames the answer lists: brief lists 12, normal (null) 60, full every frame up to 600 with each frame's quality reasons. Frames are picked evenly over the range, and the first frame of each flagged range is always listed.
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).
trackIdYesThe object track id, as the tracking tool printed it or search_assets lists it (objectTracks).
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. Added

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover readOnly/idempotent/non-destructive, so the description rightly spends its words elsewhere: it discloses the return contents (per-frame state labels tracked/carried/lost, quality score, verdict with flagged ranges) and a concrete example verdict, plus that the call is free. It stops short of stating cost-free/truncation limits at the response level (the detail cap only appears in the schema).

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-loaded with what is returned, followed by the usage sentence and a concrete example verdict. The space list in the description is slightly redundant with the schema enum, but every sentence otherwise earns its place.

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 no output schema, the description carries the return-value burden and does so: corners/box, per-frame state, quality score, verdict and flagged ranges. What remains thin is response shape/format (e.g. how flagged ranges and truncated frame lists are structured), which is only implied.

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 explains range, space, clipId, detail and atSpace in detail. The description only adds the default ('source pixels by default') and a loose paraphrase of the space list, which the enum already documents. Baseline 3 is appropriate.

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 ('Read an object track') and enumerates the payload: per-frame corners/box, per-frame state, quality scores, and the track's quality verdict with flagged ranges. It is clearly distinct from mutating siblings such as edit_track, smooth_track, track_box and fix_film.

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 explicit when-to-use context: 'to see which frames to fix before you pin to a track, and after a fix.' That is a clear workflow placement, though it never names a specific alternative tool (e.g. read_points, read_points vs read_track) for exclusion.

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