Skip to main content
Glama
deeneskoruzh
Txpple

fvtt-mcp-artificer

by Txpple
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

fvtt-mcp-imagegen

An MCP server that lets Claude make art for your Foundry VTT table using Google's Gemini image models (Nano Banana). Four tools, one API key, no GPU.

Claude Code drives it. The server is registered as imagegen, and its illustration-builder skill grounds every piece in what your world already says and shows. Claude writes the prompt, the server renders it, Claude looks at the result and fixes what is wrong, and the finished file lands on disk ready to upload into Foundry.

What you can make

  • Item, spell, and feature icons. Twenty icons from one style line come back as one matching set. About 3 cents each.

  • Tokens. Top-down, full-body, cut to transparency, centred on a square so Foundry's scale 1.0 is right: 512 px, or 1024 px for Large and bigger creatures. Humanoids face up at the camera; beasts are seen along the back. No shadow, and nothing ever clips off the edge: a render with a sword or wing cut by the frame is redone, and refused if it clips twice. Hand it one of your existing tokens as a style reference and new ones match the angle and look. About 3 cents each.

  • Token refreshes. Point it at an old, low-res token and it repaints it at higher quality while keeping the pose, silhouette, design, and colours your players know. It can also turn one creature into another in the same pose (a rat's token into a squirrel).

  • Token redresses. Start from a token you already have as the prototype and change who it is: "make this a Sharran cleric, black armour, a morningstar instead of the club". The pose, camera angle, and cut stay; the costume, gear, and figure change to match the actor it is now for. One stock token becomes the specific NPC in your world without a word of prompt about framing.

  • Token restyles. The same trick as battlemaps, for a whole bestiary. Tokens gathered from different packs (Immortal Nights, Forgotten Adventures, a few you drew yourself) do not match on one map. Hand it one token as the style reference and run the rest through, and they come back in one consistent look, each still recognisably the creature it was.

  • Props. Map dressing placed as tiles: furniture, barrels, trees, anvils. Seen straight down, object only, cut to transparency at the tile size (300 px per grid cell, from a footprint like "2x1"). Refreshing an existing prop returns it at the file's exact pixel size in the same spot on its canvas, so it replaces the old one one for one.

  • Battlemap restyles. Repaint a map you bought (Tom Cartos, Mad Cartographer, anything) in one consistent painted style, with every wall, door, and object exactly where it was, so the walls and lights already traced over it in Foundry still fit. The result lands on the source's own pixel grid. An old low-res map comes back at a whole-number upscale (a 1125×1500 map at 3375×4500). Every render is checked against the original, and one whose layout moved is redone once, then refused. Maps ship as WebP, about 4 MB where a PNG would be 40 to 70. About 11 cents a map.

  • Overland maps. A regional or world map from a sourcebook or a sketch, repainted in the house style with the geography locked and every label, marker, road, compass rose, and scale bar painted out. Names go back on afterwards by script, spelled right and movable, instead of being left to the model. A busy map takes two or three passes to come clean; each is about 11 cents.

  • Portraits. Actor sheet art at 3:4. Hand it a previous portrait or two as style references and the new one matches your table's look.

  • Illustrations. Player handouts and scene splashes at 2560×1600. Hand it your party's portraits as character references and they keep their faces in group scenes.

  • Illustrated session records. With fvtt-mcp-sessionscribe alongside, the recap and GM notes it writes after a session come back illustrated: Claude picks the moments from the record, checks where each one happened against the transcript, attaches the portraits and tokens of everyone in the scene so the same faces recur from one week to the next, and drops the finished plates into the journal and the recap. The worked example is the concluded Greenrest campaign: every recap carries eight or nine plates, and the same shelf of references went on to illustrate the campaign's book.

  • Edits. Change one thing about an existing image and keep the rest: swap a weapon, recolor a cloak, add a scar, fix an extra limb.

  • Cutouts. Knock the background off any token image you already have.

Related MCP server: FoundryVTT MCP Server

The tools

tool

what it does

generate-image

Render one asset from a prompt. kind is icon, token, prop, portrait, or illustration; it picks the model, aspect, size, framing, and post-processing for you. Optional references (character, object, style, or pose), thinking (minimal, medium, high; the result reports the thinking tokens and folds their cost into the estimate) and, for tokens, creatureSize (medium or large); for props, footprint ("2x1"). Every token and portrait render is counted by a judge model against an optional anatomy line from the book (heads, eyes, limbs, hands and fingers, tails, tendrils, held objects, and which edge a token's head points to); the result reports anatomy, each flaw placed in the picture and, for a mis-facing token, the rotation that fixes it.

edit-image

Apply one instruction to an existing image and keep everything else. Token edits are prompted the way you would type in the Gemini app and re-cut automatically: a world token, a library token or a capture of your own is restyled in place with its pose and camera kept, and crops of signature gear can ride along as object references. Takes creatureSize and thinking too, and counts token and portrait edits the same way (anatomy). kind: "battlemap" restyles a bought map with its layout locked (edit only; generate-image refuses it, since a map painted from words has no walls). kind: "overland" does the same for a regional map and paints the lettering out.

cutout-image

Cut a token's background to alpha and deliver it on a square canvas.

imagegen-status

Setup doctor: key present and accepted, models reachable, output folder writable and outside git, cutout Python ready; estimated spend this session.

Every call returns the file path, the pixel size, and an estimated cost.

Models and cost

Everything runs on Nano Banana 2.1 (gemini-nano-banana-2.1) by default: roughly 3 cents for an icon or token, 5 cents for a portrait, 11 cents for an illustration.

Nano Banana Pro (Gemini 3 Pro Image) is available for about double at 4K and four times at 1K. It is stronger on crowded multi-figure scenes and images with legible text. Claude will not use it unless you say so: a Pro call refuses without an explicit confirm and tells you the price first.

Prices are Google's published per-image rates and may change. The server keeps a running estimate; your actual bill is in the Google Cloud console.

Requirements

  • Node.js 22 or newer.

  • A Gemini API key from Google AI Studio with billing enabled: the image models have no free tier. Prepaid credit with auto-reload off is a sensible ceiling.

  • Python 3 with Pillow and numpy for the token cutout: <python> -m pip install -r requirements.txt. rembg is optional and adds an AI matte fallback for busy backgrounds (pip install "rembg[cpu]"; first use downloads a ~176 MB model). On Windows, bare python may be the Microsoft Store placeholder; set IMAGEGEN_PYTHON in .env to the full path of a real python.exe.

Install

git clone https://github.com/Txpple/fvtt-mcp-imagegen.git
cd fvtt-mcp-imagegen
npm install
npm run build
cp .env.example .env

Put your key in .env:

GEMINI_API_KEY=your-key
IMAGEGEN_OUTPUT_DIR=C:\path\where\renders\should\land

The output folder is created on the first render and must sit outside any git repo. Set IMAGEGEN_PYTHON too if bare python is not the interpreter you installed the requirements into.

Check the setup from the terminal before registering anything:

npm run doctor

It loads .env the way the server does and runs the same checks as imagegen-status below, one line each (✓ fine, ! works but worth a look, ✗ broken) with the fix, and exits non-zero until nothing is broken. The key check is a free model listing; it never renders, so it spends no credit. Rerun it after each fix.

Register the server with Claude Code (user scope, so it is available in every project), then restart Claude Code:

claude mcp add -s user imagegen -- "C:/Program Files/nodejs/node.exe" /absolute/path/to/fvtt-mcp-imagegen/dist/index.js

Give node as a full path (which node on macOS or Linux): Claude Code launched from the desktop app may not see it on PATH. A desktop-app install may not put the claude CLI on PATH either; then add the same entry by hand under mcpServers in ~/.claude.json (user scope) and restart:

"mcpServers": {
  "imagegen": {
    "command": "C:/Program Files/nodejs/node.exe",
    "args": ["/absolute/path/to/fvtt-mcp-imagegen/dist/index.js"]
  }
}

.mcp.json.example has the same entry for a project-scoped .mcp.json.

Then ask Claude to run imagegen-status. It is the setup doctor: one line each for the key (present, and accepted by Google, checked with a free model listing), the output folder (writable, outside any git repo), and the cutout Python (Pillow, numpy, rembg), each with the fix when something is wrong (the same checks npm run doctor runs, plus this session's estimated spend). The server also warns at startup when the key is missing.

Using it

Ask Claude for what you want in table terms:

  • "Make icons for these six items."

  • "This goblin needs a token; use my existing orc token as the style reference."

  • "Illustrate the party arriving at the ruined mill at dusk; here are their portraits."

  • "Change this token's cloak to forest green."

  • "This old token looks rough; give it an updated painterly pass."

  • "Make this bandit token a Sharran cleric: black armour, morningstar, keep the pose."

  • "These twelve tokens come from three different packs; restyle them all to match this one."

  • "Illustrate last night's recap; the party's portraits are in this folder."

  • "Cut the background off this token."

Claude reads every render before showing it to you and fixes obvious flaws (an extra limb, a duplicated spell effect) with one edit. Files are named <kind>-<slug>-<id>.png (.webp for a map) so they drop straight into a Foundry asset folder.

With a Foundry MCP server: art grounded in your world

This server only makes pictures. Pair it with a Foundry MCP server such as fvtt-mcp-dnd5e and Claude can read your world before it prompts and put the result back when it is done. Then you can ask for things like:

  • "Make a new token for the dragon in the Wyrmwood." Claude pulls the actor's stat block and bio, opens the token your world already uses for a similar creature so the angle and line style match, renders, cuts to alpha, and can assign it to the actor.

  • "Illustrate the party walking into the dragon's lair for the first time." Claude screenshots the battlemap, finds where the dragon's token is placed, reads the plot notes for the room, attaches the party's portraits so the faces hold, and paints the view from the doors down the hall to the dais.

  • "Illustrate three cool moments from the last few sessions." Claude reads the session recaps and GM notes, picks the scenes, checks which actors were present and what they were carrying that night, and renders each one.

  • "Give this actor a portrait." Claude reads the bio, looks at the existing token so the hair and skin match canon, renders at 3:4, and can set it as the sheet portrait.

  • "Icons for every item in this compendium folder." One shared style line, one call per item, uploaded as a set.

The handoff is files on disk: this server writes them, the Foundry server uploads them (upload-asset, set-actor-art, add-journal-image). Nothing here talks to Foundry directly, so either half works on its own.

With a campaign repo: the same faces every week

Consistency across a campaign comes from a small file, not from luck. A campaign repo keeps an art shelf (art/SHELF.md): one approved portrait per player character with the short phrase that binds it in a prompt ("a bone-white orc in battered steel plate"), two or three finished pieces that carry the house look, the finish words that keep portraits matte and the palette muted, and a note of which older files are superseded and must never be attached again. The illustration-builder skill reads the shelf before every piece, attaches the anchors as character references and the shelf as style references, and proposes a shelf if the repo has none yet.

That is how Session Scribe's records stay illustrated by the same people session after session, how a token redress lands as the actor your world already knows, and how a book assembled at the end of a campaign reads as one artist's work. Greenrest's shelf, its approved art, and the chronicle built from them are public in fvtt-campaign-greenrest.

How it works

Claude ──MCP──> fvtt-mcp-imagegen ──HTTPS──> Gemini image API
                      │
                      ├── sharp: convert, crop, resize
                      └── token_cutout.py: chroma key or rembg → alpha

  • The API returns a JPEG; the server converts to PNG and applies the kind's post-processing (512 square for icons, 16:9 to 16:10 crop for illustrations, cutout for tokens).

  • Tokens are rendered on a flat chroma plate, then keyed out. Magenta is the default because soft edges keep a trace of the plate and a magenta trace reads as a dark outline on warm subjects (skin, hair, fur, leather) where green reads as an olive fringe; green or blue takes over for purple, pink, or violet subjects. A magenta-composited preview is written beside every cut so the edge can be checked.

  • Before a token is cut, the server checks the plate's outer edge for subject pixels. A clipped render is redone once and refused if it clips again.

  • A battlemap is sent padded to the nearest aspect the API renders (a mirrored margin), and the render is mapped back onto the source's pixel grid. The API scales its input to cover the output and trims the excess, so a "3:4" render is 1792×2400, not 1800×2400. Then both images are reduced to edge strength and compared tile by tile (phase correlation): a restyle changes colour and texture, edges stay put. More than 3% of tiles moved by over 0.4% of the long side means the layout drifted. A checkerboard of source and result is written beside every map for the eye.

  • A render the image safety filter blocks is retried once; the filter is not consistent on the same input.

  • No local models, no fine-tuning, no ComfyUI. Style comes from reference images you attach.

Development

npm test          # offline unit suite; nothing hits the live API
npm run typecheck
npm run check     # biome
npm run knip
npm run doctor    # the setup checks against your .env (needs a build)

npm ci runs two install scripts, both allowed in package.json under allowScripts: esbuild's (it checks its platform binary; vitest's bundler) and classic-level's (it picks the prebuilt LevelDB binding; the Foundry CLI behind scripts/unpack_leveldb.mjs). Neither is used by the server at runtime.

Part of Open Roll 5e

fvtt-mcp-imagegen is one of the three MCP servers in Open Roll 5e, a suite of Foundry VTT modules and Claude Code tooling built for one D&D 5e table and shared. The other servers:

  • fvtt-mcp-dnd5e: builds D&D 5e content in a live Foundry world from Claude Code: a stat block becomes a complete NPC, a map image a walled and lit scene, an adventure its journals, tables and handouts.

  • fvtt-mcp-sessionscribe: turns a session's Discord recording and Foundry chat log into its record. Its end-to-end session-scribe skill drives the server from the Craig link to a speaker-labelled transcript, a fully illustrated player recap, combat statistics, GM notes and a party snapshot.

The modules, each of which installs and works on its own and none of which needs another:

  • Open Roll 5e: Autoexplore: lets a scene start fully explored, so the whole map shows through the fog of war while tokens still need line of sight.

  • Open Roll 5e: By the Books: the 2024 rules played from the sheet: a hit rolls and applies its own damage, saves resolve themselves, reactions hold, concentration is tracked, and rests, senses, sizes and lights follow the book. Every rule that rides a use or an effect in the 2024 core books, Heroes of Faerûn, Arcana Unleashed and Ravenloft: The Horrors Within, each step with a receipt and a revert; offered, never enforced.

  • Open Roll 5e: Combat Plus: automates the chores of running a fight: combat music, an initiative gate, an out-of-turn movement block, defeated marking at 0 HP and turn alerts.

  • Open Roll 5e: Errata: corrects, in memory, bugs in the premium D&D 2024 books, the dnd5e system and Foundry itself, each fix held until the vendor ships its own.

  • Open Roll 5e: FX Studio: visual and sound effects for dnd5e, played from what actually happened at the table, with about a thousand stock FX and a window for authoring your own.

  • Open Roll 5e: Loot Shelf: loot chests and merchant shelves that players can take from, buy from and sell to without owning them, with a receipt for every trade.

  • Open Roll 5e: Open Server: for hosted worlds: clears the startup pause so players can play before the GM arrives, and gives every user a one-click jump to their character's token, and their familiar's, from the Players list.

  • Open Roll 5e: Party Stash: makes a dnd5e Group actor's inventory a working party stash: drags move instead of copying, coin moves through a dialog, and every transfer posts a receipt.

  • Open Roll 5e: Area Sounds: background sound for scenes: random one-shots with silence between them, seamless crossfaded loops, day and night gating, and quiet during combat.

  • Open Roll 5e: Token Art: gives every token the look of its state, ready, in combat or dead, each a file named beside the base art, with nothing to configure.

Issues are welcome on every repo in the family; pull requests are not accepted, since each is one author's design for one table, shared because it might suit yours. How they fit together is mapped in fvtt-suite-openroll5e.

License

MIT. See LICENSE.

Available Tools

4 tools
cutout-imageA

Knock the background off a token image to real alpha and deliver it centred on a 512 square so Foundry scale 1.0 is right. Writes a magenta-composited *_preview.png beside it: READ THAT before trusting the edge. Returns coverage, residual-key and haze numbers; a cut that fails any of them falls back to the rembg AI matte automatically.

NameRequiredDescriptionDefault
sizeNoSquare canvas edge; default 512 (Foundry scale 1.0). 0 keeps the source canvas.
trimNoTighten to the subject before fitting (default true); false letterboxes as-is.
colorNoChroma key colour: "green", "magenta", "blue", or #RRGGBB. Omit to sample the corners.
erodeNoShrink the matte N px to eat a fringe.
methodNoauto (default): chroma if the plate is a flat key colour, with a rembg fallback when the cut fails verification. chroma: flat green/blue/magenta/solid plates, instant. rembg: AI matte for busy backgrounds, hair, and soft edges (first use downloads a ~176 MB model).
outputNoAbsolute output path (.png). Default: next to the source as <name>-cut.png.
padPctNoTransparent margin, % of the edge (4).
dropShadowNoAdd the world tokens' soft cast shadow (dark silhouette, ~38%, down-right) under the cut. Off by default; tokens from this server go out shadowless (owner rule 2026-09-24).
keepShadowNochroma only: keep a cast shadow on the plate.
sourceImageYesAbsolute path of the image to cut (PNG/JPEG/WebP).

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so well: it declares the side-effecting file write (a magenta-composited *_preview.png beside the output), the returned verification numbers (coverage, residual-key, haze), and the automatic fallback to the rembg AI matte when a cut fails those checks. These are non-obvious behaviors the agent could not infer from the schema.

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?

Three front-loaded sentences with no filler: purpose first, then the verification artifact, then the fallback behavior. The jargon ('real alpha', 'Foundry scale 1.0', 'residual-key') is dense but domain-appropriate, though the second sentence's emphasis on reading the preview is slightly buried.

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 10-parameter, no-annotation, no-output-schema tool, the description covers the crucial non-schema facts: the file side effect, the metrics returned, and the fallback policy. It leaves out default output naming and failure/error surfacing, but those are largely covered by the 100%-covered schema, so the remaining gap is minor.

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?

Schema coverage is 100%, so the schema already documents all 10 parameters in detail. The description only echoes the 512-square default and the preview artifact; it adds no syntax, format, or constraint detail beyond what the schema provides. Baseline 3 is appropriate here.

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 + resource ('Knock the background off a token image') and adds the output contract (true alpha, centred on a 512 square for Foundry scale 1.0). It is unmistakably distinct from the siblings generate-image, edit-image, and imagegen-status, so an agent can select it on name and purpose alone.

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?

It tells the agent to read the *_preview.png before trusting the edge and implies the rembg fallback path when verification fails, which is real operational guidance. However, it never explicitly states when NOT to use this tool or names an alternative among the sibling tools, so it falls short of a full when/when-not routing instruction.

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

edit-imageA

Edit an existing image with one instruction while keeping identity, pose, angle, and style. Flash for every kind (pro was no better at fixes and re-cropped once). Tokens are prompted light (your instruction as you would type it in the Gemini app, plus a keep-face/hair/angle line and "remove any cast shadow"), put back on a chroma plate keyed to the token's own colours, and cut to alpha on the 512 square in the same call. "give this an updated painterly style" restyles a world token in place; a token from any library or a capture of your own is restyled the same way, its pose and camera kept. Every token and portrait edit is counted by a judge model (heads, eyes, limbs, hands and fingers, tails, tendrils, held objects, and a token's facing) against an optional anatomy line from the book; the result reports anatomy: what it found, each flaw placed in the picture, and for a token the rotation that brings its front to the top. Props (kind "prop") get object-only wording (no figures added) and come back cut at the source file's exact pixel size, ready for the same tile slot. Battlemaps (kind "battlemap") restyle a bought map with the layout locked: the result lands on the source's pixel grid (a whole-number upscale when the source is small), is checked for drift against the source (a drifted render is redone once, then refused), and comes with a checkerboard image of source and result to eyeball. A dressing pass (dressing: true, battlemaps only) adds furniture and props, which the check reads as moved layout, so it renders once and reports drift without retrying or refusing. Overland maps (kind "overland") repaint a regional or world map the same way, painted bare of every name, marker, road, compass rose and scale bar (letter them on afterwards), with a looser drift check that refuses only a grossly moved geography. Returns the new file path, dimensions, and estimated spend.

NameRequiredDescriptionDefault
kindYesPurpose preset. icon: 1:1 flash → 512 square. prop: a map prop (furniture, barrel, tree) seen straight down, object only, cut to alpha at its tile size (300 px per grid cell; an edit keeps the source size). token: 1:1 flash, top-down full body on a chroma plate, cut to alpha on a 512 square (1024 for creatureSize: "large"), no shadow (framing, plate, and cut are done for you). portrait: 3:4 at 2K. illustration: 16:9 at 4K → 2560×1600 (16:10 crop). battlemap (edit-image only): restyle a bought map with its layout locked, delivered on the source's pixel grid (a whole-number upscale for a small source), drift-checked. overland (edit-image only): repaint a regional or world map on the same grid, bare of every name and symbol, with a looser drift check. Every kind defaults to flash; tier: "pro" is opt-in and needs confirmPro.
slugYesKebab-cased into the filename: <kind>-<slug>-<id>.png.
tierNoDefault flash (Nano Banana 2.1, ~3-11¢), never needs a confirm. "pro" (Nano Banana Pro, ~13-24¢, style-reference slots, stronger multi-figure scenes) needs confirmPro.
anatomyNoTokens and portraits only: what the creature should have, in one line from the Monster Manual ("two arms, two legs, one large eye, no tail"; "a mushroom with exactly four tendrils and no limbs"). Every token and portrait render is shown to the judge model, which counts heads, eyes, limbs, hands and fingers, tails, tendrils and held objects, flags what differs from this line (with no line, only what is wrong on any creature), and for a token says which edge the head points to (Foundry's front is the top; the report gives the rotation that fixes it); the result reports `anatomy`. Read it, then look anyway: the judge can be wrong, and a flaw is one edit-image call away.
dressingNoBattlemaps only: this pass adds dressing (furniture, props, debris, foliage) rather than restyling the paint, so the drift check is advisory: one render, delivered under its normal name with `drift` and the checkerboard reported, never redone and never refused (every added piece reads to the check as moved layout). Check the walls by eye on the checkerboard. The result carries `dressing: true`.
thinkingNoHow much the model thinks before it draws (Nano Banana 2.1: minimal, medium, high; the default is medium). Thinking is billed at the text rate, from a fraction of a cent to a few cents a render; the result reports thinkingTokens. Try "high" on a prompt that carries many constraints at once (a token with a face and several pieces of gear to match).
confirmProNoRequired true with tier: "pro". Offer pro to the owner as an option for portraits and illustrations ("pro is available for a bit extra"); never assume it.
referencesNoOptional extra references (attached after the source; indexes start at 2).
instructionYesThe change, and only the change: "replace the greatsword with a war maul crackling with violet energy". For a flaw-fix pass, name every flaw precisely in one instruction ("the left peryton has four legs; give it two", "remove the second fireball") and end with "keep everything else identical". Everything else is kept by the tool's own wording.
sourceImageYesAbsolute path of the image to edit (PNG/JPEG/WebP).
creatureSizeNoTokens only. medium (default): one grid cell, Tiny through Medium, a 512 square. large: Large, Huge, or Gargantuan, a 1024 square, the native render edge.

TDQS

A3.9/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 behavioral burden and mostly does: it discloses the chroma-plate/alpha-cut pipeline, the judge-model anatomy pass, battlemap drift retry-then-refuse, dressing never-retried, and the returned file path/dimensions/spend. But the wall of prose buries these traits, the retry semantics are spread across run-on clauses, and it never states permissions or what happens on a failed edit, capping it below top marks.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose is front-loaded, but the body is one enormous paragraph of parenthetical asides and anecdotes ("pro was no better at fixes and re-cropped once") that add noise for an agent scanning for routing signal. Information density is high but structure and economy are weak.

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 an 11-parameter, multi-mode tool with no output schema, it covers every kind's behavior, the anatomy reporting, drift/retry policy, and the return payload. Nothing an agent needs to call it correctly in any mode is missing.

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?

Schema coverage is 100% and the schema already documents kind, tier, anatomy, dressing, thinking, references, and creatureSize in depth, so the description largely restates structured data. Coverage is high enough that the baseline 3 is appropriate; the description adds little parameter meaning the schema doesn't already carry.

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 opening sentence names a specific verb (Edit) and resource (an existing image) plus its defining constraint: one instruction while preserving identity, pose, angle, and style. That cleanly separates it from the generate-image sibling, which has no source to preserve.

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?

It gives explicit when-to-use guidance for internal modes: flash for every kind, pro only for portraits/illustrations and needing confirmPro, dressing only on battlemaps, anatomy only on tokens/portraits. It never explicitly routes against the sibling tools (generate-image, cutout-image), so it stops short of full alternative guidance.

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

generate-imageA

Generate one Foundry art asset from a prompt via the Gemini image API. kind picks the model tier, aspect, size, framing text, and post-processing; the result is a finished PNG on disk. READ IT before showing anyone: count limbs per creature, check for duplicated spell effects or props, stray signatures, and reference faces on the wrong figure; obvious flaws are one edit-image call away. Every token and portrait render is also counted by a judge model (heads, eyes, limbs, hands and fingers, tails, tendrils, held objects, and a token's facing) against an optional anatomy line from the book; the result reports anatomy. Every kind runs on flash by default; tier: "pro" refuses without confirmPro: true and states the cost. Returns the file path, dimensions, and estimated spend.

NameRequiredDescriptionDefault
kindYesPurpose preset. icon: 1:1 flash → 512 square. prop: a map prop (furniture, barrel, tree) seen straight down, object only, cut to alpha at its tile size (300 px per grid cell; an edit keeps the source size). token: 1:1 flash, top-down full body on a chroma plate, cut to alpha on a 512 square (1024 for creatureSize: "large"), no shadow (framing, plate, and cut are done for you). portrait: 3:4 at 2K. illustration: 16:9 at 4K → 2560×1600 (16:10 crop). battlemap (edit-image only): restyle a bought map with its layout locked, delivered on the source's pixel grid (a whole-number upscale for a small source), drift-checked. overland (edit-image only): repaint a regional or world map on the same grid, bare of every name and symbol, with a looser drift check. Every kind defaults to flash; tier: "pro" is opt-in and needs confirmPro.
slugYesKebab-cased into the filename: <kind>-<slug>-<id>.png.
tierNoDefault flash (Nano Banana 2.1, ~3-11¢), never needs a confirm. "pro" (Nano Banana Pro, ~13-24¢, style-reference slots, stronger multi-figure scenes) needs confirmPro.
promptYesWhat a camera would see, in illustrator terms. Do not add framing or background text for icons and tokens; the preset appends it.
anatomyNoTokens and portraits only: what the creature should have, in one line from the Monster Manual ("two arms, two legs, one large eye, no tail"; "a mushroom with exactly four tendrils and no limbs"). Every token and portrait render is shown to the judge model, which counts heads, eyes, limbs, hands and fingers, tails, tendrils and held objects, flags what differs from this line (with no line, only what is wrong on any creature), and for a token says which edge the head points to (Foundry's front is the top; the report gives the rotation that fixes it); the result reports `anatomy`. Read it, then look anyway: the judge can be wrong, and a flaw is one edit-image call away.
thinkingNoHow much the model thinks before it draws (Nano Banana 2.1: minimal, medium, high; the default is medium). Thinking is billed at the text rate, from a fraction of a cent to a few cents a render; the result reports thinkingTokens. Try "high" on a prompt that carries many constraints at once (a token with a face and several pieces of gear to match).
footprintNoProps only: grid cells wide x tall, e.g. "2x1" for a table (default "1x1"). The prop is rendered at the nearest API aspect and delivered at 300 px per cell (600x300 here). Library files carry it in their name: "TC_Anvil 02_2x1.png".
confirmProNoRequired true with tier: "pro". Offer pro to the owner as an option for portraits and illustrations ("pro is available for a bit extra"); never assume it.
referencesNoReference images, attached in this order. Bind each in the prompt by its label or 1-based index ("Image 2 is the captain").
creatureSizeNoTokens only. medium (default): one grid cell, Tiny through Medium, a 512 square. large: Large, Huge, or Gargantuan, a 1024 square, the native render edge.

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations the description carries the whole burden and does: default tier, pro cost range and the confirmPro gate, that pro refuses without confirmation, billed thinking tokens, disk output, a judge model that checks anatomy on tokens and portraits, and what the result reports (path, dimensions, spend, anatomy, thinkingTokens). That is exactly the behavioral context annotations would otherwise supply.

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 action and output in the first sentence, with operational warnings after. It is dense and mostly earns its sentences, though the anatomy/verification material appears twice (once in the body, once in the anatomy parameter), costing a little tightness.

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?

A 10-parameter, 7-value enum generation tool with no output schema still needs the description to say what comes back, and it does: file path, dimensions, estimated spend, anatomy report, thinkingTokens. It also covers the cost gate and the default model, leaving nothing an agent needs before a first call.

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?

Schema description coverage is 100%, so every parameter is already documented in the schema and the description largely restates it (kind picks tier/aspect/size, pro needs confirmPro). The prose reinforces the safety-critical interaction between tier and confirmPro and the read-back of anatomy, but adds no syntax or format detail the schema lacks. Baseline 3 applies.

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 ('Generate one Foundry art asset from a prompt via the Gemini image API') plus the output form (a finished PNG on disk), and the first paragraph already contrasts the result with the fix path via the sibling edit-image. An agent can distinguish it from edit-image, cutout-image, and imagegen-status without opening a schema.

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?

Gives real usage constraints: inspect every render before showing anyone, use edit-image for one-call fixes, offer 'pro' only as an option and never assume it. It also notes battlemap/overland are edit-image-only kinds, which routes correctly. It does not spell out explicit when-not-to-use conditions (e.g. when to prefer cutout-image over the token preset's built-in alpha cut).

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

imagegen-statusA

Setup doctor and health check: API key present and accepted (no generation credit spent), which image models the key can reach, the output directory (writable, outside any git repo), the cutout Python (Pillow, numpy, rembg), and estimated session spend by tier. Call this first on a cold start.

NameRequiredDescriptionDefault

No parameters

TDQS

A4/5.0
Behavior4/5

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

With no annotations at all, the description carries the full behavioral burden and does well: it explicitly notes the check spends no generation credit, discloses that it inspects spend by tier, and reveals side-effect-relevant facts like the output directory needing to be writable and outside a git repo. It doesn't clarify whether the check merely verifies or actually creates/repairs directories, which is the one meaningful ambiguity for a tool with no readOnlyHint.

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 purpose is front-loaded ("Setup doctor and health check") followed by a tight enumeration of checks, ending with the call-first directive in the highest-salience position. The middle sentence is dense with comma-separated checks but every item carries distinct information; nothing is padding.

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 zero-parameter tool with no annotations and no output schema, the description covers everything an agent needs to decide to call it and what it will learn. The only gap is a lack of indication of what the response looks like (pass/fail report vs. structured diagnostics), which matters slightly more because no output schema exists.

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?

The schema has zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly adds no spurious parameter guidance.

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 enumerates concretely what the tool inspects: API key validity, reachable image models, output directory writability and git-repo placement, cutout Python dependencies, and estimated spend. This makes it unmistakably a diagnostic/health-check tool rather than a generation tool. It never names the siblings (generate-image, edit-image, cutout-image) explicitly, so it falls short of 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?

"Call this first on a cold start" gives an explicit trigger condition, which is exactly the routing guidance an agent needs before invoking generation siblings. There is no stated when-not-to-use case (e.g., calling it repeatedly mid-session), but the positive guidance is clear and actionable.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 4 tool updatesv1.3.2
    • Removedartificer-status
    • Changededit-image10 fields changed
      • addedInput schema / properties / anatomy
        Added value: +{
+  "description": "Tokens and portraits only: what the creature should have, in one line from the Monster Manual (\"two arms, two legs, one large eye, no tail\"; \"a mushroom with exactly four tendrils and no limbs\"). Every token and portrait render is shown to the judge model, which counts heads, eyes, limbs, hands and fingers, tails, tendrils and held objects, flags what differs from this line (with no line, only what is wrong on any creature), and for a token says which edge the head points to (Foundry's front is the top; the report gives the rotation that fixes it); the result reports `anatomy`. Read it, then look anyway: the judge can be wrong, and a flaw is one edit-image call away.",
+  "maxLength": 400,
+  "minLength": 1,
+  "type": "string"
+}
      • addedInput schema / properties / dressing
        Added value: +{
+  "description": "Battlemaps only: this pass adds dressing (furniture, props, debris, foliage) rather than restyling the paint, so the drift check is advisory: one render, delivered under its normal name with `drift` and the checkerboard reported, never redone and never refused (every added piece reads to the check as moved layout). Check the walls by eye on the checkerboard. The result carries `dressing: true`.",
+  "type": "boolean"
+}
      • changedInput schema / properties / kind / description
        Previous value: -"Purpose preset. icon: 1:1 flash → 512 square. prop: a map prop (furniture, barrel, tree) seen straight down, object only, cut to alpha at its tile size (300 px per grid cell; an edit keeps the source size). token: 1:1 flash, top-down full body on a chroma plate, cut to alpha on a 512 square (1024 for creatureSize: \"large\"), no shadow (framing, plate, and cut are done for you). portrait: 3:4 at 2K. illustration: 16:9 at 4K → 2560×1600 (16:10 crop). Every kind defaults to flash; tier: \"pro\" is opt-in and needs confirmPro."New value: +"Purpose preset. icon: 1:1 flash → 512 square. prop: a map prop (furniture, barrel, tree) seen straight down, object only, cut to alpha at its tile size (300 px per grid cell; an edit keeps the source size). token: 1:1 flash, top-down full body on a chroma plate, cut to alpha on a 512 square (1024 for creatureSize: \"large\"), no shadow (framing, plate, and cut are done for you). portrait: 3:4 at 2K. illustration: 16:9 at 4K → 2560×1600 (16:10 crop). battlemap (edit-image only): restyle a bought map with its layout locked, delivered on the source's pixel grid (a whole-number upscale for a small source), drift-checked. overland (edit-image only): repaint a regional or world map on the same grid, bare of every name and symbol, with a looser drift check. Every kind defaults to flash; tier: \"pro\" is opt-in and needs confirmPro."
      • changedInput schema / properties / kind / enum
        Previous value: -[
-  "icon",
-  "token",
-  "prop",
-  "portrait",
-  "illustration"
-]New value: +[
+  "icon",
+  "token",
+  "prop",
+  "portrait",
+  "illustration",
+  "battlemap",
+  "overland"
+]
      • changedInput schema / properties / references / items / properties / label / description
        Previous value: -"Short name used to bind the reference in the prompt, e.g. \"Morgash\"."New value: +"Short name used to bind the reference in the prompt, e.g. \"the captain\"."
      • changedInput schema / properties / references / items / properties / role / description
        Previous value: -"character: hold this face/figure (up to 4 on flash, 5 on pro). style: match palette, brushwork, light, camera angle; never copy the subject (works on both tiers in practice). pose: match only its pose, head direction, camera angle, and silhouette, never its drawing; for replacing a weak token, attach the old one as the ONLY image with this role."New value: +"character: hold the features, hair, skin, build and kit of this person (up to 4 on flash, 5 on pro); the pose, head angle and camera come from the prompt and the source image, so a crop already at the angle you want beats a frontal portrait. Identity only: the reference's lighting, palette, glow, background and camera are never taken, so a token made from a portrait crop is lit by its own scene, not the portrait's. object: reproduce this exact object (a crop of a weapon head, a shield face, a garment) in shape, materials, colours and markings (up to 10 on flash, 6 on pro). style: match palette, brushwork, light, camera angle; never copy the subject (works on both tiers in practice). pose: match only its pose, head direction, camera angle, and silhouette, never its drawing; for replacing a weak token, attach the old one as the ONLY image with this role."
      • changedInput schema / properties / references / items / properties / role / enum
        Previous value: -[
-  "character",
-  "style",
-  "pose"
-]New value: +[
+  "character",
+  "object",
+  "style",
+  "pose"
+]
      • changedInput schema / properties / references / maxItems
        Previous value: -13New value: +12
      • addedInput schema / properties / thinking
        Added value: +{
+  "description": "How much the model thinks before it draws (Nano Banana 2.1: minimal, medium, high; the default is medium). Thinking is billed at the text rate, from a fraction of a cent to a few cents a render; the result reports thinkingTokens. Try \"high\" on a prompt that carries many constraints at once (a token with a face and several pieces of gear to match).",
+  "enum": [
+    "minimal",
+    "medium",
+    "high"
+  ],
+  "type": "string"
+}
      • changedInput schema / properties / tier / description
        Previous value: -"Default flash (Nano Banana 2, ~7-15¢), never needs a confirm. \"pro\" (Nano Banana Pro, ~13-24¢, style-reference slots, stronger multi-figure scenes) needs confirmPro."New value: +"Default flash (Nano Banana 2.1, ~3-11¢), never needs a confirm. \"pro\" (Nano Banana Pro, ~13-24¢, style-reference slots, stronger multi-figure scenes) needs confirmPro."
    • Changedgenerate-image9 fields changed
      • addedInput schema / properties / anatomy
        Added value: +{
+  "description": "Tokens and portraits only: what the creature should have, in one line from the Monster Manual (\"two arms, two legs, one large eye, no tail\"; \"a mushroom with exactly four tendrils and no limbs\"). Every token and portrait render is shown to the judge model, which counts heads, eyes, limbs, hands and fingers, tails, tendrils and held objects, flags what differs from this line (with no line, only what is wrong on any creature), and for a token says which edge the head points to (Foundry's front is the top; the report gives the rotation that fixes it); the result reports `anatomy`. Read it, then look anyway: the judge can be wrong, and a flaw is one edit-image call away.",
+  "maxLength": 400,
+  "minLength": 1,
+  "type": "string"
+}
      • changedInput schema / properties / kind / description
        Previous value: -"Purpose preset. icon: 1:1 flash → 512 square. prop: a map prop (furniture, barrel, tree) seen straight down, object only, cut to alpha at its tile size (300 px per grid cell; an edit keeps the source size). token: 1:1 flash, top-down full body on a chroma plate, cut to alpha on a 512 square (1024 for creatureSize: \"large\"), no shadow (framing, plate, and cut are done for you). portrait: 3:4 at 2K. illustration: 16:9 at 4K → 2560×1600 (16:10 crop). Every kind defaults to flash; tier: \"pro\" is opt-in and needs confirmPro."New value: +"Purpose preset. icon: 1:1 flash → 512 square. prop: a map prop (furniture, barrel, tree) seen straight down, object only, cut to alpha at its tile size (300 px per grid cell; an edit keeps the source size). token: 1:1 flash, top-down full body on a chroma plate, cut to alpha on a 512 square (1024 for creatureSize: \"large\"), no shadow (framing, plate, and cut are done for you). portrait: 3:4 at 2K. illustration: 16:9 at 4K → 2560×1600 (16:10 crop). battlemap (edit-image only): restyle a bought map with its layout locked, delivered on the source's pixel grid (a whole-number upscale for a small source), drift-checked. overland (edit-image only): repaint a regional or world map on the same grid, bare of every name and symbol, with a looser drift check. Every kind defaults to flash; tier: \"pro\" is opt-in and needs confirmPro."
      • changedInput schema / properties / kind / enum
        Previous value: -[
-  "icon",
-  "token",
-  "prop",
-  "portrait",
-  "illustration"
-]New value: +[
+  "icon",
+  "token",
+  "prop",
+  "portrait",
+  "illustration",
+  "battlemap",
+  "overland"
+]
      • changedInput schema / properties / references / description
        Previous value: -"Reference images, attached in this order. Bind each in the prompt by its label or 1-based index (\"Image 2 is Morgash\")."New value: +"Reference images, attached in this order. Bind each in the prompt by its label or 1-based index (\"Image 2 is the captain\")."
      • changedInput schema / properties / references / items / properties / label / description
        Previous value: -"Short name used to bind the reference in the prompt, e.g. \"Morgash\"."New value: +"Short name used to bind the reference in the prompt, e.g. \"the captain\"."
      • changedInput schema / properties / references / items / properties / role / description
        Previous value: -"character: hold this face/figure (up to 4 on flash, 5 on pro). style: match palette, brushwork, light, camera angle; never copy the subject (works on both tiers in practice). pose: match only its pose, head direction, camera angle, and silhouette, never its drawing; for replacing a weak token, attach the old one as the ONLY image with this role."New value: +"character: hold the features, hair, skin, build and kit of this person (up to 4 on flash, 5 on pro); the pose, head angle and camera come from the prompt and the source image, so a crop already at the angle you want beats a frontal portrait. Identity only: the reference's lighting, palette, glow, background and camera are never taken, so a token made from a portrait crop is lit by its own scene, not the portrait's. object: reproduce this exact object (a crop of a weapon head, a shield face, a garment) in shape, materials, colours and markings (up to 10 on flash, 6 on pro). style: match palette, brushwork, light, camera angle; never copy the subject (works on both tiers in practice). pose: match only its pose, head direction, camera angle, and silhouette, never its drawing; for replacing a weak token, attach the old one as the ONLY image with this role."
      • changedInput schema / properties / references / items / properties / role / enum
        Previous value: -[
-  "character",
-  "style",
-  "pose"
-]New value: +[
+  "character",
+  "object",
+  "style",
+  "pose"
+]
      • addedInput schema / properties / thinking
        Added value: +{
+  "description": "How much the model thinks before it draws (Nano Banana 2.1: minimal, medium, high; the default is medium). Thinking is billed at the text rate, from a fraction of a cent to a few cents a render; the result reports thinkingTokens. Try \"high\" on a prompt that carries many constraints at once (a token with a face and several pieces of gear to match).",
+  "enum": [
+    "minimal",
+    "medium",
+    "high"
+  ],
+  "type": "string"
+}
      • changedInput schema / properties / tier / description
        Previous value: -"Default flash (Nano Banana 2, ~7-15¢), never needs a confirm. \"pro\" (Nano Banana Pro, ~13-24¢, style-reference slots, stronger multi-figure scenes) needs confirmPro."New value: +"Default flash (Nano Banana 2.1, ~3-11¢), never needs a confirm. \"pro\" (Nano Banana Pro, ~13-24¢, style-reference slots, stronger multi-figure scenes) needs confirmPro."
    • Addedimagegen-status
  2. 3 tool updatesv1.1.0
    • Changedcutout-image1 field changed
      • addedInput schema / properties / dropShadow
        Added value: +{
+  "description": "Add the world tokens' soft cast shadow (dark silhouette, ~38%, down-right) under the cut. Off by default; tokens from this server go out shadowless (owner rule 2026-09-24).",
+  "type": "boolean"
+}
    • Changededit-image5 fields changed
      • addedInput schema / properties / creatureSize
        Added value: +{
+  "description": "Tokens only. medium (default): one grid cell, Tiny through Medium, a 512 square. large: Large, Huge, or Gargantuan, a 1024 square, the native render edge.",
+  "enum": [
+    "medium",
+    "large"
+  ],
+  "type": "string"
+}
      • changedInput schema / properties / kind / description
        Previous value: -"Purpose preset. icon: 1:1 flash → 512 square. token: 1:1 flash, top-down full body on a chroma plate, cut to alpha on a 512 square (framing, plate, and cut are done for you). portrait: 3:4 at 2K. illustration: 16:9 at 4K → 2560×1600 (16:10 crop). Every kind defaults to flash; tier: \"pro\" is opt-in and needs confirmPro."New value: +"Purpose preset. icon: 1:1 flash → 512 square. prop: a map prop (furniture, barrel, tree) seen straight down, object only, cut to alpha at its tile size (300 px per grid cell; an edit keeps the source size). token: 1:1 flash, top-down full body on a chroma plate, cut to alpha on a 512 square (1024 for creatureSize: \"large\"), no shadow (framing, plate, and cut are done for you). portrait: 3:4 at 2K. illustration: 16:9 at 4K → 2560×1600 (16:10 crop). Every kind defaults to flash; tier: \"pro\" is opt-in and needs confirmPro."
      • changedInput schema / properties / kind / enum
        Previous value: -[
-  "icon",
-  "token",
-  "portrait",
-  "illustration"
-]New value: +[
+  "icon",
+  "token",
+  "prop",
+  "portrait",
+  "illustration"
+]
      • changedInput schema / properties / references / items / properties / role / description
        Previous value: -"character: hold this face/figure (up to 4 on flash, 5 on pro). style: match palette, brushwork, light, camera angle; never copy the subject (works on both tiers in practice)."New value: +"character: hold this face/figure (up to 4 on flash, 5 on pro). style: match palette, brushwork, light, camera angle; never copy the subject (works on both tiers in practice). pose: match only its pose, head direction, camera angle, and silhouette, never its drawing; for replacing a weak token, attach the old one as the ONLY image with this role."
      • changedInput schema / properties / references / items / properties / role / enum
        Previous value: -[
-  "character",
-  "style"
-]New value: +[
+  "character",
+  "style",
+  "pose"
+]
    • Changedgenerate-image6 fields changed
      • addedInput schema / properties / creatureSize
        Added value: +{
+  "description": "Tokens only. medium (default): one grid cell, Tiny through Medium, a 512 square. large: Large, Huge, or Gargantuan, a 1024 square, the native render edge.",
+  "enum": [
+    "medium",
+    "large"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / footprint
        Added value: +{
+  "description": "Props only: grid cells wide x tall, e.g. \"2x1\" for a table (default \"1x1\"). The prop is rendered at the nearest API aspect and delivered at 300 px per cell (600x300 here). Library files carry it in their name: \"TC_Anvil 02_2x1.png\".",
+  "pattern": "^\\d{1,2}x\\d{1,2}$",
+  "type": "string"
+}
      • changedInput schema / properties / kind / description
        Previous value: -"Purpose preset. icon: 1:1 flash → 512 square. token: 1:1 flash, top-down full body on a chroma plate, cut to alpha on a 512 square (framing, plate, and cut are done for you). portrait: 3:4 at 2K. illustration: 16:9 at 4K → 2560×1600 (16:10 crop). Every kind defaults to flash; tier: \"pro\" is opt-in and needs confirmPro."New value: +"Purpose preset. icon: 1:1 flash → 512 square. prop: a map prop (furniture, barrel, tree) seen straight down, object only, cut to alpha at its tile size (300 px per grid cell; an edit keeps the source size). token: 1:1 flash, top-down full body on a chroma plate, cut to alpha on a 512 square (1024 for creatureSize: \"large\"), no shadow (framing, plate, and cut are done for you). portrait: 3:4 at 2K. illustration: 16:9 at 4K → 2560×1600 (16:10 crop). Every kind defaults to flash; tier: \"pro\" is opt-in and needs confirmPro."
      • changedInput schema / properties / kind / enum
        Previous value: -[
-  "icon",
-  "token",
-  "portrait",
-  "illustration"
-]New value: +[
+  "icon",
+  "token",
+  "prop",
+  "portrait",
+  "illustration"
+]
      • changedInput schema / properties / references / items / properties / role / description
        Previous value: -"character: hold this face/figure (up to 4 on flash, 5 on pro). style: match palette, brushwork, light, camera angle; never copy the subject (works on both tiers in practice)."New value: +"character: hold this face/figure (up to 4 on flash, 5 on pro). style: match palette, brushwork, light, camera angle; never copy the subject (works on both tiers in practice). pose: match only its pose, head direction, camera angle, and silhouette, never its drawing; for replacing a weak token, attach the old one as the ONLY image with this role."
      • changedInput schema / properties / references / items / properties / role / enum
        Previous value: -[
-  "character",
-  "style"
-]New value: +[
+  "character",
+  "style",
+  "pose"
+]
  3. 4 tool updatesv1.0.0
    • Addedcutout-image
    • Addededit-image
    • Changedgenerate-image12 fields changed
      • removedInput schema / properties / batch
        Removed value: -{
-  "default": 6,
-  "description": "Draft mode only: images per batch.",
-  "maximum": 8,
-  "minimum": 1,
-  "type": "integer"
-}
      • addedInput schema / properties / confirmPro
        Added value: +{
+  "description": "Required true with tier: \"pro\". Offer pro to the owner as an option for portraits and illustrations (\"pro is available for a bit extra\"); never assume it.",
+  "type": "boolean"
+}
      • removedInput schema / properties / denoise
        Removed value: -{
-  "default": 0.7,
-  "description": "Refine mode only. 0.7 (pinned by test) keeps the scene skeleton in dev style; ~0.55 clones composition but inherits the draft rendering style.",
-  "maximum": 0.95,
-  "minimum": 0.3,
-  "type": "number"
-}
      • changedInput schema / properties / kind / description
        Previous value: -"Purpose preset — fixes generation and output resolution. No raw dimensions."New value: +"Purpose preset. icon: 1:1 flash → 512 square. token: 1:1 flash, top-down full body on a chroma plate, cut to alpha on a 512 square (framing, plate, and cut are done for you). portrait: 3:4 at 2K. illustration: 16:9 at 4K → 2560×1600 (16:10 crop). Every kind defaults to flash; tier: \"pro\" is opt-in and needs confirmPro."
      • changedInput schema / properties / kind / enum
        Previous value: -[
-  "handout",
-  "scene-background",
-  "portrait",
-  "token"
-]New value: +[
+  "icon",
+  "token",
+  "portrait",
+  "illustration"
+]
      • removedInput schema / properties / mode
        Removed value: -{
-  "default": "draft",
-  "description": "draft: fast klein batch for curation. final: dev-quality render from the prompt alone, finished at output resolution. refine: dev img2img over sourceImage (a picked draft) — keeps its scene skeleton, re-renders in dev style, finished at output resolution.",
-  "enum": [
-    "draft",
-    "final",
-    "refine"
-  ],
-  "type": "string"
-}
      • changedInput schema / properties / prompt / description
        Previous value: -"The full image prompt."New value: +"What a camera would see, in illustrator terms. Do not add framing or background text for icons and tokens; the preset appends it."
      • addedInput schema / properties / references
        Added value: +{
+  "description": "Reference images, attached in this order. Bind each in the prompt by its label or 1-based index (\"Image 2 is Morgash\").",
+  "items": {
+    "properties": {
+      "label": {
+        "description": "Short name used to bind the reference in the prompt, e.g. \"Morgash\".",
+        "type": "string"
+      },
+      "path": {
+        "description": "Absolute path of a PNG/JPEG on disk.",
+        "minLength": 1,
+        "type": "string"
+      },
+      "role": {
+        "description": "character: hold this face/figure (up to 4 on flash, 5 on pro). style: match palette, brushwork, light, camera angle; never copy the subject (works on both tiers in practice).",
+        "enum": [
+          "character",
+          "style"
+        ],
+        "type": "string"
+      }
+    },
+    "required": [
+      "path",
+      "role"
+    ],
+    "type": "object"
+  },
+  "maxItems": 14,
+  "type": "array"
+}
      • removedInput schema / properties / seed
        Removed value: -{
-  "description": "Fixed seed; random when omitted.",
-  "minimum": 0,
-  "type": "integer"
-}
      • changedInput schema / properties / slug / description
        Previous value: -"Short kebab-case subject name used in output filenames, e.g. \"smugglers-cove\"."New value: +"Kebab-cased into the filename: <kind>-<slug>-<id>.png."
      • removedInput schema / properties / sourceImage
        Removed value: -{
-  "description": "Refine mode only (required there): absolute path of the picked draft PNG.",
-  "type": "string"
-}
      • addedInput schema / properties / tier
        Added value: +{
+  "description": "Default flash (Nano Banana 2, ~7-15¢), never needs a confirm. \"pro\" (Nano Banana Pro, ~13-24¢, style-reference slots, stronger multi-figure scenes) needs confirmPro.",
+  "enum": [
+    "flash",
+    "pro"
+  ],
+  "type": "string"
+}
    • Removedupscale-image
  4. 3 tool updatesv0.1.0
    • First observedartificer-status
    • First observedgenerate-image
    • First observedupscale-image
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored across 4 tools

Disambiguation5/5

Each tool has a distinct role: generate-image creates new assets, edit-image modifies existing assets, cutout-image performs alpha extraction, and imagegen-status checks setup/spend. The generate vs. edit boundary is clear, and cutout/status do not overlap with either. Descriptions reinforce the distinctions with specific use cases.

Naming Consistency4/5

Three tools follow a clear verb_noun hyphenated pattern: generate-image, edit-image, cutout-image. imagegen-status is the minor deviation, using a noun-style status label rather than verb_noun. Overall the convention is predictable and readable.

Tool Count5/5

Four tools is well-scoped for an image-generation and processing server. Each tool covers a necessary step: create, edit, cut out, and diagnose/status. No tool appears redundant or trivial.

Completeness4/5

The surface covers the core lifecycle: generate, edit/restyle, cutout, and health/status. Minor gaps exist around asset listing, deletion, batch operations, or variant management, but the main Foundry art workflows are supported. Agents can work around the missing convenience operations.

Maintenance

ActivityActive
ResponsivenessWithin a week

Resources

Related MCP Connectors

Related MCP Servers

  • Foundry VTT MCP Bridge

    adambdooley
    A
    license
    Not graded
    quality
    A
    maintenance
    Connects Claude Desktop to Foundry VTT for AI-powered campaign management, enabling natural language interaction with game data including quest creation, character management, compendium searches, and dice rolling. Provides 20 MCP tools for seamless integration between Claude and your tabletop RPG sessions.
    79
    MIT

  • FoundryVTT MCP Server

    MCP-Mirror
    F
    license
    Not graded
    quality
    Not graded
    maintenance
    Integrates with FoundryVTT tabletop gaming sessions, allowing AI assistants to query game data, roll dice, generate content (NPCs, loot, encounters), manage combat, and provide tactical suggestions through natural language.
    3 npm
    -