Skip to main content
Glama
Txpple

fvtt-mcp-molten5e

by Txpple

update-token

Edit placed tokens on a scene: adjust rotation, scale, elevation, hit points, name, visibility, and more for one or multiple tokens by id or actor name. Updates applied in batch, with auto-unlock for rotated locked tokens.

Instructions

Edit one or more PLACED tokens on a scene — a token INSTANCE already dropped on the map, NOT the actor's prototype token (that's update-actor). Resolve the scene by id/exact name (default: the ACTIVE scene), then target tokens by tokenIds and/or actorIds (an actor id OR exact name — updates EVERY placed copy of that actor, e.g. all "Dead Guard" corpses). Patch any of: rotation (or randomizeRotation for an independent per-token angle), scale (token art size — sets texture.scaleX/scaleY together), elevation, hidden, lockRotation, x/y, name, displayName (nameplate visibility), displayBars (resource-bar visibility), bar1/bar2 (which resource each bar tracks — the health bar is bar1 = attributes.hp), ring (dynamic token ring on/off), and hp (this token's CURRENT hit points, per-token on its own delta — so two copies of one actor can be wounded differently, which update-actor cannot do) — all matched tokens update in one batch. GOTCHA handled for you: a token whose actor had auto-rotate OFF carries lockRotation:true, which HIDES a set rotation — so when you rotate a locked token the tool auto-unlocks it and warns. Reports matched/updated counts + any unresolved ids. GM-only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xNoNew token X in absolute canvas pixels.
yNoNew token Y in absolute canvas pixels.
hpNoSet THIS placed token's hit points on its own actor — PER-TOKEN, so two copies of the same actor can differ (e.g. a band wounded to different HP). Writes system.attributes.hp.* on the token's (unlinked) delta, NOT the prototype/statblock — the right home for a token's current HP. For a linked token it writes the shared base actor. Only the sub-fields you pass change; 0 is valid (a downed creature).
bar1NoBar 1 resource attribute path (health bar is "attributes.hp"); "" clears it.
bar2NoBar 2 resource attribute path (e.g. "attributes.hp"); "" clears it.
nameNoRename the placed token (its nameplate).
ringNoDynamic token ring: false = plain token (the house default), true = ring on. Sets ring.enabled on the placed token.
scaleNoToken ART scale (sets texture.scaleX and scaleY together). 1 = normal, 1.5 = 50% larger.
hiddenNoHide (true) or reveal (false) the token from players.
actorIdsNoActor id OR exact actor name — updates ALL placed copies of each (e.g. every "Dead Guard" token on the map). Combined (union) with tokenIds.
rotationNoFacing in degrees (0–359), applied to every matched token.
tokenIdsNoPlaced-token ids to update (from list-tokens). Combined (union) with actorIds.
elevationNoToken elevation in grid-distance units (e.g. feet).
displayBarsNoResource (health) bar visibility, same modes as displayName: none | control | owner-hover | hover | owner | always.
displayNameNoNameplate visibility: none | control (only when selected) | owner-hover | hover | owner (always, to owners) | always (always, to everyone).
lockRotationNoLock the token art from rotating. NOTE: lockRotation:true HIDES any `rotation` you set, so when you rotate a locked token and omit this, the tool AUTO-UNLOCKS it (and warns) so the angle is visible.
sceneIdentifierNoScene id or exact name holding the token(s). Omit to use the ACTIVE scene.
randomizeRotationNoGive each matched token its OWN random angle (0–359) instead of one shared `rotation` — e.g. to strew corpses naturally. Overrides `rotation` when true.
Behavior4/5

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

With no annotations, the description fully discloses behaviors: updates are applied to matched tokens, lockRotation auto-unlock, per-token HP delta, and return values (counts + unresolved ids). It could mention error handling for missing scenes, but overall it's transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single long paragraph covering many details. While it front-loads the key distinction, it could be better organized with bullet points or sections for readability. It is not overly verbose given 18 parameters, but structure could improve.

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?

Given no output schema and 18 parameters, the description covers return values (matched/updated counts, unresolved ids), lockRotation gotcha, and per-token vs shared state. It lacks some edge cases (e.g., empty token/actor lists) but is largely complete for an update 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?

Schema coverage is 100%, so baseline is 3. The description adds extra context beyond schema, like explaining bar1/bar2 health bar path, hp per-token delta, and lockRotation interaction. This adds meaningful value.

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 states the tool edits placed tokens, not prototype tokens, explicitly distinguishing from update-actor. It lists editable fields and targeting methods, making the purpose very specific and clear.

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 clearly says when to use (placed tokens) and when not (prototype tokens -> update-actor). It provides guidance on scene resolution, targeting by ids/names, and batch updates. It also includes a 'GOTCHA' about lockRotation, helping the agent use the tool correctly.

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