Skip to main content
Glama

Restyle an image

restyle

Edits an existing image with AI. COSTS CREDITS (generate_* pricing, like generate_image). Always creates a NEW generation; the original is untouched. Modes: plain-text edit (just instructions); one-click product placement (action bring + reference_id — places the reference's product into the scene at true scale, relit); recolor/remove/add items (use get_detections for item names); merge two images (merge_bias 0=reference dominates, 100=base dominates); art-style transfer (action style + style_intensity 0-100). reference_id can be an asset OR a generation you own. @slug in the prompt or entity_ids attach a saved entity's sheet (list_entities).

Input Schema

NameRequiredDescriptionDefault
itemsNoItems by name (every instance) or, remove only, by get_detections id (that one instance). Required for remove.
actionNoDefault bring.
scan_idNoThe scan_id item ids came from. Default newest.
asset_idNoAn uploaded asset as the base instead; never both.
entity_idsNo
merge_biasNomerge only: 0 reference dominates - 100 base dominates. Default 50.
project_idYesProject for the result.
resolutionNo
blend_levelNoadd only: 0 raw composite - 100 fully unified. Default 50.
merge_scopeNomerge only. Default scene.
aspect_ratioNo
instructionsNoFree-text edit instructions.
reference_idNoAsset or generation to take the product/colors/style/content from.
generation_idNoThe base photo to edit (or asset_id).
style_intensityNostyle only: 0 subtle tint - 100 full reimagine. Default 75.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • changedInput schema / properties / items / description
      Previous value: -"Item names to target (from get_detections). Required for remove."New value: +"Items by name (every instance) or, remove only, by get_detections id (that one instance). Required for remove."
    • addedInput schema / properties / items / items / properties / id
      Added value: +{
      +  "type": "integer"
      +}
    • removedInput schema / properties / items / items / required
      Removed value: -[
      -  "name"
      -]
    • addedInput schema / properties / scan_id
      Added value: +{
      +  "description": "The scan_id item ids came from. Default newest.",
      +  "type": "string"
      +}
  2. Changed3 schema fields changed
    • addedInput schema / properties / asset_id
      Added value: +{
      +  "description": "An uploaded asset as the base instead; never both.",
      +  "type": "string"
      +}
    • changedInput schema / properties / generation_id / description
      Previous value: -"The base photo to edit."New value: +"The base photo to edit (or asset_id)."
    • changedInput schema / required
      Previous value: -[
      -  "generation_id",
      -  "project_id"
      -]New value: +[
      +  "project_id"
      +]
  3. Changed1 schema field changed
    • addedInput schema / properties / entity_ids
      Added value: +{
      +  "items": {
      +    "type": "string"
      +  },
      +  "type": "array"
      +}
  4. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only say readOnlyHint=false and destructiveHint=false; the description adds the costly, credit-consuming nature ('COSTS CREDITS (generate_* pricing)') and, importantly, that the original is never mutated ('Always creates a NEW generation; the original is untouched'). It also discloses source ambiguity for reference_id (asset OR owned generation), which structured fields do not convey.

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?

It is a single dense paragraph, but it is front-loaded with the two highest-stakes facts (cost and non-destructiveness) and each clause adds distinct operational detail. The run-on density and packed mode list cost it the top mark.

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?

For a 15-parameter tool with no output schema, the description covers all five modes, the cost model, non-destructive semantics, and reference/entity sourcing. It omits output shape (acceptable without an output schema) and defaults for resolution/aspect_ratio, but an agent could call it correctly from this text.

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 80%, so the schema already documents most parameters, but the description adds real meaning: it maps actions to required companions, gives merge_bias direction (0=reference, 100=base), and explains that entity_ids/@slug attach a saved entity's sheet. It leaves resolution, aspect_ratio, and blend_level to the schema, so it is strong but not exhaustive.

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+resource ('Edits an existing image with AI') and then enumerates the distinct modes (plain-text edit, product placement, recolor/remove/add, merge, style transfer), which lets an agent distinguish it from siblings like generate_image, expand_image, and cutout. It also names adjacent tools (get_detections, list_entities, generate_image) so the boundary is explicit.

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?

Gives per-mode selection rules ('action bring + reference_id' for placement, 'action style + style_intensity' for style transfer) and routes the agent to alternatives where needed ('use get_detections for item names', 'list_entities' for entity sheets). This is explicit when-to-use guidance rather than inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources