Skip to main content
Glama
Txpple

fvtt-mcp-molten5e

by Txpple

create-group

Create a shared party group actor for D&D 5e Foundry VTT, enroll world actors as members, set default ownership, and seed coin for a communal stash.

Instructions

Create a dnd5e GROUP actor (type:group) — the shared party stash / travel group. Enrolls world actors as members, can grant every player default ownership (defaultOwnership:'owner' = the classic shared stash), seed shared coin, and optionally crown it the world's PRIMARY PARTY. Member resolution is fail-closed: one bad name and nothing is created. Stock the inventory afterwards with add-item / import-item against the group.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
imgNoPortrait image path under Data/ or URL. A path that does not resolve on the server is dropped (dnd5e stamps its default group art) with a warning.
nameYesName of the group actor, e.g. "The Party".
membersNoWorld actors to enroll (name or id; partial name match supported). FAIL-CLOSED: a member that does not resolve, or is itself a group, rejects the whole create — nothing is made.
summaryNoOne-line summary shown in group embeds.
currencyNoStarting shared coin (whole non-negative amounts per denomination).
folderNameNoActor-sidebar folder to file the group under (created if missing).
descriptionNoFull description (HTML allowed) shown on the group sheet.
defaultOwnershipNoThe document's DEFAULT ownership — what every player gets. 'owner' is the shared party stash: all players can open it and move items. Per-user grants: set-actor-ownership.
makePrimaryPartyNoAlso point the world's dnd5e primaryParty setting at this new group (the party shown in the players sidebar; XP awards and party overviews target it).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.1.3

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden, and it delivers: fail-closed member resolution ('one bad name and nothing is created'), default ownership semantics, and the optional global primaryParty side effect. It doesn't mention permissions or return shape, but the most important behavioral traits are disclosed.

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?

Four sentences with no filler: purpose, capabilities, failure mode, and follow-up step. Each sentence earns its place, and the most identifying information is front-loaded.

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 9-parameter creation tool with no output schema and no annotations, the description plus rich schema covers purpose, failure atomicity, side effects, and next steps. It doesn't state return values or auth prerequisites, but an agent has enough to select and invoke the tool correctly.

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% and every parameter already has a detailed description, so the baseline is 3. The description reinforces the fail-closed members behavior and the 'owner' default ownership meaning, but doesn't add unique parameter detail beyond the schema.

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 and resource — 'Create a dnd5e GROUP actor (type:group)' — and immediately clarifies its purpose as the shared party stash / travel group. This clearly distinguishes it from sibling actor-creation tools like create-pc or author-npc.

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 'shared party stash / travel group' phrasing gives a clear use case, and the closing sentence explicitly routes subsequent inventory work to add-item / import-item. It doesn't exhaustively list when-not cases, but the context is strong enough for an agent to select it correctly.

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