AwesomeVideo

Upload a file

upload

Destructive

Free. Put your own video or audio file into AwesomeVideo and get a fileId for caption_video, transcribe, burn_captions, create_clips, remove_silences or preview. action start: one single-use PUT URL (valid 15 min, files up to 80 MB); start_multipart: parts[] of PUT URLs for files over 80 MB (up to 2048 MB / 3 h) or flaky connections; status: missingParts of a multipart upload; complete: finish a multipart upload after every part is PUT; abort: cancel an unfinished multipart upload (deletes its parts); inline: send a clip of up to 10 MB as base64 in one call. For a public link use import_url instead. Up to 30 uploads per hour.

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": {
      "action": "<action>"
    },
    "name": "upload"
  }
}

Input Schema

Name	Required	Description
`data`	No	File bytes as base64 (a data: URL prefix is accepted).
`action`	Yes	start (single PUT URL), start_multipart, status, complete, abort, or inline (base64 up to 10 MB).
`fileId`	No	fileId from upload {action:'start_multipart'}.
`filename`	No	File name, e.g. clip.mp4.
`sizeBytes`	No	Exact file size in bytes (the PUT must match).
`contentType`	No	video/* or audio/*, e.g. video/mp4.
`partSizeBytes`	No	Bytes per part, 5242880-99614720. Default 67108864 (64 MB).

Output Schema

Name	Required	Description
`total`	No	Total number of items (paginated lists).
`result`	No	The value, when the tool returns something other than an object.
`hasMore`	No	true when more items are available (paginated lists).
`nextCursor`	No	Pass as cursor for the next page (paginated lists).

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 1, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and non-idempotent, and the description adds behavior beyond them: PUT URL validity of 15 minutes, the 80 MB / 2048 MB ceilings, that abort deletes the upload's parts, and a rate limit of 30 uploads per hour. That is real operational context (expiry, destructive side effect, throttling) rather than a restatement of the hints.

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 'Free.' then the purpose, then a tight action breakdown, then the alternative and the rate limit. Every clause carries information, but the action list is packed into one run-on sentence where a compact list would have made the mode boundaries faster to scan.

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?

For a 7-parameter, enum-driven, multi-mode upload tool with an output schema, the description covers the decision surface completely: mode selection, size/duration limits, expiry, cleanup semantics, rate limit, and the alternative tool. Return values are covered by the output schema, so nothing an agent needs to invoke it 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 description coverage is 100%, so the schema already documents data, fileId, filename, sizeBytes, contentType and partSizeBytes, making 3 the baseline. The description still adds semantics the schema does not: which action consumes which parameters (fileId for status/complete/abort, parts[] from start_multipart), the 80 MB threshold that selects start vs start_multipart, and the 10 MB inline cap.

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 concrete verb and resource ('Put your own video or audio file into AwesomeVideo') and immediately names the outcome and downstream consumers (fileId for caption_video, transcribe, burn_captions, create_clips, remove_silences, preview). An agent can distinguish this from siblings like import_url or batch 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 six action modes are each tied to a concrete condition: start for a single PUT URL under 80 MB, start_multipart for files over 80 MB / 3 h or flaky connections, status for missingParts, complete after all parts are PUT, abort to cancel, inline for base64 clips up to 10 MB. It also routes away from the tool for public links ('use import_url instead'), which is exactly the sibling differentiation an agent needs.

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

All AwesomeVideo 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?