VerseIn

upscale_image

Destructive

Upscale an image (a VerseIn media URL) to a higher resolution. Spends the user's coins: the price is quoted from the image size; calls above the confirmation threshold return needs_confirmation with a confirmation_token; ask the user, then call again with it. Returns a task id; follow it with get_tasks. Generating through an AI assistant is charged in VerseIn coins. Unlimited-plan allowances do not apply here.

Input Schema

Name	Required	Description
`model`	No	upscaler model key; omit for the default. An invalid key is answered with the valid ones
`image_url`	Yes	the image to upscale — a VerseIn media URL
`request_id`	No	your id for this call; retrying with the same id never charges twice. Use a new id to intentionally repeat identical settings
`enhance_model`	No	enhancement style, for models that offer it
`output_format`	No	output file format, for models that offer it
`upscale_factor`	No	how much larger the output is (the model may support only some factors)
`max_total_coins`	No	the most this edit may charge: send the exact most the user agreed to (the max_coins of estimate_cost, or total_cost_coins when equal). If the job could now cost more, nothing is submitted and needs_confirmation returns the new price
`face_enhancement`	No	enhance faces, for models that offer it
`subject_detection`	No	which part of the image to focus on, for models that offer it
`confirmation_token`	No	the confirmation_token a needs_confirmation answer returned, passed back once the user agreed to that price
`compression_quality`	No	1 to 100, for models that offer it
`confirm_transparency`	No	set true only after the user agreed that transparent areas become white (some models flatten transparency)
`face_enhancement_strength`	No	0 to 1, with face_enhancement
`face_enhancement_creativity`	No	0 to 1, with face_enhancement

Output Schema

Name	Required	Description
`error`	No	present only when the call failed
`tasks`	No
`failed`	No
`balance`	No	balance after submitting
`declined`	No	true when the user declined the confirmation form; nothing was submitted or charged
`next_action`	No
`total_cost_coins`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 26, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations, the description discloses the critical cost behavior: coins are spent, price depends on image size, calls above a threshold return needs_confirmation with a token, and the user must be asked before retrying. It also explains that the result is a task id to follow with get_tasks and that unlimited-plan allowances do not apply.

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?

The description is front-loaded with the core action and immediately follows with the financial and confirmation constraints. Despite a small amount of repeated cost language, every sentence contributes to safe invocation of a paid, confirmation-gated tool.

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 14-parameter paid mutation tool with a fully described schema and an output schema, the description supplies the missing workflow context: pricing, confirmation token handling, task follow-up, and plan limitations. Nothing essential for correct invocation is omitted.

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 description coverage is 100%, so each of the 14 parameters is already documented in the schema. The description explains the surrounding confirmation flow and cost context but adds little parameter-specific meaning beyond what the schema provides, making the baseline 3 appropriate.

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?

The description opens with a specific verb and resource: 'Upscale an image ... to a higher resolution.' It also identifies the required input as a VerseIn media URL, which clearly separates it from video/image generation and relighting siblings.

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?

Usage context is clear for upscaling an image, and the confirmation workflow is described. However, it does not explicitly name when to choose upscale_image over alternatives such as upscale_video or generate_image, so it falls short of full alternatives guidance.

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

All VerseIn 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?