Skip to main content
Glama
Sign In

Vixdeo — Tu Productor IA

by com.vixdeo
OverviewDiscussionsAdmin

Register uploaded material

complete_upload
Idempotent

Confirms that uploads finished and registers them in the creator's personal library: one upload (handle) or several (uploads, each with its own outcome). Each file is verified without any provider being involved — it has to be in storage with the declared size and be real media; its content identifies it (the same file twice is one asset) and it is measured (kind, size, duration). declared_content is WHAT the material shows (≤240 chars): it is what lets a director place it on the right scene. The answer carries stage — uploading (the bytes are not all in storage yet) · verifying (the file is in storage and is being checked, identified by its content and measured) · ready (the file is in the library and has an assetId) · failed (the file did not make it into the library, and reason says why). Small files answer ready at once, with the assetId that places them on a scene; a larger one answers verifying, and the same request repeated later returns its current stage. 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. Registering an upload declares that the creator holds the rights to use the file in their pieces (Terms §5.1): the declaration is recorded for each upload (rightsDeclaration: the version, hash and language of its text, served at /api/legal/declarations/material). $0.

Input Schema

NameRequiredDescriptionDefault
handleNoOne upload: the `handle` of its ticket.
speakerNoWho speaks in the recording: `el_autor` (the creator), `otra_persona` (another real person, not the creator), `nadie` (nobody speaks) or `sin_declarar` (not stated; clears a previous statement). It belongs to the file, so it holds in every piece that uses it.
uploadsNoSeveral uploads at once; the answer has one outcome per item, in the same order.
speaker_nameNoThe name of the other person who speaks; only with `speaker: otra_persona`.
declared_contentNoWhat the material shows, e.g. 'Interview with the harbour master, 2024, dock in background'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / speaker
      Added value: +{
+  "description": "Who speaks in the recording: `el_autor` (the creator), `otra_persona` (another real person, not the creator), `nadie` (nobody speaks) or `sin_declarar` (not stated; clears a previous statement). It belongs to the file, so it holds in every piece that uses it.",
+  "enum": [
+    "el_autor",
+    "otra_persona",
+    "nadie",
+    "sin_declarar"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / speaker_name
      Added value: +{
+  "description": "The name of the other person who speaks; only with `speaker: otra_persona`.",
+  "type": "string"
+}
    • addedInput schema / properties / uploads / items / properties / speaker
      Added value: +{
+  "description": "Who speaks in the recording: `el_autor` (the creator), `otra_persona` (another real person, not the creator), `nadie` (nobody speaks) or `sin_declarar` (not stated; clears a previous statement). It belongs to the file, so it holds in every piece that uses it.",
+  "enum": [
+    "el_autor",
+    "otra_persona",
+    "nadie",
+    "sin_declarar"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / uploads / items / properties / speaker_name
      Added value: +{
+  "description": "The name of the other person who speaks; only with `speaker: otra_persona`.",
+  "type": "string"
+}
  2. Changed4 schema fields changed
    • addedInput schema / anyOf
      Added value: +[
+  {
+    "required": [
+      "handle"
+    ]
+  },
+  {
+    "required": [
+      "uploads"
+    ]
+  }
+]
    • changedInput schema / properties / handle / description
      Previous value: -"The `handle` of the upload ticket."New value: +"One upload: the `handle` of its ticket."
    • addedInput schema / properties / uploads
      Added value: +{
+  "description": "Several uploads at once; the answer has one outcome per item, in the same order.",
+  "items": {
+    "properties": {
+      "declared_content": {
+        "description": "What this file shows.",
+        "type": "string"
+      },
+      "handle": {
+        "description": "The `handle` of the upload ticket.",
+        "type": "string"
+      }
+    },
+    "required": [
+      "handle"
+    ],
+    "type": "object"
+  },
+  "maxItems": 20,
+  "type": "array"
+}
    • changedInput schema / required
      Previous value: -[
-  "handle"
-]New value: +[]
  3. Changed1 schema field changed
    • changedInput schema / properties / handle / description
      Previous value: -"The `handle` from `request_upload`."New value: +"The `handle` of the upload ticket."
  4. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond annotations, it discloses the full asynchronous lifecycle (`uploading`/`verifying`/`ready`/`failed`), idempotent repeat behavior, the `ficha` enrichment stages, and that registration records a rights declaration under Terms §5.1. This is unusually rich behavioral context and is consistent with `idempotentHint: true`, `readOnlyHint: false`, and `destructiveHint: false`.

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?

The description is long and dense, but it is front-loaded with purpose and organized by lifecycle stage. Most sentences carry necessary information about the return states and rights declaration, though some parenthetical detail could be trimmed without losing meaning.

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 and a complex multi-stage response, the description fully explains the possible return states, the optional `ficha` stages, and the rights declaration record. An agent has everything needed to call the tool and interpret its 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 adds genuine meaning by explaining that `declared_content` is the director-facing description (≤240 chars) and that `uploads` returns one outcome per item in order. It does not add much for `speaker`/`speaker_name` beyond the schema, but the added context is meaningful.

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?

The description opens with a precise verb and resource: 'Confirms that uploads finished and registers them in the creator's personal library.' It distinguishes the single-upload (`handle`) and batch (`uploads`) forms, so an agent can tell exactly what the tool does and how it differs from `request_upload`.

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?

The trigger condition is clear — use it once uploads have finished, not to initiate them. It also explains that repeating the request is safe and returns the current stage. It doesn't explicitly name alternatives or when-not-to-use cases, but the context is strong enough for correct selection.

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 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