Skip to main content
Glama
Txpple

fvtt-mcp-molten5e

by Txpple
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

add-region-behavior

Add one validated behavior to an existing region: teleport, active effect, difficult terrain, rotation, and more. Resolves teleport destinations and warns on off-grid landing pads.

Instructions

Add ONE behavior to an EXISTING region — the write create-region only offers at creation time and update-region deliberately never touches. Creates a real RegionBehavior embedded document (validated against the registered behavior types). For teleporters, pass teleportTo {sceneIdentifier, regionIdentifier} and the destination UUID is resolved for you; the landing region's geometry is then sanity-checked and you are WARNED when it contains no grid-snapped token position (the silent teleport no-op: off-grid pads). GM-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoBehavior label (defaults to the type's standard name).
typeYesBehavior type key, validated against the live registry — core v14: teleportToken, executeMacro, executeScript, adjustDarknessLevel, changeLevel, displayScrollingText, modifyMovementCost, pauseGame, suppressWeather, toggleBehavior, defineSurface; dnd5e 6.0: dnd5e.applyActiveEffect (an area that applies effects to tokens inside it — lava, a poison cloud, consecrated ground; use `effects`), dnd5e.difficultTerrain (use `terrainTypes` / `magical`), dnd5e.rotateArea (a turning platform — use `rotate`).
sizesNoapplyActiveEffect: only creatures of these sizes (omit = all).
rotateNodnd5e.rotateArea: a turning platform / puzzle room — the listed placeables (ids from list-tiles / list-walls / list-lights / list-regions / list-sounds, validated to exist on the scene) rotate together around the region's first shape, stopping at `positions`. A turn is triggered from the region config or a script, not by walking in.
systemNoBehavior system data carried verbatim (the v14 shape for the type) — e.g. executeMacro {uuid}, adjustDarknessLevel {mode, modifier}.
effectsNodnd5e.applyActiveEffect: the effects applied on entry and removed on exit. Each is a NAME from the stock dnd5e.effects pack ("Poisoned", "Prone", "Fire Resistance", "Blinded" …) or from a world item's effects, an ActiveEffect uuid, or an Item uuid + "#<effect name>" (a premium-pack spell's effect). Never an effect on an actor. Resolved and echoed back.
magicalNodifficultTerrain: magical terrain (Spike Growth) vs mundane (rubble). Default false.
disabledNoCreate the behavior disabled (default false).
teleportToNoteleportToken convenience: resolve this scene+region to the destination UUID and append it to system.destinations — no hand-built "Scene.<id>.Region.<id>" needed. A teleportToken with system.choice unset defaults to choice:true (the confirm-before-moving house pattern); pass system.choice:false explicitly for silent trap/plot teleports.
dispositionsNoapplyActiveEffect: only tokens with these dispositions are affected (omit = all). difficultTerrain: these dispositions IGNORE the terrain.
terrainTypesNodifficultTerrain: what kind of terrain it is (a creature may ignore some kinds — e.g. web, plants, ice). Omit for generic difficult terrain.
creatureTypesNoapplyActiveEffect: only these creature types (omit = all).
sceneIdentifierYesScene id or exact name holding the region.
regionIdentifierYesRegion id or EXACT region name on that scene (an ambiguous name errors — use the id).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.1.3

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses that the tool creates a real embedded document (write operation), performs validation against registered behavior types, resolves destination UUIDs for teleporters, and warns about off-grid landing pads (silent teleport no-op). It also states GM-only access. It does not mention return values or error conditions, but the provided behavioral traits are substantive and beyond what schema implies.

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 four sentences and each one earns its place: purpose and distinction, creation validation, teleporter behavior, access restriction. It is front-loaded with the core purpose. While slightly dense, it avoids fluff and remains efficient for a tool with this complexity.

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 tool's complexity (14 params, nested objects, type-specific behaviors) and the rich schema, the description provides the essential high-level context: existing-region scope, sibling distinctions, validation, teleporter convenience and warning, GM-only. It does not explain outputs, but no output schema exists and it is a create operation. The schema covers parameter details, making this description adequately complete.

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 the schema already documents all 14 parameters thoroughly. The description adds minimal extra parameter semantics beyond what the schema provides (e.g., the teleporter workflow is also explained in the teleportTo property description). Baseline 3 is appropriate; the description does not need to compensate.

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 begins with 'Add ONE behavior to an EXISTING region', clearly stating the action, resource, and scope. It distinguishes this tool from create-region and update-region by explaining what they do not do, and specifies it creates a 'RegionBehavior embedded document' validated against registered types. This allows an agent to identify the tool's purpose without opening the schema.

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?

The description explicitly states when to use this tool vs. alternatives: create-region only offers behaviors at creation time and update-region deliberately never touches them. It also gives a specific usage pattern for teleporters and notes the GM-only restriction, providing clear context and exclusion guidance.

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