Skip to main content
Glama

Viral Manager

upload_asset

Add a video file to the asset library (mp4, mov, avi, webm, mkv, m4v; max 500 MB). Two modes. (1) With source_url: the server downloads the file from that public URL itself and creates the asset in one call (needs a Content-Length; large or slow files may time out, then use mode 2). (2) Without source_url: returns an upload_url; PUT the raw file bytes to it with the returned Content-Type header (e.g. curl -X PUT -H 'Content-Type: video/mp4' --data-binary @file.mp4 '<upload_url>'), then call confirm_asset_upload with the upload_id and the name/notes/category/tags. A video already in the library (same name and size, or same exact size) is not imported twice: its existing asset is returned with duplicate=true. Analysis: edits are never used for asset matching, so they are not AI-analyzed: they only get a thumbnail and their duration (analysis=skipped_not_in_matching). Raw footage (kind='rush') is always analyzed. If you rendered the file on the user's computer, delete it once this call succeeds.

Input Schema

NameRequiredDescriptionDefault
kindNo'edit' (default) = a finished reel/edit to be posted. 'rush' = raw footage meant for asset matching (e.g. migrating a library): always fully AI-analyzed.edit
nameNoAsset name. Empty = the file name without its extension.
tagsNoCustom tags
notesNoInternal notes saved on the asset (e.g. the caption or brief that came with the file)
categoryNoCategory (id or name). Empty = none.
file_nameNoPresigned mode only: file name with its extension (e.g. clip.mp4), required.
source_urlNoPublic URL of the video to import. Empty = presigned upload mode.
file_size_bytesNoPresigned mode only: file size, used to check the storage quota up front (0 = checked at confirm).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / kind
      Added value: +{
      +  "default": "edit",
      +  "description": "'edit' (default) = a finished reel/edit to be posted. 'rush' = raw footage meant for asset matching (e.g. migrating a library): always fully AI-analyzed.",
      +  "enum": [
      +    "edit",
      +    "rush"
      +  ],
      +  "type": "string"
      +}
  2. Added

TDQS

A4.4/5.0
Behavior3/5

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

Annotations declare openWorldHint=true and destructiveHint=false, but the description still adds substantial behavior of its own: the 500 MB ceiling, server-side download timeouts, the dedup rule (same name and size, or same exact size, returns the existing asset with duplicate=true), and the analysis split between 'edit' and 'rush'. The hint pair is not contradicted — deleting the local rendered file is explicitly a client-side action, not a server mutation — but the description never addresses the non-idempotent hint in terms of retry safety.

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 core action, format list, and size cap are front-loaded, and the two modes are numbered so the agent can branch quickly. The parenthetical nesting in the source_url and duplicate sentences is dense, but no sentence is filler.

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, and the description compensates by naming the key return values (upload_url plus Content-Type header, upload_id, duplicate=true) and the follow-up call needed to finish. For an eight-parameter, open-world upload tool, an agent has enough to select a mode, call it, and handle the response.

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 baseline would be 3, but the description earns more by explaining the consequence of kind='rush' (always AI-analyzed) versus edits (thumbnail and duration only, analysis=skipped_not_in_matching) — a downstream effect absent from the schema. It also frames source_url and file_name as mutually exclusive mode selectors rather than independent fields.

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 specific verb and resource ("Add a video file to the asset library"), then immediately bounds it with supported containers and a 500 MB cap. It also enumerates the two operational modes by name, so an agent can tell this apart from confirm_asset_upload or update_asset 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?

It states exactly when each mode applies: mode 1 requires source_url and a Content-Length, mode 2 is the fallback when a large or slow file times out. It also names the required follow-up call (confirm_asset_upload with upload_id plus name/notes/category/tags) and the local cleanup step, leaving nothing to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources