Vixdeo — Tu Productor IA

List own material

list_material

Read-onlyIdempotent

The creator's own material in the personal library — assetId, kind, filename, what it declares, size, duration and how many times a piece uses it — and, in uploads, the uploads still in progress or refused in the last day, each with its stage and reason. kind keeps one kind of file; asset_id returns one file with its content hash; handle returns the state of one upload. After a file is verified it can carry a ficha: what the system saw and heard in it (measures, a description of the frames, what is said, faces), with its own stage — reading (what the file shows and what is said in it is being described; the file is usable meanwhile) · ready (the description is written; estado is partial when part of it could not be produced, and motivo says why) · failed (the file could not be described and motivo says why; the file itself is still usable). The file does not wait for it: once ready, its assetId is already valid as material of a new piece and as the material of a scene. origin chooses where the files came from: own (the default: what the creator uploaded) or declared_source (figures the system took from the sources the creator declared for a piece; each carries origin and its provenance — source page, credit, license and a stance: mountable, forbidden, permission_pending, citation), or all. A file whose speaker is stated, or in which the system heard a voice, carries speaker (who speaks in it: el_autor, otra_persona, nadie, sin_declarar), speakerName, speakerOrigin (declarado when someone stated it, canal_invitado when it is presumed because a guest sent it through an upload link, sin_declarar) and hearsVoice (the system heard a voice in it). Nothing is written. $0.

Input Schema

Name	Required	Description
`kind`	No	Only files of this kind.
`limit`	No	How many files to return, newest first.
`handle`	No	One upload, by the `handle` of its ticket: its `stage`, and its `assetId` once it is ready.
`origin`	No	Where the files came from: `own` (default) is what the creator uploaded; `declared_source`, the figures taken from the sources the creator declared; `all`, both. With `asset_id` the file is returned whatever its origin.
`asset_id`	No	One file of the library, by its `assetId`; the answer adds its content hash (`sha256`).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026

addedInput schema / properties / origin

Added value: +{
+  "description": "Where the files came from: `own` (default) is what the creator uploaded; `declared_source`, the figures taken from the sources the creator declared; `all`, both. With `asset_id` the file is returned whatever its origin.",
+  "enum": [
+    "own",
+    "declared_source",
+    "visual_citation",
+    "all"
+  ],
+  "type": "string"
+}

Changed4 schema fields changedOct 3, 2026

addedInput schema / properties / asset_id

Added value: +{
+  "description": "One file of the library, by its `assetId`; the answer adds its content hash (`sha256`).",
+  "type": "string"
+}

addedInput schema / properties / handle

Added value: +{
+  "description": "One upload, by the `handle` of its ticket: its `stage`, and its `assetId` once it is ready.",
+  "type": "string"
+}

addedInput schema / properties / kind

Added value: +{
+  "description": "Only files of this kind.",
+  "enum": [
+    "image",
+    "video",
+    "audio"
+  ],
+  "type": "string"
+}

addedInput schema / properties / limit / description

Added value: +"How many files to return, newest first."

First observedSep 27, 2026

TDQS

A4/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 confirms it tersely with "Nothing is written. $0." Beyond that it discloses real behavior: uploads can be in progress or refused within the last day with a `stage` and `reason`, and the `ficha` runs asynchronously through `reading`/`ready`/`failed` while the file stays usable, including a `partial` outcome. That is substantive context annotations cannot carry.

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?

It is a single dense block of run-on prose with em-dash chains and no bullets or sentences breaking the return-shape description from the filter description. Most content is load-bearing because there is no output schema, but the ficha-stage and speaker enumerations are packed tightly enough that an agent must parse carefully rather than skim.

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 full burden of explaining returns, and it does: row fields, the `uploads` collection, the `ficha` lifecycle, `origin`/`provenance` with `stance`, and the speaker fields. An agent can call this with all-zero arguments and still predict the response shape.

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 description coverage is 100%, so baseline would be 3. The description nonetheless adds meaning the schema does not: it explains the `origin` values concretely, notes that with `asset_id` the file is returned whatever its origin, and unpacks what `handle` and `asset_id` yields (upload state; content hash).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (the creator's own material in the personal library) and enumerates exactly what each row carries — `assetId`, kind, filename, declarations, size, duration, usage count — so the agent knows this is a filtered listing tool, not a fetch or mutation. It does not explicitly distinguish itself from sibling listers such as `list_cast` or `list_referents`, which keeps it short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the selection rules for the alternate modes: `kind` keeps one kind of file, `asset_id` returns a single file, `handle` returns one upload's state, and `origin` chooses the source bucket with a stated default. It also gives a genuinely useful timing rule — the file does not wait for its `ficha`, so its `assetId` is already valid as material. It stops short of naming when to prefer a sibling tool instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Vixdeo — Tu Productor IA 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.

Resources

Need Help?