Skip to main content
Glama

Vidova

by ai.vidova
OverviewDiscussionsAdmin

Search assets

search_assets
Read-onlyIdempotent

Search uploaded media by id, name, kind, mime type, transcript or brief (what the analysis saw: summary, subjects, setting, mood and tags, in English). Every word of the query must appear. An empty query lists every uploaded asset, one line each, with the brief of every file (what it shows, then its kind, setting, framing and mood), so one call shows the whole footage: plan from it, and use it to tell apart takes of the same scene. When a project has more files than one answer holds, the listing says the offset to call again with for the rest. Each line includes truncated per-field metadata, hasAudio for videos and sounds, analysis (analyzing with its progress, or ready with its brief), and transcript status (none, pending, processing, completed, error) with segmentCount when completed. Matching a query uses transcript text inside the tool; the model does not receive that text. If transcript.status is completed, the asset already has a transcript; do not call transcribe_asset again. Use read_asset with id to read one asset whole: its full brief with moments and quotes, pixels when available (the image, or a timestamped contact sheet for video) and metadata. Call read_analysis_range to read transcript rows, beat times or track frames. Uploads still in progress are listed too, from the moment the user starts them on any device: preparing is set while an asset uploads or encodes (stage uploading, processing or failed). It is not usable yet; call wait_for_asset with the ids of every asset you need, in one call, before placing or analyzing them. Does not list TypeScript components; use read_component. Does not list the published elements library; use search_elements. Video assets include libraryId, the id of their Library copy, once their cloud upload has started; null means the video is only on this device so far. The Video Intelligence tools (search_video_moments, analyze_video, index_video, read_video_intelligence) take a video's Asset ID or its libraryId as mediaId. Lists only this project's media; the user's other uploads are in their Library: use search_library.

Input Schema

NameRequiredDescriptionDefault
limitYesMost files to list, 1 to 500. null lists as many as fit one answer and says the offset of the rest.
queryYesEmpty lists every asset.
offsetYesFiles to skip: the offset a listing says to call again with, for the next files. null starts at the first.
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. Changed3 schema fields changed
    • addedInput schema / properties / limit
      Added value: +{
+  "anyOf": [
+    {
+      "maximum": 500,
+      "minimum": 1,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Most files to list, 1 to 500. null lists as many as fit one answer and says the offset of the rest."
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "anyOf": [
+    {
+      "maximum": 9007199254740991,
+      "minimum": 0,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Files to skip: the offset a listing says to call again with, for the next files. null starts at the first."
+}
    • changedInput schema / required
      Previous value: -[
-  "query",
-  "projectId"
-]New value: +[
+  "query",
+  "offset",
+  "limit",
+  "projectId"
+]
  2. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real behavior beyond that: line-by-line return contents, pagination via a reported offset, uploads-in-progress appearing with a preparing stage, and the important note that transcript matching happens inside the tool and the model never receives the matched text. That last point is a non-obvious behavioral trait. It stops short of 5 only because return-shape details are dense prose rather than a crisp contract.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The content is largely load-bearing and front-loaded with searchable fields, but it is delivered as one very long run-on paragraph mixing purpose, return shape, sibling routing and libraryId semantics. A short structured breakdown would make the same information far easier to scan.

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?

With no output schema, the description carries the return-value burden and does so thoroughly: per-line truncated metadata, hasAudio, analysis state with progress, transcript status plus segmentCount, and libraryId presence/nulling. Pagination and in-progress uploads are also covered, so an agent can call this correctly and interpret the result.

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. The description earns above baseline by specifying query matching semantics ('Every word of the query must appear' — conjunctive, not fuzzy) and by tying offset to the value a previous listing returns, which the schema alone does not convey.

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 (search uploaded media) and enumerates exactly what is searchable: id, name, kind, mime type, transcript and brief. It explicitly carves itself out from siblings — read_component, search_elements, search_library — so an agent can pick it without opening any 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 when-to-use routing: read_asset for one asset whole, read_analysis_range for transcript rows/beats/frames, search_library for the user's other uploads, wait_for_asset before placing or analyzing. It also states the empty-query use case (plan from the full footage, tell apart takes of the same scene) and warns not to re-call transcribe_asset when transcript.status is completed.

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