Skip to main content
Glama
jau123

MeiGen AI Image Generation MCP

by jau123

upscale_image

DestructiveIdempotent

Enhance one still image. Crisp preserves structure; creative regenerates detail for blurry images. Pass the original public URL directly, including external URLs; avoid generic reference-image resizing.

Instructions

Enhance one still image. Crisp preserves structure; creative regenerates detail for blurry images. Pass the original public URL directly, including external URLs; avoid generic reference-image resizing. The shared backend prepares the image. Inputs above 4096px or 16 MP require acceptance of resizing; the output may be smaller than the original. Source safety cap: 64 MiB / 64 MP. Video enhancement is not exposed through this API. This legacy local npm path requires an existing MeiGen key (MEIGEN_API_TOKEN or saved local configuration) and purchased credits. New connections use remote OAuth at https://www.meigen.ai/api/mcp. Local files and external public HTTPS URLs are uploaded automatically. Use the dedicated skill directly; skip unrequested prompt enhancement, preference loading and delegation. Preserve caller-supplied inputs. Infer omitted optional settings from the request and defaults; when only a requested count is known, choose suitable modules unless the caller selected them. Ask only for missing required material or unresolved scope. An explicit user request or authorized upstream workflow establishes its count, quality and budget: do not reconfirm that scope or add paid images. The caller persists a requestId for each logical step; never ask an end user for technical IDs. Use live list_skills prices and account for in-flight charges when planning within a budget; a batch is not atomic and an estimate is not a server-enforced spending cap. Recovery actions take precedence over generic retry advice: check an interrupted submission, preserve exact retryParameters and do not create a new ID or replace failed modules automatically. Retry a temporary upload at most once after the suggested wait. Return structured status, handles, errors and completed URLs to the caller; it owns progress, previews, downloads and final presentation. If interacting directly with the user, explain the problem and a concrete next step in their language. Describe image details only after actual inspection.

Input Schema

NameRequiredDescriptionDefault
modeNocrisp=faithful enhancement (default); creative=AI reconstructs details and may change them. Use creative only when the user accepts those changes.crisp
imageUrlYesOriginal still PNG/JPEG/WebP: absolute local path, ~/, file://, or public direct HTTPS URL. Maximum 64 MiB/64 million pixels. Local uploads remove metadata, preserve alpha and dimensions, and compress below the gateway limit; if that fails, provide a public original URL. The backend asks before any resizing.
requestIdYesGenerate a new UUID for a new paid request; reuse the SAME requestId and inputs on retry. Use check_skill after interruptions.
allowDownscaleNoTrue only after the user accepts resizing a large source and potentially receiving a smaller result. On upscale_resize_required, no charge occurred; after acceptance use a new requestId.
confirmedCreditsYesRequired on every MCP submission, including the first: current list_skills quote within the user or upstream workflow accepted budget. Reuse explicit acceptance. On price_changed, accept the updated quote before a new requestId. This pre-dispatch check is not an atomic spending cap.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.1

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already declare destructive, idempotent, open-world, and non-read-only behavior. The description adds valuable context beyond annotations: legacy local npm auth requirements, purchased credits, source safety caps (64 MiB / 64 MP), automatic resizing acceptance above 4096px/16MP, non-atomic batch behavior, and retry/recovery rules. It does not contradict annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a long, unstructured block that mixes purpose, operational guidance, agent workflow instructions, billing rules, and retry policies. While the first sentence is front-loaded, much of the text restates schema or annotation content and could be trimmed or moved. It is not concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (paid generation, credits, resizing, retries) and the absence of an output schema, the description covers a lot: auth paths, credit confirmation, resizing behavior, source caps, retry rules, and return expectations. It is nearly complete, though some return details remain vague.

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 the schema already fully documents all five parameters. The description adds little parameter meaning beyond what is in the schema, aside from clarifying mode semantics and URL acceptance. Baseline 3 is appropriate when the schema carries the load.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb and resource: 'Enhance one still image.' It distinguishes two modes and explicitly excludes video enhancement and generic reference-image resizing. However, it does not clearly differentiate itself from sibling image tools like generate_image or remove_background, so sibling routing remains fuzzy.

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

Usage Guidelines3/5

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

The description provides some negative guidance ('avoid generic reference-image resizing', 'Video enhancement is not exposed through this API') and a directive to use the dedicated skill directly. It lacks a positive when-to-use statement versus alternatives such as generate_image or enhance_prompt. Usage is implied but not explicitly framed.

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