Veltake Studio

Upscale an image or a video

upscale

Upscale an image or a video. This SPENDS the user's coins: pass expected_cost exactly as estimate_upscale answered it for these arguments — if the price changed, nothing is charged and the new price is answered. A failed or canceled upscale is refunded in full. Answers the generation; poll get_generation for the result (a host that runs tool tasks waits for it itself). Repeat idempotency_key on a retry. Without expected_cost, a host that can ask the person confirms the price with them; any other host is answered the price and nothing is charged.

Input Schema

Name	Required	Description
`kind`	Yes	image or video — what the file is
`model`	No	as passed to estimate_upscale
`funding`	No	who 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
`resolution`	No	as passed to estimate_upscale
`source_url`	Yes	the hosted URL, as passed to estimate_upscale
`expected_cost`	No	the coins estimate_upscale answered for these very arguments
`idempotency_key`	No	optional: repeat it on a retry so the retry answers the first upscale instead of charging again

Output Schema

Name	Required	Description	Default
`v`	No
`id`	Yes
`kind`	Yes
`coins`	Yes
`model`	Yes
`takes`	No
`result`	No
`status`	Yes
`balance`	No
`replayed`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 8, 2026

changedInput schema / required

Previous value: -[
-  "kind",
-  "source_url",
-  "expected_cost"
-]New value: +[
+  "kind",
+  "source_url"
+]

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"
+}

First observedOct 19, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the supplied annotations by disclosing that this spends the user's coins, that a stale price results in no charge with the new price returned, and that failed or canceled upscales are refunded in full. The annotations only say it is not read-only; the description adds the financial consequences an agent must know before invoking.

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-loaded with the action, then the cost-safety rules, then the polling step — a sensible order for a spending tool. It is dense and a couple of clauses ('Answers the generation', the parenthetical about hosts running tool tasks) are terse almost to the point of ambiguity, but no sentence is filler.

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 7-parameter, coin-spending mutation with a peer quoting tool, the description covers the pricing handshake, refund behavior, retry semantics, and result retrieval. An output schema exists, so it does not need to describe return values, and the only remaining details (funding pool rules) live in the schema itself.

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 would be 3, but the description adds real meaning: expected_cost must match what estimate_upscale answered for these exact arguments, and its absence changes host behavior entirely. It also explains that idempotency_key prevents a double charge, which the schema only hints at.

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?

Opens with a specific verb+resource ('Upscale an image or a video') and implicitly separates itself from estimate_upscale by framing that tool as the pricing step. An agent can distinguish it from app_upscale_quote, estimate_upscale, and generate without opening a 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?

Explicitly states the workflow: call estimate_upscale first and pass expected_cost, then poll get_generation (or let a task-running host wait), and repeat idempotency_key on retries. It also names the fallback path when expected_cost is omitted and describes what each host type does, so when-to-use and how-to-sequence are both covered.

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

All Veltake Studio tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?