Skip to main content
Glama
OfflineCreatorStudio

OfflineCreator Studio MCP

Official

Upload input image

upload_input

Upload a source image for a reserved image-to-video generation and start processing. Provide a local path inside the upload root or base64 data.

Instructions

Upload a source image for a reserved image-to-video generation, then start processing. Local filePath must stay inside the upload root.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
waitNo
filePathNoLocal image path relative to the upload root (cwd or OFFLINECREATOR_UPLOAD_ROOT).
aspectRatioNo
contentTypeNo
imageBase64NoBase64-encoded image (optionally data URL)
generationIdYesReserved generation id

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.2

TDQS

A3.5/5.0
Behavior3/5

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

Annotations establish it is a non-read-only but non-destructive write. The description adds a meaningful side effect beyond a plain upload ('then start processing') and a constraint on filePath ('must stay inside the upload root'). It does not disclose overwrite behavior on repeat uploads, credit consumption (relevant given the get_credits sibling), or auth requirements, so it is decent but incomplete.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

Two tight sentences with zero waste; the action and its follow-on processing are front-loaded, and the path constraint follows directly. Nothing is padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter mutation tool with no output schema, the description covers the core action and one constraint, but leaves the 'wait' parameter's effect and the result of processing unexplained. Annotations carry the safety profile, so the remaining gap is modest but real.

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 coverage is 50% with filePath, imageBase64, and generationId documented in-schema. The description reinforces the filePath path constraint but adds nothing about wait, aspectRatio, or contentType beyond their enum values, matching the baseline for partial schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource: uploads a source image and starts processing for a reserved image-to-video generation. It clearly situates the tool in the generation workflow, though it does not name a sibling it differs from (e.g., generate) to sharpen differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'for a reserved image-to-video generation' implies the prerequisite that a generation must first be reserved, which is useful context. However, there is no explicit when-to-use vs alternative guidance and no statement of when not to use it.

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