Skip to main content
Glama
jau123

MeiGen AI Image Generation MCP

by jau123

upscale_image

Enhance still images: crisp mode preserves structure, creative mode regenerates blurry details. Provide an image URL to boost quality and resolution.

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. Requires a MeiGen API key configured for this local npm server (MEIGEN_API_TOKEN or saved local configuration), and purchased credits only. 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

TableJSON 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

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full transparency burden and does so thoroughly: it discloses upload behavior, metadata removal, 64 MiB/64 MP caps, possible downscaling, non-atomic batches, quote-vs-spending-cap semantics, retry rules, requestId reuse, and the structured return contract. This goes well beyond simple 'upscale this image' and gives an agent realistic expectations of side effects and failures.

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?

The description is long, but it is front-loaded with the core purpose and then parcels planning, retry, and cost guidance into useful clauses. It earns most of its length, though a few operational policies could be tightened without losing meaning; this keeps it just shy of a 5.

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 paid, upload-capable, retry-sensitive tool with no output schema, the description is remarkably complete: it covers prerequisites, cost handling, failure recovery, interaction boundaries, and what the caller receives. An agent has enough context to invoke it correctly and to coordinate with check_skill and list_skills.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description enriches every parameter meaningfully: imageUrl gets path formats, size limits, and metadata behavior; requestId gets retry semantics; confirmedCredits gets quote and budget context; allowDownscale gets a clear charge-related caveat; mode gets user-acceptance considerations. This is far beyond the baseline 3 for complete schemas.

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 — 'Enhance one still image' — and immediately distinguishes the two operating modes, crisp vs creative. It also explicitly separates this from video enhancement and general image generation, making it easy to differentiate from siblings like generate_image and generate_video.

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?

The description gives concrete when-to-use guidance: pass original public URLs, avoid generic reference-image resizing, do not use this for video, and use the dedicated skill directly rather than routing through prompt enhancement or delegation. It references check_skill and list_skills as supporting tools, though it does not explicitly name sibling tools as alternatives for similar still-image operations.

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