Skip to main content
Glama

Estimate render time

render_estimate
Read-onlyIdempotent

Estimate a render before starting it (no GPU time): GPU seconds, queue wait, the wall-clock time as text (estimate.human, e.g. 'about 3 minutes') and whether it fits the free GPU time left (the welcome credit, or 2 preview GPU-minutes a day after it) and the size limits. Call it before render_final when the time or quota is uncertain, the job is longer than about 24 frames or above 720p, or the user asks how long it takes; tell the user the result. With scene_id the estimate uses measured render times and returns calibration.final_path_measured. If false, treat it as preliminary: run a short contiguous final-path test and estimate again before the full animation. It also says when to split a job.

Input Schema

NameRequiredDescriptionDefault
kindNo'final' (frame_start..frame_end at width x height, samples) or 'preview' (frames like '1-24').final
widthNoOutput width in pixels (previews are capped at 1280x720 keeping the aspect ratio; a final frame can have at most 1920x1080 pixels on free time, 3840x2160 on prepaid credit).
framesNoPreview frames: '' = frame 1; '12' = one frame; '1,8,16,24' or '1-24' = up to 4 frames tiled in one labeled image (to judge camera motion and animation; same GPU time as one 720p frame).
heightNoOutput height in pixels (previews are capped at 1280x720 keeping the aspect ratio; a final frame can have at most 1920x1080 pixels on free time, 3840x2160 on prepaid credit).
presetNoPurpose preset: 'product' (4 studio shots at 0/90/180/270 deg on a plain backdrop; the final gives 4 PNGs at 1440x1440), 'turntable' (one full turn as an MP4, studio light, plain backdrop), 'animation' (the scene's own camera, lights and frame range; the scene is read first when the range is unknown), or '' (none). It fills what you do not pass; environment, orbit_frames, width/height and the frames still win when given.
camerasNoSeveral camera object names (up to 8) rendered from the same frame in one job: the preview tiles them in one labeled sheet, the final returns one PNG/EXR per camera (camera_files maps names to files). For product shots from fixed angles. Not combinable with orbit, environment='compare' or camera.
samplesNoCycles samples per pixel (preview: up to 32, default 16; final: default 128).
scene_idNoscene_id returned by an earlier call (reuses the uploaded scene without sending it again).
frame_endNoLast frame to render (inclusive); equal to frame_start for a single image. With orbit=True and no frame_end, one full turn is rendered.
frame_startNoFirst frame to render (inclusive).

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / height / description
      Previous value: -"Output height in pixels (previews are capped at 1280x720 keeping the aspect ratio; a final frame can have at most 1920x1080 pixels)."New value: +"Output height in pixels (previews are capped at 1280x720 keeping the aspect ratio; a final frame can have at most 1920x1080 pixels on free time, 3840x2160 on prepaid credit)."
    • changedInput schema / properties / width / description
      Previous value: -"Output width in pixels (previews are capped at 1280x720 keeping the aspect ratio; a final frame can have at most 1920x1080 pixels)."New value: +"Output width in pixels (previews are capped at 1280x720 keeping the aspect ratio; a final frame can have at most 1920x1080 pixels on free time, 3840x2160 on prepaid credit)."
  2. Changed1 schema field changed
    • addedInput schema / properties / preset
      Added value: +{
      +  "default": "",
      +  "description": "Purpose preset: 'product' (4 studio shots at 0/90/180/270 deg on a plain backdrop; the final gives 4 PNGs at 1440x1440), 'turntable' (one full turn as an MP4, studio light, plain backdrop), 'animation' (the scene's own camera, lights and frame range; the scene is read first when the range is unknown), or '' (none). It fills what you do not pass; environment, orbit_frames, width/height and the frames still win when given.",
      +  "title": "Preset",
      +  "type": "string"
      +}
  3. Changed2 schema fields changed
    • changedInput schema / properties / height / description
      Previous value: -"Output height in pixels (previews are capped at 1280x720 keeping the aspect ratio; during the free beta a final frame can have at most 1920x1080 pixels)."New value: +"Output height in pixels (previews are capped at 1280x720 keeping the aspect ratio; a final frame can have at most 1920x1080 pixels)."
    • changedInput schema / properties / width / description
      Previous value: -"Output width in pixels (previews are capped at 1280x720 keeping the aspect ratio; during the free beta a final frame can have at most 1920x1080 pixels)."New value: +"Output width in pixels (previews are capped at 1280x720 keeping the aspect ratio; a final frame can have at most 1920x1080 pixels)."
  4. Changed9 schema fields changed
    • addedInput schema / properties / cameras / description
      Added value: +"Several camera object names (up to 8) rendered from the same frame in one job: the preview tiles them in one labeled sheet, the final returns one PNG/EXR per camera (camera_files maps names to files). For product shots from fixed angles. Not combinable with orbit, environment='compare' or camera."
    • addedInput schema / properties / frame_end / description
      Added value: +"Last frame to render (inclusive); equal to frame_start for a single image. With orbit=True and no frame_end, one full turn is rendered."
    • addedInput schema / properties / frame_start / description
      Added value: +"First frame to render (inclusive)."
    • addedInput schema / properties / frames / description
      Added value: +"Preview frames: '' = frame 1; '12' = one frame; '1,8,16,24' or '1-24' = up to 4 frames tiled in one labeled image (to judge camera motion and animation; same GPU time as one 720p frame)."
    • addedInput schema / properties / height / description
      Added value: +"Output height in pixels (previews are capped at 1280x720 keeping the aspect ratio; during the free beta a final frame can have at most 1920x1080 pixels)."
    • addedInput schema / properties / kind / description
      Added value: +"'final' (frame_start..frame_end at width x height, samples) or 'preview' (frames like '1-24')."
    • addedInput schema / properties / samples / description
      Added value: +"Cycles samples per pixel (preview: up to 32, default 16; final: default 128)."
    • addedInput schema / properties / scene_id / description
      Added value: +"scene_id returned by an earlier call (reuses the uploaded scene without sending it again)."
    • addedInput schema / properties / width / description
      Added value: +"Output width in pixels (previews are capped at 1280x720 keeping the aspect ratio; during the free beta a final frame can have at most 1920x1080 pixels)."
  5. Changed1 schema field changed
    • addedInput schema / properties / cameras
      Added value: +{
      +  "anyOf": [
      +    {
      +      "items": {
      +        "type": "string"
      +      },
      +      "type": "array"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "title": "Cameras"
      +}
  6. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnlyHint/idempotent/non-destructive, but the description adds non-obvious behavior: the call consumes no GPU time, it reports queue wait and free-credit limits, and it may return preliminary numbers requiring a short contiguous test render before a full animation. It also flags when a job should be split.

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?

Purpose and the no-GPU-cost caveat are front-loaded, and every sentence carries decision-relevant content. However, the middle sentences are long and clause-stacked (quota/credit, calibration, test render, splitting all in one breath), which costs some scannability.

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 10-parameter tool with an output schema and full annotation coverage, the description supplies everything an agent needs: what it does, when to call it, what it returns conceptually, how to interpret an uncalibrated result, and what to do next. No material gap remains.

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 real meaning beyond the schema: passing scene_id switches the estimate to measured render times and produces calibration.final_path_measured, which the schema does not convey. No other parameters are elaborated, so it stays short of 5.

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 ('Estimate a render before starting it') and immediately qualifiers the scope with '(no GPU time)'. It explicitly positions itself against the sibling render_final ('Call it before render_final'), so an agent can distinguish the two without opening either 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?

Gives explicit trigger conditions ('when the time or quota is uncertain, the job is longer than about 24 frames or above 720p, or the user asks how long it takes') plus a follow-up instruction to relay the result. It also branches on the outcome via calibration.final_path_measured, telling the agent what to do when it is false.

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.