Skip to main content
Glama

Vixdeo — Tu Productor IA

by com.vixdeo
OverviewDiscussionsAdmin

Request upload ticket

request_upload

Upload tickets for the creator's OWN material (a recorded interview, a product photo, drone footage, a recorded voice) so it can be kept in the personal library and placed in a piece. Three forms: one file (filename + size_bytes); a batch (files: one ticket per file, and a file that is refused carries its reason without stopping the others); or handle alone, which resumes an upload in parts — it returns the parts that arrived, the ones missing and signed URLs for the missing ones. The bytes travel outside this tool, straight to storage: a ticket's upload is one signed PUT (url + headers) or, with resumable, a list of parts — consecutive slices of partSizeBytes, each sent by PUT to its own url with its headers — that can be continued after an interruption until expiresAt (the session, about a day); each signed part url is valid until upload.partsExpireAt (about 1 h), and a 403 on a part past that is an expired url, not a failed upload: request_upload with only the handle re-signs the missing parts for free. The declared size is part of the signature. A video container that only carries sound (a browser recorder) is declared as audio/webm or audio/mp4 and is registered as audio. Each ticket states the limit per file in force (maxBytes) and the space in use (quota); a refusal says which limit was reached and with which numbers. Accepted: gif/heic/heif/jpeg/jpg/png/webp images, mov/mp4/webm video and aac/m4a/mp3/wav audio. $0.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filesNoA batch: one ticket per file, in the same order.
handleNoResumes an upload in parts: the `handle` of its ticket, with nothing else.
filenameNoOne file: its original filename with extension (the extension decides image, video or audio).
resumableNoDefault false. True asks for an upload in parts that can be resumed, for the single file or for every file of the batch; a file that fits in one part still gets one PUT.
size_bytesNoExact size of that file in bytes. Required with `filename`: the upload is signed for that size.
content_typeNoOptional MIME type of that file, accepted when it matches the extension.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • addedInput schema / anyOf
      Added value: +[
+  {
+    "required": [
+      "filename",
+      "size_bytes"
+    ]
+  },
+  {
+    "required": [
+      "files"
+    ]
+  },
+  {
+    "required": [
+      "handle"
+    ]
+  }
+]
    • changedInput schema / properties / content_type / description
      Previous value: -"Optional MIME type, accepted when it matches the extension."New value: +"Optional MIME type of that file, accepted when it matches the extension."
    • changedInput schema / properties / filename / description
      Previous value: -"Original filename with extension (decides image vs video)."New value: +"One file: its original filename with extension (the extension decides image, video or audio)."
    • addedInput schema / properties / files
      Added value: +{
+  "description": "A batch: one ticket per file, in the same order.",
+  "items": {
+    "properties": {
+      "content_type": {
+        "description": "Optional MIME type, accepted when it matches the extension.",
+        "type": "string"
+      },
+      "filename": {
+        "description": "Original filename with extension.",
+        "type": "string"
+      },
+      "size_bytes": {
+        "description": "Exact size of the file in bytes.",
+        "type": "integer"
+      }
+    },
+    "required": [
+      "filename",
+      "size_bytes"
+    ],
+    "type": "object"
+  },
+  "maxItems": 20,
+  "type": "array"
+}
    • addedInput schema / properties / handle
      Added value: +{
+  "description": "Resumes an upload in parts: the `handle` of its ticket, with nothing else.",
+  "type": "string"
+}
    • addedInput schema / properties / resumable
      Added value: +{
+  "description": "Default false. True asks for an upload in parts that can be resumed, for the single file or for every file of the batch; a file that fits in one part still gets one PUT.",
+  "type": "boolean"
+}
    • changedInput schema / properties / size_bytes / description
      Previous value: -"Optional size, checked against the cap before issuing the ticket."New value: +"Exact size of that file in bytes. Required with `filename`: the upload is signed for that size."
    • changedInput schema / required
      Previous value: -[
-  "filename"
-]New value: +[]
  2. Changed1 schema field changed
    • changedInput schema / properties / content_type / description
      Previous value: -"Optional MIME type; must match the extension."New value: +"Optional MIME type, accepted when it matches the extension."
  3. First observed

TDQS

A4.3/5.0
Behavior5/5

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

With only generic annotations (non-read-only, non-idempotent, non-destructive), the description carries real behavioral weight: signed-PUT mechanics, resumable parts that continue after interruption, expiresAt/partsExpireAt windows, and the crucial clarification that a 403 on an expired part is an expired URL rather than a failed upload and can be re-signed for free. Quota/maxBytes and refusal reporting are also disclosed.

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 and every sentence carries information, but it is delivered as one very dense paragraph with heavy nested parentheses and long em-dash clauses, which costs some scannability for a description of this size.

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?

There is no output schema, so the description must convey returns, and it does: ticket upload as a signed PUT or a list of parts, part expiry fields, handle-based re-signing, quota and maxBytes, and accepted content types. Nothing an agent needs to invoke and follow through correctly is missing.

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, but the description goes beyond the schema: it explains that handle alone resumes and returns arrived/missing parts, that a refused batch file carries its reason without aborting the rest, that the declared size is part of the signature, and how resumable changes the part layout.

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?

States a specific verb+resource: it issues upload tickets for the creator's own material and enumerates the three supported forms (single file, batch, resume-by-handle). It never names or distinguishes itself from the closest sibling, complete_upload, so an agent must infer the relationship from the flow described.

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?

Clearly explains which form to use in which situation (filename+size for one file, files for a batch, handle alone to resume) and states that bytes travel outside the tool. It stops short of explicit when-not-to-use or naming alternatives such as complete_upload.

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