Vidova

Check Video Intelligence

read_video_intelligence

Read-onlyIdempotent

Read Video Intelligence progress for a video. mediaId is the video's Asset ID from search_assets or its Library id. jobId null reads the whole video's index; pass the jobId that index_video (for a range) or analyze_video returned to read that job. waitSeconds 1–25 waits for a status change or deadline, without starting work or using credits; in the chat a wait goes on while the job runs, up to about two minutes. If canWait remains true, call again. disabled, upgrade_required, quota_exceeded, unsupported and failed are terminal: do not loop waiting or silently restart them. reason says why the job stopped and what to change. waiting_for_upload means upload/encoding must finish first; not_indexed means call index_video if wanted. Ready analysis jobs include their answer in result; note says how to read the answer's times.

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": {
      "mediaId": "<mediaId>",
      "jobId": "<jobId>",
      "waitSeconds": "<waitSeconds>",
      "projectId": "<projectId>"
    },
    "name": "read_video_intelligence"
  }
}

Input Schema

Name	Required	Description
`jobId`	Yes
`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.
`waitSeconds`	Yes

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",
-  "jobId",
-  "waitSeconds"
-]New value: +[
+  "mediaId",
+  "jobId",
+  "waitSeconds",
+  "projectId"
+]

First observedOct 19, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds behavior annotations cannot express: waiting 1–25s does not start work or consume credits, a chat wait may run about two minutes, canWait signals whether to poll again, and disabled/upgrade_required/quota_exceeded/unsupported/failed are terminal. It also explains that reason describes why a job stopped and that waiting_for_upload and not_indexed have specific next steps.

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 the core purpose, then parameter behavior, then state-machine guidance; every sentence carries operational information. It is dense and runs several clauses together in one paragraph, which slightly reduces scanability, but there is no filler to cut.

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 polling tool with an output schema and rich annotations, the description covers the remaining unknowns: how to choose jobId, how waiting behaves, how to interpret terminal versus retryable states, and where the answer appears. Nothing an agent needs to call or loop correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 50%, but the description fully documents the two undocumented parameters: jobId's null-vs-specific-job meaning and waitSeconds' 1–25 wait-for-change-or-deadline semantics including its credit-free nature. It also reiterates mediaId's provenance (search_assets Asset ID or Library id) and explains result/note fields for ready analysis jobs, compensating well for the schema gap.

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 Video Intelligence progress for a video) and immediately distinguishes the two modes: whole-video index when jobId is null versus a specific job returned by index_video or analyze_video. Sibling tools index_video and analyze_video are named as the producers of jobId, so the agent can place this tool in the workflow without opening another 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?

Gives explicit routing rules: pass null to read the whole index, pass the jobId from index_video/analyze_video to read that job, call again while canWait is true, do not loop on terminal states, and call index_video when the status is not_indexed. When-not-to-act guidance (do not silently restart terminal jobs) is unusually specific.

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.