Vidova

Add files from the Library

add_from_library

Idempotent

Add files from the user's Library to the open project. Pass Library ids from search_library. Returns each file's Asset ID; place it with patch_film. A file the project already has returns its Asset ID again. A file that cannot be added, such as one in the Trash, is listed with the reason. A file still uploading is listed too: call wait_for_asset with its Library id, as the NEXT line says, which adds it once its upload lands. Nothing is copied or charged. If the answer says a video is still processing, call wait_for_asset with its Asset ID before you place it.

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": {
      "ids": "<ids>",
      "projectId": "<projectId>"
    },
    "name": "add_from_library"
  }
}

Input Schema

Name	Required	Description	Default
`ids`	Yes	Library ids from search_library, 1 to 200.
`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.

First observedOct 19, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare non-destructive, idempotent, non-open-world, but the description adds real behavior beyond them: nothing is copied or charged, already-present files return the same Asset ID, unusable files come back with a reason, and in-flight uploads must be resolved via wait_for_asset. Minor deduction for the opaque phrase "as the NEXT line says," which references something outside the description and reads as a leftover UI artifact.

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 in the first sentence and each subsequent sentence covers a distinct outcome or next step. There is mild redundancy: the wait_for_asset remedy is stated twice for two similar stalled states, and the "NEXT line" reference is a distracting pointer.

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 steps in to describe returns (Asset ID, per-file reasons, listed-but-not-added entries), which is exactly what an agent needs before calling. It stops short of clarifying whether partial success is possible in a batch of up to 200 ids, which is the main remaining ambiguity for a mutation tool.

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 coverage is 100%, and the schema itself already says ids come from search_library and that null projectId means the open project. The description reinforces but does not extend that, adding no format, bounds, or edge-case semantics for either parameter; baseline 3 applies when the schema carries the load.

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?

"Add files from the user's Library to the open project" gives a specific verb (add), source (Library), and destination (open project), and it is clearly separable from siblings like search_library (the id source), patch_film (placement), and wait_for_asset (stuck uploads). An agent can pick this tool without opening the 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?

The description explicitly routes the agent: get ids from search_library, call this to add, then use patch_film to place the returned Asset ID, and call wait_for_asset when a file is still uploading or a video is still processing. It also covers the failure case (Trash) and the already-present case, so the when/when-not decision is fully specified.

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.