Skip to main content
Glama

Start local file upload

upload_file_start

Start uploading a LOCAL video or image file from the user's machine into Flask. It needs a shell that can run curl; without one (a chat app), upload from a public link with upload_video. VIDEO: creates the asset immediately (container_id + shareable url, live before any bytes move) with the file as its version (asset_id / version_id), or a new version of an existing asset with version_of, and returns the shell command (next_step) that sends it while the user watches its progress at the url; then call upload_file_complete(asset_id). IMAGE (content_type image/png, image/jpeg, image/webp or image/gif, max 20MB): returns upload_url and image_url and creates NO asset yet; curl the bytes, then call upload_file_complete(image_url) with the folder_id / version_of / title / team_id you want - the asset is made there. On the free plan new assets are limited (web and agents together); a new version via version_of is always free. When the team has no free assets left, the upload is refused with a message that says how to continue. If the command fails, run it again (it resumes); calling upload_file_start again creates (and counts) another asset. Made with code? Pass notes and files (source.zip) here (an image or zip: to upload_file_complete): the version shows them from the start. LIVE ANIMATION (beta, selected teams): ONLY when the user asks to play an HTML/JS animation live (no render); by default render it and upload the MP4. Upload a zip (content_type application/zip, max 30MB): the page plus the files it loads, flask.json {"entry": "page.html"} (or index.html) at the top, nothing loaded from the network. The page must not run its own loop; it sets window.flaskComposition = { duration (seconds), seek(t) (draw the frame at t), width, height } and Flask calls seek. Returns upload_url and upload_id, NO asset yet; curl the zip, then upload_file_complete(upload_id) with folder_id / version_of / title / team_id. A zip Flask cannot play is refused there with what to fix, creating nothing.

Input Schema

NameRequiredDescriptionDefault
filesNoVideo only (an image or a zip: pass them to upload_file_complete). Files to attach to the version, sent with the upload: by convention the working files that made it as ONE source.zip (the project folder without node_modules, build output or renders; over 30 MB, split into source-1.zip, source-2.zip, ...). Max 30 MB each, 20 per version, names used once. Each comes back with its upload command: run it before the main upload.
notesNoVideo only (an image or a zip: pass it to upload_file_complete, where its version is made). The version's notes, in Markdown: what changed and why (link the feedback it answers), and how to continue (the tools, the command that renders it). Saved with the version, so it shows them from the start; each file's line is put above them for you. Up to 20,000 characters of text.
titleNoTitle for the new asset (defaults to "Untitled Video"). For an image, pass it to upload_file_complete instead.
team_idNoTeam to act in: the team.id an earlier result named. Omit for the team selected in the Flask app (which the user can switch at any time).
file_sizeYesExact size of the local file in bytes (e.g. from `stat -f%z <file>` on macOS or `stat -c%s <file>` on Linux)
folder_idNoOptional folder to upload into (you must have edit access - check with permission_get if unsure). Omit to upload to the team's top level (root). For an image, pass it to upload_file_complete instead.
version_ofNoUpload as a NEW VERSION of an existing asset instead of creating a separate asset. Accepts the id of the asset (its container id, what contents/search return), or of any of its versions. The new upload becomes the current version; the asset's url then shows it. folder_id is ignored when version_of is given.
content_typeNoMIME type of the file (defaults to video/mp4). image/png, image/jpeg, image/webp or image/gif uploads an image; application/zip uploads a live animation.

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.5/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description meaningfully adds beyond them: free-plan asset limits, that version_of is always free, refusal behavior when quota is exhausted, resume-on-retry, and critically that re-calling upload_file_start creates and counts another asset. This last point is essential given idempotentHint=false.

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?

Content largely earns its place given three distinct upload modes, but it is delivered as one dense run-on paragraph. The capitalized mode labels (VIDEO:, IMAGE, LIVE ANIMATION) help navigation, yet the sheer density and lack of line separation make it hard to scan; it is close to over-long for a single description.

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 an 8-parameter, multi-mode tool with no output schema, the description covers all branches (video/immediate asset, image/deferred, zip/animation), the required follow-ups, quota and size limits, and error behavior. Nothing an agent needs to invoke it correctly across modes 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 adds cross-parameter conditional semantics the schema does not: which params apply per content_type (image/zip params go to upload_file_complete instead), the files/notes 'video only' constraint, and that folder_id is ignored when version_of is set. That meaningfully exceeds the schema's per-field docs.

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 first sentence states a specific verb and resource ('Start uploading a LOCAL video or image file from the user's machine into Flask') and immediately distinguishes it from upload_video for public links. It also routes to upload_file_complete as the continuation, so an agent can place it in the workflow without reading sibling schemas.

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?

Explicit when-to-use (needs a shell running curl) and when-not (a chat app without a shell -> use upload_video), plus per-mode routing (video vs image vs zip) and follow-up calls. It even states the live-animation precondition ('ONLY when the user asks to play an HTML/JS animation live') and the default it overrides (render the MP4).

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.