Vidova

Index a video

index_video

Index a Library video so search_video_moments can search it, or index one range of it again with shorter segments. mediaId is the video's Asset ID from search_assets or its Library id. startSeconds and endSeconds null index the whole video: new uploads are indexed automatically unless disabled in global settings, so do that only for an older, disabled or failed video. Segment length follows the indexed length: 2 seconds for up to a minute, growing to 6 seconds at three minutes and longer. Index a range of at least 4 seconds when a search moment is too coarse for the question: take that moment's startSeconds and endSeconds, a few seconds wider on each side. A range that rows already cover at least as densely returns the existing job without a charge. Uses about 22 credits a minute of indexed video, billed by the second; an accepted submission keeps its credits even if it later fails or is deleted. It never prevents editing. Returns a job; wait for it with read_video_intelligence and its jobId before searching.

Input Schema

Name	Required	Description
`mediaId`	Yes	The video: its Asset ID from search_assets, or its Library id (libraryId from search_assets or read_asset, id from search_library).
`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.
`endSeconds`	Yes	Source seconds where the indexed range ends, at least 4 seconds after startSeconds. null with startSeconds null indexes the whole video.
`startSeconds`	Yes	Source seconds where the indexed range starts. null with endSeconds null indexes the whole video.

Output Schema

Name	Required	Description	Default
`kind`	Yes
`note`	Yes
`jobId`	Yes
`state`	Yes
`reason`	Yes
`result`	Yes
`canWait`	Yes
`mediaId`	Yes
`errorCode`	Yes
`updatedAt`	Yes
`endSeconds`	Yes
`startSeconds`	Yes
`pollAfterSeconds`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 27, 2026

changedOutput schema / properties / updatedAt / anyOf

Previous value: -[
-  {
-    "format": "date-time",
-    "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d(?::[0-5]\\d(?:\\.\\d+)?)?(?:Z))$",
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "format": "date-time",
+    "pattern": "^(?:(?:\\d\\d[2468][048]|\\d\\d[13579][26]|\\d\\d0[48]|[02468][048]00|[13579][26]00)-02-29|\\d{4}-(?:(?:0[13578]|1[02])-(?:0[1-9]|[12]\\d|3[01])|(?:0[469]|11)-(?:0[1-9]|[12]\\d|30)|(?:02)-(?:0[1-9]|1\\d|2[0-8])))T(?:(?:[01]\\d|2[0-3]):[0-5]\\d:[0-5]\\d(?:\\.\\d+)?(?:Z))$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

Changed2 schema fields changedOct 26, 2026

addedInput schema / properties / projectId

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "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."
+}

changedInput schema / required

Previous value: -[
-  "mediaId",
-  "startSeconds",
-  "endSeconds"
-]New value: +[
+  "mediaId",
+  "startSeconds",
+  "endSeconds",
+  "projectId"
+]

First observedOct 19, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations: pricing (about 22 credits per minute, billed by the second), the fact that credits are not refunded on failure or deletion, adaptive segment lengths by video duration, the minimum 4-second range, the dedup rule, that it does not block editing, and that it is asynchronous and must be polled via read_video_intelligence with the returned jobId. These are the exact behavioral facts an agent needs before committing spend.

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 and every sentence carries operational information, but the paragraph is dense and long, and the segment-length sentence sits awkwardly between the whole-video rule and the range-selection guidance. A slight restructure would improve scanning without cutting content.

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?

Output schema exists and the description still names the return type (a job) and the exact follow-up tool and field (read_video_intelligence with jobId). Combined with cost, dedup and safety notes, an agent has everything required to call this correctly and sequence the next step.

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 100%, so the baseline is 3, and the description does add real meaning: mediaId is the Asset ID from search_assets or a Library id, and null/null on both seconds means the whole video. The startSeconds/endSeconds pairing and the 4-second minimum are already in the schema, but the segment-length-by-duration rule is new information the schema does not carry.

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 ('Index a Library video') and immediately names the downstream consumer (search_video_moments) so the agent can place it in the pipeline. It also calls out the re-index-one-range variant, which separates it from any sibling that merely reads or searches video.

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?

Gives explicit when-to-use logic: whole-video indexing only for an older, disabled or failed video because new uploads are automatic; range indexing only when a search moment is too coarse, with instructions to widen the moment's bounds by a few seconds. It also states the no-op condition (densely covered range returns the existing job) so the agent can avoid a pointless call.

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.