Skip to main content
Glama
Txpple

fvtt-mcp-molten5e

by Txpple
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

configure-dnd5e-settings

Read or change D&D 5e automation settings in Foundry VTT: falling damage, token vision/size sync, exhaustion, initiative grouping, downed effects, encounter placement, player trays, bastion, and calendar. GM-only.

Instructions

[D&D 5e] Read or set the dnd5e 6.0 AUTOMATION settings — falling damage, token size ↔ creature size, senses ↔ token vision, exhaustion, initiative grouping, auto-apply Unconscious/Dead at 0 HP, encounter placement, the player damage / effects trays, the bastion system, and the calendar (enabled, daily recovery mode, which calendar). Call with NO arguments to read every switch; pass any of them to change it — each change echoes previous → new, re-applying the current value is a clean no-op, and the switches that need a client reload are named. Allow-listed: nothing else in the settings menu is reachable. GM-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bloodiedNoWho sees the Bloodied status. all (every token) · player (default — only tokens the players own/see) · none (off).
calendarNoCalendar in use. gregorian (default) · greyhawk · harptos (Forgotten Realms) · khorvaire (Eberron); modules may add more. Takes effect after clients reload. Validated against the live list.
pietyScoreNoPiety score (optional rule). Adds the Piety score to character sheets (default false; registered config:false — this tool is the lever).
tokenSizeSyncNoSync token size to creature size. A Large creature gets a 2×2 token automatically (default true). Takes effect after clients reload.
allowSummoningNoPlayers may summon. Players place summons from their own summon activities (default false — GM-only).
bastionEnabledNoBastion system. Turns on bastion turns + the bastion tab (default false).
disableFallingNoDisable falling automation. true turns OFF fall damage / falling from Levels (default false — falling is automated).
autoApplyDownedNoAuto-apply Unconscious / Dead at 0 HP. none (default) · deadOnly (NPCs die at 0) · npcs (NPCs die, PCs go unconscious) · all.
bastionDurationNoDays per bastion turn. How many in-world days make one bastion turn (default 7).
calendarEnabledNoCalendar. Turns on the date/time HUD, dawn / dusk / day recovery and bastion-turn progression (default false).
senseVisionSyncNoSync senses to token vision. Darkvision / blindsight on the sheet drive the token vision modes (default true).
allowPolymorphingNoPlayers may polymorph / transform actors. Players run the transform flow on actors they own (default false — GM-only).
disableExhaustionNoDisable exhaustion automation. true turns OFF the exhaustion d20 penalties (default false). Takes effect after clients reload.
movementAutomationNoMovement automation. full (default — difficult terrain + creature blocking) · noBlocking (terrain only) · none.
initiativeGroupRollNoRoll initiative once per group. A grouped set of combatants rolls one initiative (default true).
disableConcentrationNoDisable concentration tracking. true turns OFF automatic concentration effects + prompts (default false).
allowPlayerDamageTrayNoPlayers may use the damage tray. Players apply damage from chat cards to their own tokens (default false).
calendarDailyRecoveryNoDaily recovery mode. auto = the system default (calendar when the calendar is enabled, else manual) · calendar (uses recover on time advance) · manual ("New Day" in rest dialogs).
allowPlayerEffectsTrayNoPlayers may use the effects tray. Players apply effects from chat cards to their own tokens (default false).
initiativeGroupCombatantsNoGroup identical combatants in the tracker. Six goblins share one tracker row (default true).
encounterPlacementBehaviorNoWhen an encounter is placed on the map. none (default) · createCombatants (add them to the tracker) · rollInitiative (and roll).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.1.3

TDQS

A4.5/5.0
Behavior5/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, and it delivers: it states that changes echo previous → new, re-applying is a no-op, certain switches require a client reload (and names them), the tool is GM-only, and it is allow-listed to automation settings only. This goes well beyond a bare CRUD statement.

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?

Although the description is long, it is dense and front-loaded: it states the verb, scope, and key usage pattern in the first sentence, then enumerates categories, behavior, and constraints. Every sentence adds operational value, and no filler or repetition is present.

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 21-parameter configuration tool with no output schema and no annotations, the description covers everything needed for correct invocation: read vs. set behavior, no-op semantics, reload requirements, GM-only restriction, and the exact allow-listed scope. The schema covers per-parameter defaults and enums, so the combination is 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 baseline is 3 even if the description adds no per-parameter details. The description groups the settings into categories and explains global behavior, but it does not add meaning beyond the already-rich schema descriptions for individual parameters. This meets the baseline without exceeding 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 names a specific verb pair (read/set), a specific resource (dnd5e 6.0 AUTOMATION settings), and enumerates the exact categories involved. It also distinguishes itself from the broader settings menu by stating 'Allow-listed: nothing else in the settings menu is reachable,' so an agent can separate it from siblings like manage-calendar or configure-combat-tracker.

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 explicit call patterns: call with NO arguments to read every switch, pass any argument to change it, and re-applying the current value is a clean no-op. It does not explicitly name alternative tools or exclusion cases, but the read-vs-write usage is clear enough for correct selection and invocation.

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