aicut

Upload a file from this machine

upload_media

Puts a VIDEO OR IMAGE FILE FROM THE USER'S OWN MACHINE onto their aicut account so the generation tools can use it (every other tool takes a URL). It returns an upload target in two forms, a ready-to-run curl_template for you and a browser_upload_url for the user; then you call confirm_upload. CANNOT RUN A SHELL COMMAND ON THE USER'S OWN MACHINE (claude.ai, ChatGPT, Claude Desktop, the mobile apps)? YOU ARE ON THE WRONG TOOL: call upload_media_widget and stop. This tool is for an agent that can run a command there (Claude Code, Cursor, a terminal, a script). WHEN: the user refers to a file on their computer ('upscale the clip in my Downloads'). NOT when it is already a URL (public https, or an earlier generation): pass that straight to the tool that needs it. TWO ROUTES, PICK BEFORE YOU START. The curl_template needs your environment to reach upload.host; a SANDBOXED CODE ENVIRONMENT (claude.ai's code sandbox) CANNOT (the curl dies with HTTP code 000; no retry fixes it): there, DO NOT RUN THE CURL: give the user the browser_upload_url as a link, say in one line that opening it lets their own browser send the file, wait for them to say it is done, then confirm_upload. On the user's own machine (Claude Code, Cursor, a terminal) run the curl. Never report an upload that did not happen. SEQUENCE: (1) upload_media with the file's content type and size in bytes; (2) move the bytes by exactly one route: run the curl_template with the real path for <FILE_PATH> (it prints the body, then an HTTP status; 204 with an empty body is success) or hand the user browser_upload_url and wait; (3) confirm_upload with the id. The url is not real media until the confirm returns: never pass it to a generation tool before then. browser_upload_url: an aicut page where the user picks the file; 15 minutes, retryable, carries no key, cannot spend; private. PUT IT IN A MARKDOWN LINK, EXACTLY ONCE, NEVER AS TEXT: it is about 900 characters of base64, so write [Open the upload page](<the whole url>) with short anchor text (everything after the # IS the upload, so the whole url goes inside the parentheses). DO NOT REPEAT IT: if they have not finished, say so in one line without the link, and do not call upload_media again (a second call within 15 minutes with the SAME type and size returns the SAME target). SUBSTITUTING THE PATH IS YOUR RESPONSIBILITY: it is a shell command on the USER'S OWN MACHINE. <FILE_PATH> sits inside single quotes, so an ordinary path pastes as-is, but a path containing a SINGLE QUOTE would break out and run whatever follows: quote it properly or have the user rename the file. ACCEPTED TYPES: video/mp4 and video/quicktime up to 50 MB; image/png, image/jpeg and image/webp up to 20 MB. WebM, AVIF, HEIC, TIFF and GIF are not accepted: re-encode to MP4 or PNG / JPEG. bytes MUST BE THE FILE'S REAL SIZE, read off disk (stat -c%s on Linux, stat -f%z on macOS): it is signed as a hard limit and charged against the daily media allowance. Costs no tokens. OUTPUT: browser_upload_url is the ONE url that may reach the conversation (browser route only, as a markdown link). url serves nothing until confirm_upload returns: never show or pass it. Do not paste the raw JSON, the reservation id, the signed fields or the curl command.

Input Schema

Name	Required	Description
`bytes`	Yes	The file's real size in bytes, read off disk: signed as the hard limit. Ceiling: 50 MB for a video, 20 MB for an image.
`file_name`	No	The local file name, for your own bookkeeping; not stored.
`content_type`	Yes	The file's real type, taken from the file itself, not its name.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond annotations, it discloses critical behavior: the tool returns a curl template and browser upload URL, requires a separate confirm_upload, the curl fails with HTTP 000 in sandboxed environments, the browser URL expires in 15 minutes, and bytes are signed as a hard limit charged against the daily media allowance. The 15-minute same-target retry behavior is a narrow retry property, not a full idempotency guarantee, so it does not clearly contradict 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the main purpose, wrong-tool warning, and route decision, then structured into WHEN, SEQUENCE, and output guidance. It is longer and more emphatic than necessary for a three-parameter tool, with some repeated warnings, but the length is largely justified by the multi-step workflow and sandbox failure mode.

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?

Given the complex multi-route upload workflow, annotations, and absence of an output schema, the description is complete enough to call correctly. It explains return values, the confirm_upload dependency, output display restrictions, file limits, and failure modes an agent must avoid.

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. The description adds operational meaning beyond the schema by explaining accepted and rejected media types, re-encoding needs, and that bytes must be the real on-disk size read with stat commands and is charged as a signed hard limit.

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 states a specific verb and resource: puts a video or image file from the user's own machine onto their aicut account for generation tools to use. It explicitly distinguishes this from the URL-based sibling tools and from upload_media_widget, so an agent can select it without opening 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?

It gives explicit WHEN and WHEN-NOT conditions: use it when the user refers to a local file, not when the media is already a public URL or prior generation. It also names the alternative upload_media_widget for sandboxed or non-shell environments and explains the two route choices.

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

All aicut tools Inspect

Try in Browser