Skip to main content
Glama

video_upload_link

Issues ONE presigned URL (1 h) to PUT the template's native VIDEO over HTTP, and returns its path, which goes in video of the listing (create_draft, update_draft, submit_for_review, resubmit_for_review). There is ONE video per template and it REPLACES the YouTube links, which are no longer accepted ([INVALID_DATA] if the old youtubeLinks field is sent with any link; an empty list is ignored). Upload the ORIGINAL as is (MP4, MOV or WebM, with the Content-Type you asked for) up to the size and length the answer gives (maxBytes, maxSeconds), THEN save its path in a draft or a submission, which is what queues it; the server converts it on its own to a single MP4 (H.264 + AAC, 720p or 1080p depending on the source, never upscaled) plus a still cover, stripping metadata such as location. You can submit while it is processing: the human review waits until it is ready, and my_draft and my_templates show video.status (queued, processing, ready, failed with its error). On submit the video is rejected with [FOREIGN_VIDEO] (not issued for your account), [VIDEO_NOT_UPLOADED], [VIDEO_TOO_LARGE] or [VIDEO_FAILED] (the processing rejected it: replace it or remove it with video: null).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
contentTypeYesContent-Type of the ORIGINAL you are going to upload: video/mp4 (MP4), video/quicktime (MOV) or video/webm (WebM). You must PUT it with this same header.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesThe path that goes in `video` of the listing (create_draft, update_draft, submit_for_review, resubmit_for_review).
maxBytesYesMaximum size of the original, in bytes.
expiresAtYesWhen the link expires, in ISO 8601.
expiresInYesThe same thing in plain language.
maxSecondsYesMaximum length, in seconds.
processingYesWhat happens after the upload and how to follow it.
contentTypeYesThe Content-Type the PUT must carry.
instructionsYesWhat to do now with this link.
presignedUrlYesPresigned URL: upload the original with ONE HTTP PUT and the same Content-Type.
maxResolutionYesResolution the published MP4 comes out at, at most (720p or 1080p; it is never upscaled).
acceptedFormatsYesContainers accepted, judged by the file's bytes.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so thoroughly: 1-hour expiry, one video per template, replacement of YouTube links, server-side transcoding to MP4 H.264+AAC with a still cover, metadata stripping, async processing with status values, and specific error codes ([FOREIGN_VIDEO], [VIDEO_NOT_UPLOADED], [VIDEO_TOO_LARGE], [VIDEO_FAILED]).

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?

The purpose is front-loaded, but the body is a dense run-on wall of text packing expiry, replacement rules, transcoding, async status, and four error codes into few sentences. The information is relevant, yet the size is heavy for a one-parameter tool and would benefit from structure.

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 tool with an output schema (so return values need no explanation) and a single fully-documented parameter, the description covers everything an agent needs: what it issues, how to use the path, conversion behavior, size/length limits returned by the response, and failure modes.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single enum parameter contentType is already fully documented in the schema, so the baseline is 3. The description reinforces that the PUT must carry the same Content-Type, but adds no new syntax or format beyond the schema.

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 specific verb and resource: 'Issues ONE presigned URL (1 h) to PUT the template's native VIDEO over HTTP'. It clearly distinguishes itself from the parallel upload tools (image_upload_link, evidence_upload_link, zip_upload_link) by naming the resource as the template's native video and clarifying it replaces the deprecated YouTube links.

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?

Explicitly describes the full workflow: issue URL, upload the original, then save the returned path in create_draft/update_draft/submit_for_review/resubmit_for_review to queue conversion. It also states the exclusion (YouTube links no longer accepted, [INVALID_DATA] if sent) and the submit-time rejection conditions, leaving almost 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