PixelForge MCP

Overview Schema Source Related Servers Discussions Admin

Advanced Edit

advanced_edit

Edit images through specialized modes for inpainting, outpainting, background swaps, style transfers, and product shots. Pass an optional mask to guide semantic region changes with a Gemini image model.

Instructions

Edit an image with a specialized mode using a Gemini image model.

Each mode wraps the prompt in an instruction tuned for that edit. An optional mask (white = region to change) is passed to the model as guidance; the boundary is interpreted semantically, not pixel-exactly.

Input Schema

Name	Required	Description	Default
`model`	No	Image model to use (default gemini-nano-banana-2.1)
`prompt`	Yes	What to remove, add, replace, or the style to apply
`edit_mode`	Yes	One of: inpaint_removal, inpaint_insertion, outpaint, background_swap, style_transfer, product_image
`mask_path`	No	Optional mask image for the inpainting modes
`image_path`	Yes	Path to the image to edit
`output_format`	No	Output format (png, jpeg, webp)	png
`output_filename`	No	Custom output filename (optional)

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv0.7.0Oct 30, 2026

changedInput schema / properties / mask_path / description

Previous value: -"Optional mask image for inpainting operations"New value: +"Optional mask image for the inpainting modes"

addedInput schema / properties / model

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Image model to use (default gemini-nano-banana-2.1)"
+}

changedInput schema / properties / prompt / description

Previous value: -"Edit instruction"New value: +"What to remove, add, replace, or the style to apply"

First observedv0.5.4Jul 12, 2026

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description carries the full burden and does deliver genuinely useful behavioral detail: an optional mask is guidance only, interpreted semantically rather than pixel-exactly. It is silent on whether the source file is overwritten, where the result is written, and any cost/latency, which matters for a model-inference call.

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?

Two short sentences, front-loaded with the action, and the mask caveat placed immediately after. No filler, though the line break mid-sentence slightly fragments the flow.

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?

Seven parameters, three required, and the most consequential required input (edit_mode, six undocumented enum-like values) gets no guidance on selection or per-mode prerequisites such as which modes need a mask. Output schema exists so return values needn't be explained, but the mode-selection gap keeps this at minimum-viable.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, and the description earns above that by explaining mask_path semantics (white = region to change, soft boundary guidance) and by framing prompt as what the mode-specific wrapper consumes. It adds no color on the model or output_format parameters, but those are self-describing.

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?

States a specific verb and resource ("Edit an image") plus the distinguishing mechanism: a specialized mode backed by a Gemini image model, with per-mode prompt tuning. It does not name or contrast with the obvious sibling edit_image, so an agent cannot be fully certain which of the two to reach for.

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?

Usage is only implied. Nothing says when to prefer advanced_edit over edit_image, or which of the six edit_mode values fits a given intent. The mask note implies the inpainting modes benefit from a mask, but the other four modes are left uncharacterized.

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