Skip to main content
Glama

Upload Editor Media

upload_editor_media

Put image, video or audio files into your real Switch Editor project. By default they land in the project's media bin only; pass place: true to also lay each one at the end of its track. Three ways: url (an https link to the file; Switch keeps a copy), video_id (one of your finished videos from list_my_videos, attached as it is), or bytes: call with presign=true (one file, or files: [...] for several), PUT each file to its upload_url within 2 hours (or use the resumable block, a TUS upload in 6 MB pieces that can resume for up to 24 hours, for a big file on a slow link), then call again with confirm: [the confirm objects from the presign answer] (several in one call; each keeps the place asked at presign) or confirm_path for one. Files up to 500 MB each. A video's scrub copy and frame strip are made in the background after the confirm (a long clip takes a few minutes; the original plays until they land).

Input Schema

NameRequiredDescriptionDefault
urlNoAn https link to the file to bring in (no presign needed).
kindNoWhat the file is.
mimeNoThe file type, for example video/mp4.
nameNoOptional name the media bin shows, if it should differ from the file name.
filesNoWith presign=true: several files at once; the answer has one upload per file, each with its own confirm object.
placeNotrue also puts the media at the end of its timeline track. Default false: the media bin only.
confirmNoAfter the uploads: the confirm objects from the presign answer, all attached in one call and one save.
presignNotrue on the first call: answers an upload_url to PUT the bytes to (and a resumable block) and the path to confirm.
filenameNoThe file name with its extension.
video_idNoOne of your finished videos (list_my_videos) to attach as it is.
file_sizeNoBytes; required for presign.
project_idYesThe Editor project id, from list_editor_projects.
confirm_pathNoThe path from the presign answer, on the second call after the PUT, to put the file in the project.
duration_secondsNoThe clip length in seconds, if known. A still image with none given is placed as a 5-second clip.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / confirm
      Added value: +{
      +  "description": "After the uploads: the confirm objects from the presign answer, all attached in one call and one save.",
      +  "items": {
      +    "properties": {
      +      "duration_seconds": {
      +        "type": "number"
      +      },
      +      "filename": {
      +        "type": "string"
      +      },
      +      "kind": {
      +        "enum": [
      +          "image",
      +          "video",
      +          "audio"
      +        ],
      +        "type": "string"
      +      },
      +      "mime": {
      +        "type": "string"
      +      },
      +      "name": {
      +        "type": "string"
      +      },
      +      "path": {
      +        "description": "storage_path from the presign answer.",
      +        "type": "string"
      +      },
      +      "place": {
      +        "type": "boolean"
      +      }
      +    },
      +    "required": [
      +      "path",
      +      "filename",
      +      "mime"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / properties / confirm_path / description
      Previous value: -"The path from the presign answer, on the second call after the PUT, to place the file in the project."New value: +"The path from the presign answer, on the second call after the PUT, to put the file in the project."
    • addedInput schema / properties / files
      Added value: +{
      +  "description": "With presign=true: several files at once; the answer has one upload per file, each with its own confirm object.",
      +  "items": {
      +    "properties": {
      +      "duration_seconds": {
      +        "type": "number"
      +      },
      +      "file_size": {
      +        "description": "Bytes.",
      +        "type": "integer"
      +      },
      +      "filename": {
      +        "description": "The file name with its extension.",
      +        "type": "string"
      +      },
      +      "kind": {
      +        "enum": [
      +          "image",
      +          "video",
      +          "audio"
      +        ],
      +        "type": "string"
      +      },
      +      "mime": {
      +        "description": "The file type, for example video/mp4.",
      +        "type": "string"
      +      },
      +      "name": {
      +        "description": "Optional name the media bin shows.",
      +        "type": "string"
      +      },
      +      "place": {
      +        "description": "This file only: true also puts it on the timeline (overrides the call's place).",
      +        "type": "boolean"
      +      }
      +    },
      +    "required": [
      +      "filename",
      +      "mime",
      +      "file_size"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
    • addedInput schema / properties / name
      Added value: +{
      +  "description": "Optional name the media bin shows, if it should differ from the file name.",
      +  "type": "string"
      +}
    • addedInput schema / properties / place
      Added value: +{
      +  "description": "true also puts the media at the end of its timeline track. Default false: the media bin only.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / presign / description
      Previous value: -"true on the first call: answers an upload_url to PUT the bytes to and the path to confirm."New value: +"true on the first call: answers an upload_url to PUT the bytes to (and a resumable block) and the path to confirm."
  2. Changed3 schema fields changed
    • addedInput schema / properties / url
      Added value: +{
      +  "description": "An https link to the file to bring in (no presign needed).",
      +  "type": "string"
      +}
    • addedInput schema / properties / video_id
      Added value: +{
      +  "description": "One of your finished videos (list_my_videos) to attach as it is.",
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "project_id",
      -  "kind"
      -]New value: +[
      +  "project_id"
      +]
  3. Changed7 schema fields changed
    • addedInput schema / properties / confirm_path / description
      Added value: +"The path from the presign answer, on the second call after the PUT, to place the file in the project."
    • addedInput schema / properties / duration_seconds / description
      Added value: +"The clip length in seconds, if known. A still image with none given is placed as a 5-second clip."
    • addedInput schema / properties / filename / description
      Added value: +"The file name with its extension."
    • addedInput schema / properties / kind / description
      Added value: +"What the file is."
    • addedInput schema / properties / mime / description
      Added value: +"The file type, for example video/mp4."
    • addedInput schema / properties / presign / description
      Added value: +"true on the first call: answers an upload_url to PUT the bytes to and the path to confirm."
    • addedInput schema / properties / project_id / description
      Added value: +"The Editor project id, from list_editor_projects."
  4. Added

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses the multi-call handshake (presign → PUT → confirm), the 2-hour PUT window, the 24-hour resumable TUS option with 6 MB chunks, the 500 MB per-file cap, and that scrub copy/frame strip are generated asynchronously in the background after confirm. These are exactly the operational constraints that cause failed calls if unknown.

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: the core action and the default (bin only) come first, then the modes, then the limits. It is one very dense paragraph, though — the three-mode breakdown and the resumable-window detail would read faster as structure, and a sentence or two is packed tighter than needed.

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 14 parameters and no output schema, the description still makes the call sequence unambiguous by describing what presign returns (upload_url, resumable block, path) and what must be fed back into confirm. An agent has everything needed to complete a full round trip without guessing.

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 adds sequencing semantics the schema cannot: confirm takes the confirm objects from the presign answer in one batch, confirm_path is the single-file second-call variant, and each confirm retains the place requested at presign. It does not restate formal types, which is fine given 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 tied to a named product surface: 'Put image, video or audio files into your real Switch Editor project.' The default behavior (media bin only) versus opted-in behavior (place on track) further narrows what the tool does, separating it from generic siblings like upload_media or add_editor_library_assets.

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 enumerates the three intake paths — url, video_id (from list_my_videos), and bytes via presign — and gives a selection rule for the resumable variant ('for a big file on a slow link'). It also tells the agent which sibling supplies the id (list_my_videos) and when to set place.

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