Skip to main content
Glama
danmarce

forge-mcp

by danmarce
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

generate_image

Create images from text prompts on a local SDXL backend, returning an inline preview, exact parameters, and optional full-res PNG base64 for saving.

Instructions

Generate an image (txt2img) on the local SDXL box. Returns an inline preview + (in the text block) the exact params and the full-res PNG base64 to save in your repo.

    Args:
        prompt: the positive prompt, sent VERBATIM (attention weights like `(grey eyes:1.3)` work).
        shot: aspect/framing shortcut — `portrait` (832x1216, default, face-focus), `full-figure`,
            `establishing` (1216x832 scene), `square` (1024). Raw width/height override this.
        model: checkpoint (default DreamShaperXL_Turbo_SFW). Switched only if different from loaded.
        seed: -1 = random (the resolved seed is returned so you can lock it); set it to reproduce.
        steps: default 8 (Turbo). cfg: default 2 (Turbo). sampler/scheduler: DPM++ SDE / Karras (Turbo).
        negative: extra negative text (combined with the profile; the NSFW block is always appended).
        negative_profile: named profile(s), e.g. "sfw-strict" (default), "mature", "candid+sfw-strict".
        style: optional positive preset, e.g. "photoreal".
        width/height: raw size, must be a VRAM-safe bucket (832x1216, 1216x832, 1024x1024).
        include_full: include the full-res PNG base64 in the result (default True; False = preview only,
            lighter for rapid iteration — re-run with the echoed seed to get the full-res of a keeper).

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing return format (inline preview + params + full-res base64 PNG), model-switch behavior ('Switched only if different from loaded'), that the NSFW block is always appended, the VRAM-safe bucket constraint, and that the resolved seed is echoed back. These are genuinely useful behavioral facts an agent needs.

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 core purpose and return info, then a well-structured Args block. It is long, but the length is justified by 14 parameters; a few entries (cfg/steps/sampler/scheduler) are thinner than others, keeping it just under 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 14-parameter local-generation tool with only minimal annotations and no output schema, the description covers purpose, all key parameter semantics, return values, and behavioral constraints. Nothing an agent needs to call it correctly appears to be missing.

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?

With 0% schema description coverage and 14 parameters, the description carries the full burden and documents essentially all of them: prompt verbatim semantics with attention-weight syntax, shot enum-like values with dimensions, seed=-1 meaning and return, profile names, style presets, and the allowed width/height buckets. This compensates thoroughly for the empty schema.

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 description states a specific verb and resource ('Generate an image (txt2img) on the local SDXL box'), which clearly separates it from the edit_image and list_models siblings. It stops short of explicitly naming and contrasting those siblings, so it lands just below a 5.

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?

Provides clear usage context for parameters — include_full=False for rapid iteration, seed=-1 for random vs. locking the echoed seed to reproduce, and the shot shortcuts. However, it never explicitly states when to use this tool versus the alternatives (edit_image, list_models), so it is not a full 5.

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