Skip to main content
Glama
Txpple

fvtt-mcp-molten5e

by Txpple
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

create-teleporter

Set up a two-way or one-way teleporter between existing scenes by placing grid-snapped trigger regions at two points; tokens walking onto one are sent to the other, with optional player confirmation.

Instructions

Create a two-way (or one-way) region TELEPORTER between two points on existing scenes — the thing create-scene can only do at import time. Give a CENTER point (canvas px) on each scene (from/to, may be the same scene); a rectangle trigger is placed at each (sized in whole grid cells, grid-snapped by default) and a teleportToken behavior on each points at the OTHER — so a token that walks onto one is sent to the other. Both regions are created before either link is wired (the destination-UUID chicken-and-egg). twoWay:false makes it one-directional. By default the player is ASKED before moving (confirmation dialog — the house pattern for map transitions); confirm:false makes it fire silently (traps/plot teleports only). Regions default to GM/Regions-layer visibility (no player-visible overlay). GM-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toYesThe second endpoint (may be the same scene).
fromYesThe first endpoint.
colorNoRegion tint hex (default "#3fb0ff").
toNameNoName for the to-side region.
twoWayNoWire the return teleporter too (default true). false = one-way from→to.
confirmNoAsk before moving (default true — the house pattern for transitions): the moving player gets core v14's "Teleport / Do Not Teleport" confirmation dialog (`choice` flag). Pass false ONLY for trap/plot teleports that should fire silently.
fromNameNoName for the from-side region.
snapToGridNoSnap each trigger rectangle to the grid cell(s) under its center (default true).
widthCellsNoTrigger width in whole grid cells, applied to both ends. Default 1.
heightCellsNoTrigger height in whole grid cells. Default 1.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.1.3
    • addedInput schema / properties / confirm
      Added value: +{
+  "default": true,
+  "description": "Ask before moving (default true — the house pattern for transitions): the moving player gets core v14's \"Teleport / Do Not Teleport\" confirmation dialog (`choice` flag). Pass false ONLY for trap/plot teleports that should fire silently.",
+  "type": "boolean"
+}
  2. Addedv1.3.0

TDQS

A4.7/5.0
Behavior5/5

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

No annotations exist, so the description carries the full burden, and it delivers: trigger placement, grid snapping, teleportToken wiring, creation order, confirmation dialog default, silent mode, and default GM/Regions-layer visibility. It also flags GM-only permissions. Nothing in the description conflicts with the absent annotations.

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

Conciseness5/5

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

The text is dense but purposeful: every clause addresses a non-obvious behavior such as endpoint semantics, wiring order, confirmation behavior, and visibility. It is front-loaded with the core purpose and avoids repeating schema field definitions.

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 10-parameter tool with no output schema and no annotations, the description covers the main behavioral surface: endpoint construction, sizing/snapping, one- vs two-way, confirmation behavior, layer visibility, and GM restriction. The schema documents remaining field-level details, so nothing needed to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3; the description adds meaning beyond the schema by explaining how from/to map to trigger rectangles, what twoWay:false does, what confirm controls, and the default region visibility. This elevates it above the baseline.

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 ('Create') and resource ('region TELEPORTER') with explicit scope ('between two points on existing scenes') and distinguishes it from create-scene, which can only do this at import time. The from/to endpoint semantics make the action unambiguous.

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 clear context: used when a teleporter is needed on existing scenes rather than at scene creation, and notes it is GM-only. It also clarifies mode selection with twoWay:false and when confirm:false is appropriate (traps/plot teleports only). It does not explicitly name related alternatives like remap-teleporters, so it stops just short of full alternative routing.

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