Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@upres Upscale the attached image using the flare model at 4x"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Official CLI + SDK for upres.ai — AI image and video upscaling. One API, 6 specialist models (Flare, Prism, Lumen, Mirage, Motion, Motion X), up to 8K output.
$ upres upscale photo.jpg --model flare --scale 4
Submitting job... model=flare
Job created: 550e8400-e29b-41d4-a716-446655440000 (status: pending)
Waiting for result.......
Downloading to photo_upscaled.jpg... done.
Result: photo_upscaled.jpgTopaz is $200/yr, desktop-only, no API, no automation
Upscayl is great for one-offs but can't handle bulk exports or CI pipelines
Every other SaaS upscaler either watermarks your output, caps resolution at 2K, or charges per image with no monthly plan
upres.ai gives you a clean REST API, 6 specialist models, batch processing, and predictable pricing starting at $9/mo on the Creator launch deal.
Related MCP server: Ideogram MCP Server
npx upres-cli upscale photo.jpgOr install globally:
npm install -g upres-cli
upres upscale photo.jpg --model lumen --scale 8 --output photo_8k.jpgpip install upres-ai
upres upscale photo.jpg --model flare --scale 4Sign up at upres.ai (free — 3 upscales/month)
Generate a key — it's shown once
export UPRES_API_KEY=upres_yourkeyOr save permanently:
mkdir -p ~/.config/upres
echo '{"apiKey":"upres_yourkey"}' > ~/.config/upres/config.jsonKey resolution order: --api-key flag → UPRES_API_KEY env var → ~/.config/upres/config.json
# Upscale a single image (local file or URL)
upres upscale photo.jpg --model flare --scale 4
upres upscale photo.jpg --model lumen --scale 8 --output out.jpg
upres upscale https://example.com/photo.jpg --model prism
# Upscale video (AI-generated video from Sora, Kling, Runway etc.)
upres upscale clip.mp4 --model motion --scale 4
# Batch upscale a folder
upres batch ./photos/ --model flare --output ./upscaled/ --concurrency 5
# List available models
upres models
# List recent jobs
upres jobs --limit 20 --status completed
# Account / quota info
upres accountimport { UpresClient } from "upres-cli";
const client = new UpresClient(); // reads UPRES_API_KEY from env
// Upscale a local file
const job = await client.createJobFromFile("photo.jpg", {
model: "flare",
scale: 4,
});
// Wait for completion
const completed = await client.waitForJob(job.id);
// Download result
await client.downloadResult(completed, "photo_4k.jpg");
console.log("Done:", completed.result_url);Files over 50 MB are automatically uploaded via TUS resumable protocol.
from upres import UpresClient
with UpresClient() as client: # reads UPRES_API_KEY from env
job = client.create_job_from_file(
"photo.jpg",
model="flare",
scale=4,
)
completed = client.wait_for_job(job["id"])
client.download_result(completed, "photo_4k.jpg")
print("Done:", completed["result_url"])The Python SDK uses httpx — async-ready, no heavy dependencies.
Example | What it does |
Upscale all images in a folder with configurable concurrency | |
Restore old/scanned photos using Recraft Crisp Upscale | |
Product image pipeline: raw shots → 4K → publish-ready | |
Auto-upscale Lightroom exports via post-processing hook | |
Figma plugin integration guide |
6 specialist models across image and video. Each one tells you up front whether it invents detail or leaves your file alone.
Model | Kind | Best for |
| Image | Everyday photos, fastest default |
| Image | Text, logos, product shots — keeps edges true |
| Image | Maximum detail recovery for print, up to 8x |
| Image | Invents new detail — art and hero images |
| Video | Fast 4K finish for Sora/Kling/Runway clips |
| Video | Cinema-grade, for film and commercials |
Full model catalogue: upres.ai/models · Live spec: api.upres.ai/v1/openapi.json
Plan | Price | Includes | API | Watermark |
Free | $0 | 3 upscales/mo | — | Yes |
Creator | $9/mo (launch deal, was $19) | 50 stills + 20 min 4K video/mo | — | No |
Studio | $39/mo | 250 stills + 90 min 4K video/mo | Yes | No |
Studio tier unlocks the full API, batch processing, and no output watermark.
Compare plans → · vs. Topaz → · vs. Upscayl →
claude mcp add upres -- npx -y github:auroracapital/upres-cli mcpOr in claude_desktop_config.json / Cursor:
{
"mcpServers": {
"upres": {
"command": "npx",
"args": ["-y", "github:auroracapital/upres-cli", "mcp"],
"env": { "UPRES_API_KEY": "upres_yourkey" }
}
}
}Tools: upres_list_models, upres_get_credits, upres_upscale_image, upres_upscale_video, upres_get_job.
If you're building something open-source on top of the API, email support@upres.ai with your repo link. We offer 500 ops/month for qualifying OSS projects.
The SDK handles these errors automatically:
Status | Behavior |
| Prints API key error + link to key management, exits |
| Prints quota exceeded + link to pricing, exits |
| Prints rate limit message (60 req/min), exits |
| Throws |
In Python: raises AuthError, QuotaExceededError, or UpresError.
See CONTRIBUTING.md. Tests run with:
# Node
npm test
# Python
pip install -e ".[dev]"
pytest tests/test_client.py -vMIT — see LICENSE
Show recent job count for the authenticated UpRes API key as a quota proxy.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It conveys the authenticated context and the quota-proxy framing, but it does not define what 'recent' means, what the response looks like, or how the count relates to credits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact, front-loaded sentence with no filler. Every word adds meaning, and the core purpose is immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter status/quota tool, the core purpose is adequately conveyed. However, with no output schema or annotations, the agent is left without the return format or the exact time window behind 'recent', leaving minor ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description has no parameter details to add; the schema already covers everything. The authentication context mentioned is useful but not a parameter semantic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Show'), a precise resource ('recent job count for the authenticated UpRes API key'), and its conceptual role ('quota proxy'). This clearly distinguishes it from sibling tools like upres_upscale_image or upres_get_job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: checking quota/credit consumption via recent job count. However, it does not explicitly state when to prefer this tool over alternatives, nor does it mention exclusions or prerequisites beyond authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get status and result_url of an UpRes job by id.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes | Job UUID returned by an upscale tool |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the whole behavioral burden. It states that the tool retrieves status and result_url, which implies a read-only operation, but it does not mention error behavior, whether the job must be finished, or if it can be polled repeatedly. The core behavior is clear, but deeper transparency is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence with no filler. The verb and resource are front-loaded, and every word earns its place. It is an exemplary concise definition for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter getter with no output schema, the description names the two return fields (status, result_url) and the input, which is mostly sufficient. It could enrich the context by mentioning that status may be pending or completed, but that is inferable and minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter job_id is fully described in the schema as a UUID from an upscale tool. The description merely repeats 'by id' and adds no extra meaning beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), a concrete resource ('status and result_url of an UpRes job'), and an identifier ('by id'). It is clearly distinct from sibling tools that manage models, credits, or submit upscale jobs, so an agent can separate it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to call this tool as opposed to the upscaling tools; it only implies use after a job is created. The schema parameter description says the job_id comes from an upscale tool, but that is in the schema, not the description. There is no when-to-use or exclusions, only an implied context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List UpRes upscale models (flare, prism, lumen, mirage, motion, motion-x) with use cases.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It correctly implies a read-only listing operation, but it does not mention whether results are cached, require authentication, or are limited in any way. The behavior is simple enough that this is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One succinct sentence, immediately naming the resource and the model list. No redundant words or filler, and every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter listing tool with no output schema, the description adequately states what it returns (models and their use cases). It could mention ordering or formatting, but nothing essential is missing for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so there is nothing for the description to add about parameters. Baseline 4 applies per the rubric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise verb ('List') and resource ('UpRes upscale models'), and enumerates the exact model names. This clearly distinguishes it from the sibling tools like upres_upscale_image and upres_get_credits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'with use cases' implies the tool is for deciding which model to use, but it does not explicitly say when to call it or how it relates to the upscale/credit/job tools. No explicit alternatives or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit an image upscale job from a public URL. Models: flare, prism, lumen, mirage.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Image model. Default flare. | |
| scale | No | Scale multiplier. Default 4. | |
| image_url | Yes | Public HTTPS URL of the image |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry behavioral disclosure. It communicates that the call submits a job (implying asynchronous work), but it does not mention what the response contains, that the caller must poll with upres_get_job, or any constraints beyond a public URL. For a job-submission tool with zero annotation coverage, this is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core action and requirement are front-loaded, and the model list is presented compactly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite simple parameters, this is an asynchronous job submission with no output schema and no annotations. The description does not explain the return value, how to track the job, or the relationship to upres_get_job, leaving an agent without enough context to know what happens after invoking it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: every parameter, including enum values and defaults, is documented in the schema. The description's model list is a duplication of the enum and adds no semantic depth, so the baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Submit an image upscale job.' It also names the available models, and the word 'image' distinguishes this from the sibling upres_upscale_video. This is enough for an agent to know what operation is being offered.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful context by requiring a public URL and listing models, but it does not explicitly say when to choose this over siblings such as upres_upscale_video, upres_get_job, or upres_get_credits. Usage guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a video upscale job from a public URL. Models: motion, motion-x.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Video model. Default motion. | |
| scale | No | Scale multiplier. Default 4. | |
| video_url | Yes | Public HTTPS URL of the video |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'Submit a job' implies asynchronous behavior, but the description does not disclose that it likely returns a job ID, that it consumes credits, or that results must be polled with get_job. This is a meaningful transparency gap for a job-submitting tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. It front-loads the action and resource, then lists model options. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should explain what happens after submission. It omits the async nature, the likely job ID return value, the need to poll with get_job, and potential credit usage. These are essential for an agent to correctly handle the tool's result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all three parameters with descriptions, enums, and defaults, so description-level parameter information is not strictly needed. The description adds 'Models: motion, motion-x,' but this only repeats schema content. Baseline 3 is appropriate given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Submit') and resource ('video upscale job'), and clarifies the required input ('public URL'). This clearly distinguishes it from the sibling image tool upres_upscale_image and other upres tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this is for video upscaling jobs from a public URL, with available models listed. It does not explicitly name alternatives or exclusions, but the video-vs-image distinction is obvious from the tool name and description, so the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.0upres_get_creditsupres_get_jobupres_list_modelsupres_upscale_imageupres_upscale_videoScored across 5 tools
Each tool maps to a unique action or resource: model discovery, quota check, image upscaling, video upscaling, and job retrieval. The two upscale tools are clearly separated by media type and supported models, so there is no real ambiguity.
All tool names share the upres_ prefix and follow a consistent verb_noun pattern: list_models, get_credits, upscale_image, upscale_video, get_job. This makes the tool set predictable and easy to navigate.
Five tools is a well-scoped set for an upscaling API: model discovery, quota monitoring, two job submission variants, and job status/result retrieval. Each tool earns its place without redundancy.
The core workflow is fully covered: list available models, submit image or video jobs from public URLs, poll job status, and retrieve results. There are no obvious dead ends or missing operations required for the primary use case.
Generate AI images, video, music, and sound effects, and upscale them, from any MCP client.
Video, audio, and image processing for AI agents: convert, transcribe, upscale - 150+ operations.
Magnific in natural language: upscale images, generate and list your creations. Connect your Magnifi
Create AI images and videos, manage projects and credits, and use workspace campaign context.
