Vidova

Create a link to add files

create_upload_link

Create a link where the person adds their own files to this project from any device. They open it, with no sign-in, drop videos, photos or audio, and watch each file upload, with no editor to load. Use it whenever their files are on their own device and you cannot read them: large files, many files, a phone, or when you cannot run upload commands on their machine. Returns url, the link. Give the person the whole link exactly as written and end your turn. It takes new files for 24 hours, up to 200 files and 100 GB. When they say they are done, call search_assets, which lists their files from the first byte with preparing set, then wait_for_asset with all their Asset IDs in one call.

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

Input Schema

Name	Required	Description	Default
`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.

AddedNov 8, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well past the annotations by disclosing what the link does operationally (no sign-in, no editor to load, per-file upload progress visible to the recipient) and stating hard limits: 24-hour intake window, 200 files, 100 GB. It also tells the agent what the tool returns ('url, the link') and how to hand it off, which the non-readOnly, non-idempotent annotations alone would never convey.

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 action and the key constraint ('person adds their own files', 'no sign-in'), then layered with limits and follow-up steps in a logical order. It is dense but nearly every clause carries actionable information; only the phrasing about watching each file upload is slightly incidental.

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 compensates by naming the return value and instructing the agent to pass the link through verbatim and end the turn. It also supplies the intake limits and the exact post-completion tool sequence, which covers what an agent needs for a multi-turn, human-in-the-loop handoff.

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?

There is only one parameter and the schema already documents it at 100% coverage, including the null-means-open-project fallback and the relationship to wait_for_jobs. The description adds no additional meaning about projectId, so the baseline 3 for fully covered schema applies.

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 artifact ('Create a link where the person adds their own files to this project') and immediately distinguishes it from direct-upload siblings by noting the recipient needs no sign-in and uploads from their own device. An agent can tell this apart from upload_files, begin_asset_upload, or import_asset_url without inspecting 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 an explicit use condition ('whenever their files are on their own device and you cannot read them') plus concrete triggers: large files, many files, a phone, or no ability to run upload commands on their machine. It also prescribes the follow-up sequence (search_assets, then wait_for_asset with all Asset IDs in one call), so the agent knows both when to call it and what to do after.

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.