Skip to main content
Glama
Txpple

fvtt-mcp-molten5e

by Txpple

read-pack

Read a Foundry VTT scene pack module from disk, extracting scenes and journal entries with asset paths rewritten for import. Supports both v10/NeDB and v13/LevelDB formats, returning results in pages for large packs.

Instructions

Read a Tom-Cartos-style Foundry SCENE-PACK MODULE off disk (a module.json + LevelDB/NeDB compendium packs) and return its era-normalized documents for import. OFF-LINE and Node-only: it reads files, never the live world. Detects the pack's Foundry era from field shape (older v10/NeDB vs newer v13/LevelDB), extracts each Scene (dimensions, grid, background, thumbnail, walls, lights, regions/teleporters) and JournalEntry (pages), strips cli pack artifacts, and — when given the destination root the skill chose — emits per-asset path REWRITE HINTS (the module-relative %-encoded src → a clean Data-relative path). Also discovers any standalone TILE images the pack ships (building/prop pieces with a Tile_<W>x<H> grid footprint in the name, not referenced by any scene) so the skill can make them available for the GM to drop onto scenes. The heavy per-scene walls/lights/regions are written to PAYLOAD FILES and referenced by placeablesPath (NOT inline — the response cap truncates them at scene scale); pass that path to create-scene, which reads it server-side. The skill then uploads the assets, recreates the scenes/journals, and (modern packs) remaps the cross-scene teleporters. Handles all eras: modern v13/LevelDB (via the @foundryvtt/foundryvtt-cli child process) AND legacy v10/NeDB .db (parsed directly — no cli needed). The full manifest is PAGED to fit the response cap: returns totalScenes + a page of scenes + nextOffset (call again with offset until null). Pass index:true first for a tiny names-only survey of the whole pack (variant planning + dedup) before paging the heavy import.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
indexNoSurvey mode: return ONLY the lightweight scene list ({sourceId, name, counts}) + descriptor + journal names — no paths, payloads, or assets. Call this ONCE to plan variant selection and dedup across the whole pack before paging the full import (the full manifest is capped/paged).
offsetNoIndex of the first Scene to return (for paging a big pack). Default 0.
destRootNoData-relative asset destination root the skill chose (e.g. "worlds/<world>/assets/tom-cartos/<module-id>"). When set, every referenced asset gets a `dataPath` rewrite hint (modules/<id>/<rel> → <destRoot>/<rel>, percent-decoded) so the create tools receive already-correct paths. Omit to get the decoded module-relative paths only.
packNameNoOnly read this pack (matched against module.json packs[].name). Default: all packs.
modulePathYesAbsolute path to the unzipped module folder OR directly to its module.json.
sceneLimitNoPage size: how many Scene records to return this call (default 10). The manifest must fit the MCP response cap, so a big pack is read in pages — import a page, then call again with `offset` advanced by the returned count until `nextOffset` is null.
Behavior5/5

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

With no annotations, the description carries full responsibility. It thoroughly discloses behaviors: offline-only, dual-era support (v10/NeDB vs v13/LevelDB), stripping pack artifacts, emitting path rewrite hints, discovering standalone tiles, and paging response truncation. No contradictions present.

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 well-structured and front-loaded with the core action, but it is lengthy (multiple paragraphs). Every sentence adds value, but minor redundancy exists (e.g., repeating offline nature). Slight conciseness improvement possible without losing clarity.

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?

Given the tool's complexity (6 parameters, no output schema, offline-only, paging, path rewriting), the description is highly complete. It covers all behavioral aspects, parameter usage, return structure, and integration with sibling tools, leaving no significant gaps for an AI agent.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds significant meaning: it explains the purpose of each parameter in the overall workflow (e.g., destRoot for path rewriting, index for survey, offset/sceneLimit for paging, packName for filtering) and their interplay, surpassing basic schema descriptions.

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 explicitly states it reads a Foundry SCENE-PACK MODULE off disk, detailing the content (module.json + compendium packs) and output (era-normalized documents for import). It distinguishes itself from sibling tools like create-scene (which handles online scene creation) and import-cards/import-item by being offline and module-specific.

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 provides clear when-to-use guidance: offline reading of Tom-Cartos-style packs for import, with explicit instructions for survey mode (index:true), paging (offset, sceneLimit), and integration with create-scene for payload files. It also explains when to use each parameter, effectively guiding the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Txpple/fvtt-mcp-molten5e'

If you have feedback or need assistance with the MCP directory API, please join our Discord server