Skip to main content
Glama

Upscale Video (Popcraft)

popcraft_upscale_video

Upscale and enhance an existing video to 2x or 4x with Topaz — use when the user asks to upscale, enhance, sharpen, denoise, or convert a video to higher resolution. Pass the source as a GCS URL (video_url from a prior generation result or popcraft_media_import_url); width, height (pixels) and duration (seconds) are optional hints — the server measures the real file and prices from that, so the cost is unaffected by what you pass. mode picks the Topaz model: "live-action" (default, real footage), "detail", "sharpen", "theia-detail" (fine detail), "cgi" (3D renders). fps above 30 roughly doubles the cost. This tool does not use prompt or count. Set get_cost:true to preflight the credit cost WITHOUT submitting — video upscales are expensive, so preview first unless the user already confirmed. On success, an interactive result card is shown and refreshes itself automatically — do NOT poll; call popcraft_job_display at most once if no card is visible. The result includes project — the Popcraft project the output was filed into; when the user did not pass project_id/project_name, mention it briefly (e.g. "saved to "). Never tell the user how long the job will take or quote any estimate of generation time — the result card shows progress.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fpsNoOutput fps: 24, 30 (default), or 60 — above 30 roughly doubles the cost
modeNoTopaz mode — default "live-action"
scaleNoUpscale factor: 2 (default) or 4
widthNoOptional source width hint (px); the server measures the real file for pricing
heightNoOptional source height hint (px); the server measures the real file for pricing
durationNoOptional source duration hint (s); the server measures the real file for pricing
get_costNotrue = return the exact credit cost WITHOUT submitting; preview before submitting unless the user already confirmed
video_urlYesSource video as a GCS https URL (from a prior result or popcraft_media_import_url) or gs:// URI
project_idNoFile the result into this Popcraft project (id from popcraft_projects). Omit to use the user's current/last-used project (or a default). Errors if you don't own it.
project_nameNoFile the result into the project with this title, creating it if it doesn't exist. Ignored when project_id is set.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / duration / description
      Previous value: -"Source video duration in seconds"New value: +"Optional source duration hint (s); the server measures the real file for pricing"
    • changedInput schema / properties / height / description
      Previous value: -"Source video height in pixels"New value: +"Optional source height hint (px); the server measures the real file for pricing"
    • changedInput schema / properties / width / description
      Previous value: -"Source video width in pixels (caller-supplied)"New value: +"Optional source width hint (px); the server measures the real file for pricing"
    • changedInput schema / required
      Previous value: -[
      -  "video_url",
      -  "width",
      -  "height",
      -  "duration"
      -]New value: +[
      +  "video_url"
      +]
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing cost behavior (fps above 30 roughly doubles cost), the get_cost preflight pattern, that no prompt/count is used, that the result card auto-refreshes so polling is forbidden, and project-filing consequences. This is rich operational context an agent cannot get from readOnlyHint/idempotentHint alone.

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?

Front-loads purpose, then layers cost, mode, and result-handling guidance efficiently. It is dense and lengthy, but nearly every sentence carries actionable information; minor trimming of the card/polling advice could tighten it further.

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?

Despite no output schema, the description explains what the result contains (interactive card, `project` value) and how to handle it, plus cost and routing behavior. An agent has everything needed to invoke and follow up correctly on this 10-parameter mutation tool.

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% (baseline 3), and the description adds real meaning beyond it: width/height/duration are non-authoritative hints that do not affect pricing because the server measures the file, plus glosses for the Topaz mode values. It stops short of full per-parameter documentation but meaningfully enriches the enum and hint semantics.

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 ('Upscale and enhance an existing video to 2x or 4x with Topaz'), naming the engine and factors. It is clearly distinguishable from siblings like popcraft_upscale_image and popcraft_upgrade_video without opening their schemas.

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

Usage Guidelines4/5

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

Provides explicit trigger conditions ('use when the user asks to upscale, enhance, sharpen, denoise, or convert...'), mode-selection guidance, and a get_cost preflight workflow. It does not explicitly contrast against the sibling popcraft_upgrade_video or upscale_image, but the when-to-use context is strong.

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