Skip to main content
Glama
Txpple

fvtt-mcp-molten5e

by Txpple

create-scene

Creates a Foundry VTT scene from a background image: auto-detects dimensions, sets folder and navigation, and generates a thumbnail. Imports walls/lights from map sidecar JSON if provided.

Instructions

Create a Foundry Scene from a Data-relative background image path (e.g. an uploaded map). Width/height auto-detect from the image when omitted. Places it in a folder (created if absent) and sets navigation (false = a DM-only scene off the player nav bar) in the same call. AUTO-GENERATES the navigation thumbnail from the background (Foundry-native) when no explicit thumb is given — no more thumbnail-less scenes. Optionally set grid size/type/distance/units/color/alpha, token vision, fog mode, lighting (darkness, global light, or a whole environment{}/fog{} mood object + saved camera for pack imports), weather, a linked playlist/journal, a nav thumbnail, padding, provenance flags, and activate it. Can also IMPORT walls + ambient lights from a map sidecar JSON (the walls/lights arrays many battlemaps ship alongside the image): pass them and they are placed on the new scene (legacy or v14 shapes both accepted, normalized to v14). GM-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fogNoA v12+ scene's full fog{} object (exploration, overlay, colors), carried whole (deep-merged).
nameYesScene name.
flagsNoDocument flags namespaced by scope — e.g. {"tom-cartos-import":{sourceModule,sourceId}} for import provenance/dedup. Deep-merged over any existing flags (re-stampable on update).
thumbNoData-relative path to a pre-rendered navigation thumbnail (e.g. an uploaded <id>-thumb.webp shipped by a map pack). Foundry may regenerate it on a later in-app edit, so treat it as a nice-to-have, not load-bearing.
wallsNoWalls to import from a map sidecar JSON (the `walls` array of a Foundry scene-export sidecar that ships next to a map). Created after the scene exists; coordinates are absolute canvas pixels, so pass the sidecar width/height/gridSize/padding too.
widthNoScene width in pixels (optional — auto-detected from the image when omitted).
folderNoScene folder id or exact name to place the scene in (created if absent).
heightNoScene height in pixels (optional — auto-detected from the image when omitted).
lightsNoAmbient lights to import from a map sidecar JSON (the `lights` array).
fogModeNoFog of war: disabled | individual (classic per-player) | shared (party-wide).
initialNoThe saved initial camera view {x,y,scale} to restore on scene load (deep-merged).
journalNoJournalEntry id or exact name to attach as scene notes. "" clears it.
paddingNoScene padding fraction (optional).
regionsNoRegions (v12+ RegionDocument incl. teleporters) to import from a scene-pack payload. Created after the scene exists; each is stamped with its source id, and cross-scene teleporter destinations are rewritten afterward by a single remap-teleporters call.
weatherNoWeather effect key (e.g. rain, snow, fog, leaves, rainStorm, blizzard). "" = none.
activateNoActivate the scene after creating it.
darknessNoDarkness/day-night level: 0 = full daylight, 1 = full night.
gridSizeNoGrid size in pixels (default 100).
gridTypeNoFoundry grid type (0 gridless, 1 square, 2+ hex). Default 1.
playlistNoPlaylist id or exact name to auto-play on scene activation. "" clears it.
gridAlphaNoGrid line opacity 0–1 (e.g. 0.2 for a faint grid).
gridColorNoGrid line color as a hex string, e.g. "#000000".
gridUnitsNoDistance unit label per cell, e.g. "ft" (dnd5e default).
navigationNoWhether the scene appears in the player navigation bar. Set false for a DM-only scene (keeps it off the nav bar). Omit for Foundry default.
environmentNoA v12+ scene's full environment{} mood object, carried whole (darknessLevel, globalLight{...}, cycle, base, dark{hue,luminosity}…). Deep-merged, so a partial mood patch layers onto the scene; prefer this over the flat darkness/globalLight knobs when importing or re-mooding a pack scene.
globalLightNoGlobally illuminate the whole scene (turn the lights on).
tokenVisionNoRequire token line-of-sight to see the scene. Turn OFF for overland/illustration maps.
gridDistanceNoReal-world distance per grid cell (dnd5e default 5).
backgroundPathYesData-relative path to the background/map image.
placeablesPathNoServer-local path to a JSON file of {walls,lights,regions} to place (as written by read-pack for a scene-pack import). Read SERVER-SIDE and merged with any inline placeables — this routes a pack's hundreds of walls/lights/regions tool→tool without passing them through the agent (the MCP response cap makes inline placeables infeasible at scene scale).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv2.1.3
    • removedInput schema / properties / fog / properties / overlay / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedInput schema / properties / fog / properties / overlay / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedInput schema / properties / regions / items / properties / elevation / properties / bottom / anyOf
      Removed value: -[
      -  {
      -    "type": "number"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedInput schema / properties / regions / items / properties / elevation / properties / bottom / type
      Added value: +[
      +  "number",
      +  "null"
      +]
    • removedInput schema / properties / regions / items / properties / elevation / properties / top / anyOf
      Removed value: -[
      -  {
      -    "type": "number"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedInput schema / properties / regions / items / properties / elevation / properties / top / type
      Added value: +[
      +  "number",
      +  "null"
      +]
  2. Changed7 schema fields changedv1.3.0
    • changedInput schema / properties / environment / description
      Previous value: -"A v12+ scene's full environment{} mood object, carried whole (darknessLevel, globalLight{...}, cycle, base, dark{hue,luminosity}…). Prefer this over the flat darkness/globalLight knobs when importing a pack so the authored day/night mood round-trips."New value: +"A v12+ scene's full environment{} mood object, carried whole (darknessLevel, globalLight{...}, cycle, base, dark{hue,luminosity}…). Deep-merged, so a partial mood patch layers onto the scene; prefer this over the flat darkness/globalLight knobs when importing or re-mooding a pack scene."
    • changedInput schema / properties / flags / description
      Previous value: -"Document flags to stamp on the new scene, namespaced by scope — e.g. {\"tom-cartos-import\":{sourceModule,sourceId}} for import provenance/dedup. Merged verbatim."New value: +"Document flags namespaced by scope — e.g. {\"tom-cartos-import\":{sourceModule,sourceId}} for import provenance/dedup. Deep-merged over any existing flags (re-stampable on update)."
    • changedInput schema / properties / fog / description
      Previous value: -"A v12+ scene's full fog{} object (exploration, overlay, colors), carried whole."New value: +"A v12+ scene's full fog{} object (exploration, overlay, colors), carried whole (deep-merged)."
    • addedInput schema / properties / folder
      Added value: +{
      +  "description": "Scene folder id or exact name to place the scene in (created if absent).",
      +  "type": "string"
      +}
    • changedInput schema / properties / initial / description
      Previous value: -"The saved initial camera view {x,y,scale} to restore on scene load."New value: +"The saved initial camera view {x,y,scale} to restore on scene load (deep-merged)."
    • addedInput schema / properties / navigation
      Added value: +{
      +  "description": "Whether the scene appears in the player navigation bar. Set false for a DM-only scene (keeps it off the nav bar). Omit for Foundry default.",
      +  "type": "boolean"
      +}
    • changedInput schema / properties / regions / items / properties / behaviors / description
      Previous value: -"Region behaviors carried whole — incl. teleportToken whose system.destination (Scene.<id>.Region.<id>) is rewritten post-import by remap-teleporters."New value: +"Region behaviors carried whole — incl. teleportToken whose system.destinations[] (each Scene.<id>.Region.<id>) are rewritten post-import by remap-teleporters."
  3. First observedv1.2.2

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries full responsibility for behavioral disclosure. It reveals several non-obvious behaviors: width/height auto-detection, folder creation when absent, automatic navigation thumbnail generation, sidecar import normalization from legacy to v14, and the distinction between DM-only and player-visible scenes. This goes well beyond a simple 'creates a scene' and helps the agent anticipate side effects.

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 description is a single dense paragraph, but it is well organized: core action first, then key behaviors, optional settings, and finally the import caveat. Every sentence adds value, though the length borders on overwhelming. Splitting into a few sentences would improve scannability, but it remains appropriately sized for a tool with this many features.

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?

Given the large parameter count (30) and the lack of an output schema or annotations, the description covers the critical aspects: what the tool creates, how it behaves by default, how to import supplementary data, and access restrictions. It does not mention what the tool returns after creation, which is a minor gap, but the schema's per-parameter documentation fills in the remaining details. Overall, an agent has enough to decide when and how to invoke it.

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 already describes all 30 parameters in depth (100% coverage). The description adds high-level semantic context that the per-parameter entries do not: auto-detection of width/height, folder creation, thumbnail auto-generation, and the sidecar import workflow. This supplements the schema rather than repeating it.

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 pair ('Create a Foundry Scene from a Data-relative background image path') and goes on to list concrete behaviors (auto-detection, folder placement, thumbnail generation) that distinguish it from sibling tools like update-scene or create-walls. It is immediately clear what the tool does and what it is for.

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?

The description gives strong usage context: it is for creating a new scene from an image, with optional import of walls/lights from a sidecar, and states 'GM-only' as an access constraint. It does not explicitly name alternative tools (e.g. 'for editing an existing scene use update-scene'), so exclusions are implied rather than stated, but the intended use case is clear.

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