Skip to main content
Glama

Veltake Studio

Generate an image, video, speech or music

generate

Make an image, a video, a spoken script or a song. This SPENDS the user's coins: pass expected_cost exactly as estimate_generation answered it — if the price changed, nothing is charged and the new price is answered. The charge is a reservation of at most that number: a failed or canceled generation is refunded in full and the settlement may return part of it. Every call is paid in coins — a Relax queue or an unlimited allowance does not apply through an agent, and nothing here buys coins. Media (images, last_frame, reference_video, reference_audio) must be hosted: a URL import_media answered, or one on Veltake's own media host — import anything else first. Answers the generation (music answers its two takes); poll get_generation for the result — a host that runs tool tasks waits for the result itself. Repeat idempotency_key on a retry so it answers the first generation instead of charging again. Without expected_cost, a host that can ask the person shows them the price and the generation runs only when they accept; any other host is answered the price (price_required) and nothing is charged.

Input Schema

NameRequiredDescriptionDefault
kindYeswhat to make: image | video | speech | music. Each argument below says which kinds take it
linesNospeech: the script, in order — each line is {speaker, text, style}
modelYesa model id from list_models for this kind
styleNomusic: the style — a genre, a mood, the instruments (custom songs)
titleNomusic: the song's title (custom songs)
imagesNoimage, video: hosted image URLs — references for an image model; for a video model the first frame, or with images_are_references the subject/style references (at most the model's max_images). Import a link with import_media first
lyricsNomusic: the words to be sung. With lyrics, title and style are required
promptNoimage, video: what to make. music: the description of the song (simple mode; for a song with its own lyrics use lyrics)
fundingNowho pays: personal (the person's own coins) or team (their team's pool — only when the person allowed this connection to spend team coins and the team approved this app). Omit to use the payer the person chose when connecting
durationNovideo: seconds, one of the model's durations. music: the song's length in seconds (custom songs only)
speakersNospeech: the voices, in order (list_models has the voices, accents, styles and paces). Each is {name, voice, accent, style, pace, profile}, all optional except that a script needs at least one speaker. A model with line_style lists no accents, styles or paces: direct each line with its own style instead
last_frameNovideo: a hosted image URL for the LAST frame — only for models with supports_transition; then images holds exactly the first frame
resolutionNoimage, video: one of the model's resolutions — a higher tier costs more
video_taskNovideo: what reference_video is for — edit (change that one clip; images are references, and with no duration the answer runs the clip's length) or extend (add new footage to it; duration is the new part's length, the answer is that part alone, and images are refused). Omitted, it is a reference; on a model with clip_is_source it is required, and images are refused either way (there a clip is never a reference, an edit runs the clip's length, and an extension answers the clip plus the new part and takes up to 10 seconds). Only for models with video_tasks; needs a prompt and exactly one clip
aspect_ratioNoimage, video: the frame, one of the model's aspect_ratios (e.g. 16:9)
filler_wordsNospeech: add filler words and natural interjections to a TWO-speaker dialogue — only for models with filler_words
instrumentalNomusic: no vocals
expected_costNothe coins estimate_generation answered for these very arguments — omit it only when the host confirms prices with the person itself
generate_audioNovideo (and any image model that has it): make the sound too — only for models with supports_audio, and it costs audio_cost more
idempotency_keyNooptional: repeat it on a retry so the retry answers the first generation instead of charging again
reference_audioNovideo: a hosted audio URL to take sound from — only for models with max_reference_audios above 0
reference_videoNovideo: a hosted video URL to take motion or style from, or on a model with clip_is_source the clip to edit or extend (video_task is then required) — only for models with max_reference_videos above 0
images_are_referencesNovideo: read images as references to draw from, NOT as the first frame — the video does not start on them. Needs at least one image, cannot be combined with last_frame, and only models with supports_reference take it

Output Schema

NameRequiredDescriptionDefault
vNo
idYes
kindYes
coinsYes
modelYes
takesNo
resultNo
statusYes
balanceNo
replayedNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / expected_cost / description
      Previous value: -"the coins estimate_generation answered for these very arguments"New value: +"the coins estimate_generation answered for these very arguments — omit it only when the host confirms prices with the person itself"
    • changedInput schema / required
      Previous value: -[
      -  "kind",
      -  "model",
      -  "expected_cost"
      -]New value: +[
      +  "kind",
      +  "model"
      +]
    • addedOutput schema / properties / result
      Added value: +{
      +  "additionalProperties": true,
      +  "properties": {
      +    "coin_cost": {
      +      "minimum": 0,
      +      "type": "integer"
      +    },
      +    "created_at": {
      +      "type": "string"
      +    },
      +    "duration_sec": {
      +      "type": "number"
      +    },
      +    "fail_category": {
      +      "type": "string"
      +    },
      +    "height": {
      +      "type": "integer"
      +    },
      +    "id": {
      +      "type": "string"
      +    },
      +    "kind": {
      +      "type": "string"
      +    },
      +    "model": {
      +      "additionalProperties": true,
      +      "properties": {
      +        "id": {
      +          "type": "string"
      +        },
      +        "name": {
      +          "type": "string"
      +        },
      +        "vendor": {
      +          "type": "string"
      +        }
      +      },
      +      "required": [
      +        "id"
      +      ],
      +      "type": "object"
      +    },
      +    "progress": {
      +      "maximum": 100,
      +      "minimum": 0,
      +      "type": "number"
      +    },
      +    "prompt": {
      +      "type": "string"
      +    },
      +    "result_url": {
      +      "type": "string"
      +    },
      +    "status": {
      +      "enum": [
      +        "queued",
      +        "in_progress",
      +        "succeeded",
      +        "failed",
      +        "canceled",
      +        "submit_unknown"
      +      ],
      +      "type": "string"
      +    },
      +    "take": {
      +      "type": "integer"
      +    },
      +    "take_group": {
      +      "type": "string"
      +    },
      +    "takes": {
      +      "type": "integer"
      +    },
      +    "thumb_url": {
      +      "type": "string"
      +    },
      +    "width": {
      +      "type": "integer"
      +    }
      +  },
      +  "required": [
      +    "id",
      +    "status",
      +    "kind"
      +  ],
      +  "type": "object"
      +}
  2. Changed2 schema fields changed
    • changedInput schema / properties / reference_video / description
      Previous value: -"video: a hosted video URL to take motion or style from — only for models with max_reference_videos above 0"New value: +"video: a hosted video URL to take motion or style from, or on a model with clip_is_source the clip to edit or extend (video_task is then required) — only for models with max_reference_videos above 0"
    • changedInput schema / properties / video_task / description
      Previous value: -"video: what reference_video is for — edit (change that one clip; images are references, and with no duration the answer runs the clip's length) or extend (add new footage to it; duration is the new part's length, the answer is that part alone, and images are refused). Omitted, it is a reference. Only for models with video_tasks; needs a prompt and exactly one clip"New value: +"video: what reference_video is for — edit (change that one clip; images are references, and with no duration the answer runs the clip's length) or extend (add new footage to it; duration is the new part's length, the answer is that part alone, and images are refused). Omitted, it is a reference; on a model with clip_is_source it is required, and images are refused either way (there a clip is never a reference, an edit runs the clip's length, and an extension answers the clip plus the new part and takes up to 10 seconds). Only for models with video_tasks; needs a prompt and exactly one clip"
  3. Changed1 schema field changed
    • addedInput schema / properties / video_task
      Added value: +{
      +  "description": "video: what reference_video is for — edit (change that one clip; images are references, and with no duration the answer runs the clip's length) or extend (add new footage to it; duration is the new part's length, the answer is that part alone, and images are refused). Omitted, it is a reference. Only for models with video_tasks; needs a prompt and exactly one clip",
      +  "type": "string"
      +}
  4. Changed5 schema fields changed
    • addedInput schema / properties / filler_words
      Added value: +{
      +  "description": "speech: add filler words and natural interjections to a TWO-speaker dialogue — only for models with filler_words",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / lines / description
      Previous value: -"speech: the script, in order — each line is {speaker, text}"New value: +"speech: the script, in order — each line is {speaker, text, style}"
    • addedInput schema / properties / lines / items / properties / style
      Added value: +{
      +  "description": "how this line is said, in your own words (tone, emotion, pace) — only for models with line_style, at most max_line_style_chars",
      +  "type": "string"
      +}
    • changedInput schema / properties / lines / items / properties / text / description
      Previous value: -"what they say"New value: +"what they say — on a model with tags, a sound tag from its list may sit inside the words (e.g. <laugh>)"
    • changedInput schema / properties / speakers / description
      Previous value: -"speech: the voices, in order (list_models has the voices, accents, styles and paces). Each is {name, voice, accent, style, pace, profile}, all optional except that a script needs at least one speaker"New value: +"speech: the voices, in order (list_models has the voices, accents, styles and paces). Each is {name, voice, accent, style, pace, profile}, all optional except that a script needs at least one speaker. A model with line_style lists no accents, styles or paces: direct each line with its own style instead"
  5. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (which only say non-read-only and open-world), it discloses that every call spends coins as a reservation, that failures and cancellations are refunded in full and settlement may return part, that Relax queues and unlimited allowances do not apply, and that a mismatched expected_cost charges nothing. Those are exactly the costly side effects an agent must know before invoking a mutation.

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 purpose and the coin-spending warning are front-loaded, and each subsequent sentence carries a distinct operational fact (reservation, refunds, media hosting, polling, idempotency, price confirmation) with no filler. It is dense and the latter half is a long run-on, which costs a point on readability but not on necessity.

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 23-parameter, multi-modal, money-spending tool with an output schema, the description covers the full lifecycle: price check, charging and refunds, media prerequisites, asynchronous result retrieval, and retry safety. Nothing an agent needs in order to avoid double-charging or a failed call is left implicit.

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 still adds meaning by explaining what expected_cost must contain (the exact estimate answer), why idempotency_key exists on retry, and the hosting requirement that constrains images, last_frame, reference_video and reference_audio together. It does not add per-kind argument detail beyond the schema, keeping it just above baseline.

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?

"Make an image, a video, a spoken script or a song" states a concrete verb and the exact resource set, matching the four enum kinds. It also immediately distinguishes itself from estimate_generation (price source) and get_generation (result retrieval), so an agent can place it among its siblings without reading the schema.

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-to-do-what: call estimate_generation first and pass its answer as expected_cost, import non-hosted media via import_media, poll get_generation unless the host runs tasks itself, and repeat idempotency_key on retries. It also names the two price-confirmation paths (host that can ask the person vs. price_required), which is exactly the alternative-behavior routing an agent needs.

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