Skip to main content
Glama
danmarce

forge-mcp

by danmarce
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

edit_image

Edit or vary an image with image-to-image generation from an init image, re-deriving the whole frame for wardrobe, pose, lighting, or hair-mass changes rather than single-feature fixes.

Instructions

Edit/vary an image (img2img). ⚠ HOLISTIC — re-derives the WHOLE frame from the init, so use it for variants that should re-settle (wardrobe, pose, lighting, hair-mass), NOT single-feature fixes (those belong in a PSD — pushing just the eyes also moves skin/age/expression). For character consistency, pass the character's canonical keeper as init_image and its seed/prompt, then change only the delta.

    Args:
        init_image: the source image as base64 (your client reads the keeper PNG from the repo and passes
            it; also load its sidecar params so this render builds on the keeper's recipe).
        denoising_strength: 0.3-0.45 = keep the subject, fix details; 0.5-0.65 = restyle. Default 0.45.
        (all other args: see generate_image.)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cfgNo
seedNo
shotNoportrait
modelNo
stepsNo
styleNo
widthNo
heightNo
promptYes
samplerNoDPM++ SDE
negativeNo
schedulerNoKarras
init_imageYes
include_fullNo
negative_profileNosfw-strict
denoising_strengthNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=false and openWorldHint=false, so the description carries most of the behavioral burden and does it well: it warns that the render is HOLISTIC and will also move skin/age/expression, maps denoising_strength bands to outcomes, and instructs the client to load the keeper's sidecar params. It omits cost/latency, determinism of seed, and return-format behavior, so not a 5.

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 critical ⚠ HOLISTIC caveat before the Args block, and nearly every clause carries actionable information. The Google-style Args formatting is slightly awkward for a tool description and the deferred-args sentence is a bit hand-wavy, but there is little filler.

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

Completeness3/5

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

For a 16-parameter tool with no output schema and thin annotations, the description covers the distinctive behavior and the two key parameters but leaves the bulk of the argument surface to be resolved via generate_image. An agent can call it correctly for the common case but must cross-reference another tool for anything beyond init_image/denoising_strength.

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?

With 16 parameters at 0% schema description coverage, the description documents only init_image and denoising_strength (with concrete 0.3-0.45 / 0.5-0.65 bands and the 0.45 default). The remaining 14 parameters, including the required prompt, are deferred wholesale to generate_image, which is a useful pointer but leaves most of the surface undocumented in place.

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?

States a specific verb and resource ("Edit/vary an image (img2img)") and scopes it precisely: whole-frame re-derivation, not single-feature fixes. It implicitly separates itself from generate_image by noting that tool covers "all other args" and by requiring an init_image, so an agent can route correctly between the two.

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?

Explicit when-to-use and when-not-to-use: use it for variants that should re-settle (wardrobe, pose, lighting, hair-mass), and NOT for single-feature fixes, which "belong in a PSD." It also gives a concrete workflow for character consistency (pass the canonical keeper as init_image plus its seed/prompt, change only the delta).

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

Deploy Server

Other Tools