Vidova

Search the elements library

search_elements

Read-onlyIdempotent

Search the published Vidova elements library. Each result is one line: id, name, category and description (its first sentence when the query is empty, which lists every published element, a page at a time: the answer says the offset to read on from). A query matches ids, names, descriptions, categories and input names. Use read_element with id to load that element's inputDefs, thumbnail and preview video URLs, and TypeScript source. To use an element unchanged, call import_element with that id; then place it with patch_film. Load the source only to change it. Does not list uploaded media or project-local components. Does not publish elements.

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": {
      "query": "<query>",
      "offset": "<offset>",
      "limit": "<limit>",
      "projectId": "<projectId>"
    },
    "name": "search_elements"
  }
}

Input Schema

Name	Required	Description
`limit`	Yes	Most elements on the page, 1 to 200. null means 40.
`query`	Yes	Empty lists every published element.
`offset`	Yes	elements to skip: the offset the page before says to call again with. null starts at the first.
`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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 22, 2026

addedInput schema / properties / limit

Added value: +{
+  "anyOf": [
+    {
+      "maximum": 200,
+      "minimum": 1,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "Most elements on the page, 1 to 200. null means 40."
+}

addedInput schema / properties / offset

Added value: +{
+  "anyOf": [
+    {
+      "maximum": 9007199254740991,
+      "minimum": 0,
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "elements to skip: the offset the page before says to call again with. null starts at the first."
+}

changedInput schema / required

Previous value: -[
-  "query",
-  "projectId"
-]New value: +[
+  "query",
+  "offset",
+  "limit",
+  "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?

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, yet the description adds real behavioral detail the annotations cannot: the one-line result format, that empty query enumerates every published element page by page, that the response carries the next offset, and which fields a query matches against. It also states the exclusions (no uploaded media, no project-local components, no publishing).

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 purpose and result shape, then workflow routing, then exclusions — a sound order with no filler sentences. The single nested parenthetical about the first sentence / paging is dense enough to require a second read, which keeps it off a 5.

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?

No output schema exists, so the description must carry return-value information and does: the per-result line format, what an empty query returns, and how pagination terminates via the returned offset. Combined with the exclusions and the read_element/import_element handoffs, an agent has everything needed to call and continue paging correctly.

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 baseline is 3; the description earns above baseline by documenting match semantics ('A query matches ids, names, descriptions, categories and input names') and by explaining that offset comes from the previous page's answer, both of which go beyond the schema text. It does not restate limit's default or the projectId scoping rules, which the schema already covers well.

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 the published Vidova elements library') and immediately scopes it against near-neighbors by declaring what it does NOT cover: uploaded media, project-local components, and publishing. The result shape (id, name, category, description) further pins down what this tool rather than any search_* sibling returns.

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?

Names the follow-on alternatives explicitly and the condition selecting each: read_element to get inputDefs/thumbnail/source, import_element to use an element unchanged, patch_film to place it, plus 'Load the source only to change it.' That is a full routing rule, not just a context hint.

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.