D&D 5e SRD Oracle

End Turn

end_turn

Destructive

End the current actor's turn in an active D&D 5e battle, applying end-of-turn effects and returning the next state for fills or reactions.

Instructions

End the current combatant's turn in an active Battle after all pending fills are resolved. Use actorId for the current actor in the returned Battle state. The operation applies end-of-turn effects and stores the result; the response may require hole fills or reaction decisions before play advances. Continue from the returned frontier with fill_battle_hole when required. Use end_battle to finish the entire Battle.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`actorId`	Yes	Combatant id of the current actor in this Play Session's Battle state, returned by read_battle_state or discover_battle_acts; not a Character Session id.
`playSessionId`	Yes	Play Session handle returned by create_play_session for follow-up stateful calls in the same local process or authenticated account.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.1Sep 21, 2026

changedInput schema / properties / actorId / description

Previous value: -"Combatant id from the current battle checkpoint/frontier envelope."New value: +"Combatant id of the current actor in this Play Session's Battle state, returned by read_battle_state or discover_battle_acts; not a Character Session id."

First observedSep 21, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already give destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description adds useful behavioral context beyond those flags: the operation applies end-of-turn effects, stores the result, and may require hole fills or reaction decisions before play advances. This explains the mutable, non-final nature of the operation without contradicting the 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?

The description is compact, front-loaded with the action and precondition, and every sentence delivers distinct information: what the tool does, how to select the right actor, what side effects occur, and how to proceed or use the sibling tool. There is no redundant or filler content.

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 moderate complexity, the rich schema, the presence of an output schema, and the annotations, the description covers the necessary operational context: when to act, what the result may contain, and the follow-up path (fill_battle_hole or end_battle). Nothing needed for correct invocation is missing.

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 both actorId and playSessionId already have detailed schema descriptions. The tool description reinforces 'Use actorId for the current actor in the returned Battle state,' but it does not add meaningful parameter semantics beyond what the schema already provides. Baseline 3 is appropriate.

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 a specific verb ('End'), a precise resource ('the current combatant's turn in an active Battle'), and a precondition ('after all pending fills are resolved'). It also differentiates this tool from the sibling end_battle by clarifying scope: end_turn advances a turn, end_battle finishes the entire Battle.

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?

It explicitly tells the agent when to call this tool (after pending fills are resolved), how to identify the correct actorId (from the returned Battle state), and what to do next if the response requires follow-up ('Continue from the returned frontier with fill_battle_hole when required'). It also names the alternative end_battle for the full Battle, covering the main routing decision.

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