Skip to main content
Glama
Txpple

fvtt-mcp-molten5e

by Txpple

screenshot-scene

Render a scene and capture a PNG for visual QA of imports and maps. Optionally fit the whole map or keep camera view, and draw markers over map-note pins to check placement.

Instructions

Render a scene in the headless bridge and capture a PNG to a local file — visual QA for imports/maps. Views the scene, waits for the WebGL canvas to draw, fits the whole map into the viewport (or keeps the saved camera with fit:false), and optionally draws numbered markers over each map-note pin (mark:true) to check legend-pin placement (a view-only overlay, no document changes). Returns the file path + scene metadata; open/read that file to view the image. GM-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fitNoFit the whole scene into the viewport (default). false keeps the saved camera view.
markNoDraw a transient numbered marker over each map-note pin (QA for legend-pin placement). No document changes — the overlay is view-only.
outputPathNoAbsolute local path to write the PNG to. Default: a temp file (path returned).
sceneIdentifierYesScene id or exact name to screenshot.
Behavior4/5

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

Describes headless operation, WebGL wait, viewport fitting, marker overlay (view-only), and output, but could mention error handling or prerequisites.

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?

Single paragraph, front-loaded with core purpose, every sentence adds value, no fluff.

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 no output schema and no annotations, the description adequately covers all parameters, behavior, and output for a screenshot tool.

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?

Description adds context beyond schema (e.g., fit:true/false, mark:true for QA, outputPath default), enhancing understanding despite full schema coverage.

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 clearly states the tool renders a scene and captures a PNG for visual QA, distinguishing it from sibling scene tools that perform CRUD or get info.

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 explains usage for visual QA, imports/maps, and notes GM-only restriction, but doesn't explicitly exclude alternatives or state when not to use.

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