Skip to main content
Glama

Change combat turn

change-combat-turn

Move a Foundry VTT combat encounter to the next or previous turn or round, or set the turn to a specific combatant, and report the round and turn before and after.

Instructions

Move a running combat encounter: next-turn, previous-turn, next-round, previous-round, or set-turn to a combatant. Moves use Foundry's own rules (for example skipping defeated combatants when the tracker is set so). The answer gives round and turn before and after.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYesThe move
tokenIdNoFor set-turn: or the id of its token
combatIdNoId of the combat encounter, as list-combats shows it. Without it the active encounter is used.
combatantIdNoFor set-turn: the combatant who acts

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv14.2609.4

TDQS

A4/5.0
Behavior4/5

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

Annotations already cover read-only/idempotent/destructive hints, and the description adds useful behavioral context: moves follow Foundry's own defeated-combatant handling and the response reports round/turn before and after. This elaborates on side effects without contradicting annotations.

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?

Three short sentences carry purpose, behavior, and output expectations without repetition. The action list is front-loaded, and every sentence earns its place.

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?

Despite no output schema, the description covers prerequisites (running encounter), behavior, and return info (round/turn before and after). It leaves tokenId vs combatantId and combatId defaulting to the schema, which is appropriate; minor error/validation behavior is not described.

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. The description reiterates that set-turn targets a combatant, but the tokenId/combatantId semantics and combatId default are already fully described in the input 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?

Description names a clear verb and resource: 'Move a running combat encounter', then exhaustively lists the five supported moves. This differentiates it from combat-query tools like list-combats/get-combat and from start/end-combat siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It implies the tool applies to running encounters and that movement follows Foundry's own rules, but it never explicitly says when to choose it over sibling combat tools or when not to use it. No alternative tools or exclusions are named.

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