Skip to main content
Glama
Txpple

fvtt-mcp-molten5e

by Txpple
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

create-walls

Add wall segments to a Foundry VTT scene to block movement, sight, light, or sound, and insert doors or secret doors. Specify coordinates and wall properties; errors are isolated per wall.

Instructions

Create one or more WALL segments on a scene — surgical additions (block a corridor, add a door/secret door) to walls normally drawn in the app or shipped by a map pack. Each wall is a segment x0,y0→x1,y1 (or c:[4]) in absolute canvas pixels. Channels: move (0/20), light/sight/sound (0 none / 10 limited / 20 normal / 30 proximity / 40 distance — omitted channels default to 20 blocking), dir (one-way), door (1 door / 2 secret) + ds (state) + doorSound, and proximity thresholds. Per-wall error isolation. Returns created ids. GM-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
wallsYesOne or more wall segments to create (omitted channels default to blocking).
sceneIdentifierYesScene id or exact name holding the placeables.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv2.1.3
    • removedInput schema / properties / walls / items / properties / thresholdLight / anyOf
      Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]
    • addedInput schema / properties / walls / items / properties / thresholdLight / type
      Added value: +[
+  "number",
+  "null"
+]
    • removedInput schema / properties / walls / items / properties / thresholdSight / anyOf
      Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]
    • addedInput schema / properties / walls / items / properties / thresholdSight / type
      Added value: +[
+  "number",
+  "null"
+]
    • removedInput schema / properties / walls / items / properties / thresholdSound / anyOf
      Removed value: -[
-  {
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]
    • addedInput schema / properties / walls / items / properties / thresholdSound / type
      Added value: +[
+  "number",
+  "null"
+]
  2. Addedv1.3.0

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 of behavioral disclosure. It explicitly states key behaviors: per-wall error isolation (so partial failures are possible), returns created ids, and GM-only restriction. It also discloses default channel values (omitted channels default to 20 blocking) and explains door state semantics. This goes well beyond a bare 'create walls' and covers the main operational expectations.

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 that front-loads the core purpose and then layers in defaults, channels, and error handling. Every sentence adds new information, and nothing is wasted. It could be split into bullet points for readability, but it remains compact and scannable for an agent.

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 tool with many parameters and no output schema, the description covers the essential operational aspects: what the tool does, coordinate system (absolute canvas pixels), channel defaults, door and threshold semantics, error isolation, return value, and access restriction. It does not explicitly state the walls are added to the scene's walls layer, but that is implied by 'on a scene'. No critical information appears 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?

Although the schema provides 100% coverage with per-parameter descriptions, the description adds a higher-level interpretation: it groups channels (move, light/sight/sound) and explains the meaning of threshold values and the alternative 'c' array syntax. It also gives a concrete example of doorSound ('woodBasic', 'metal'), which is not in the schema. This enriches the schema and helps an agent choose correct values.

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 one or more WALL segments') and immediately clarifies scope: 'surgical additions' to walls normally drawn in the app or shipped by a map pack. This distinguishes it from sibling tools like update-walls (modifying) and delete-walls, and the door/secret door examples make the intent unmistakable.

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 states the intended use case ('surgical additions') and contrasts with the normal workflow of drawing walls in the app, implying when to use this tool vs. manual drawing. However, it does not explicitly name alternatives like update-walls or list-walls, and there is no direct 'when not to use' guidance. The context is clear enough for an agent to infer the primary scenario.

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