holonovel

Resolve Fate Actions

resolve_fate

Destructive

Roll 4dF and manage Fate aspects, points, and stress, persisting changes to the Novel; uncommitted rolls are flagged, and stress clears tracks/consequences when no track is given.

Instructions

Resolve Fate-style actions with Fudge dice, aspects, Fate points, and stress. Rolls and state changes (points, stress, momentum, progress) persist to the Novel; a roll with no following write is flagged as an uncommitted roll. stress with neither track nor consequence clears all tracks and consequences. Rolls and their state writes are recorded and are not individually reversible. Use when: rolling 4dF against a difficulty, invoking or compelling aspects, spending or refreshing Fate points, or marking stress and consequences. Do NOT use when: resolving a d20 skill check — use the bound ruleset's roll tools or run_command (action: resolve).

Input Schema

TableJSON Schema

Name	Required	Description
`op`	No	Sub-operation: aspect (create, invoke, compel, remove, list), fate_point (spend, grant, refresh, list), or stress (mark, clear, list).
`dice`	No	Fudge dice notation (roll), e.g. '4dF'; defaults to 4dF.
`name`	No	Aspect name (aspect); consequence label (stress).
`seed`	No	Deterministic seed (roll).
`skill`	No	Skill name for the roll label (roll).
`track`	No	Stress track to mark or clear (stress).
`action`	Yes	roll, aspect, fate_point, or stress.
`amount`	No	Fate points to spend or grant (fate_point); defaults to 1.
`shifts`	No	Shifts to mark on a stress track (stress); defaults to 1.
`target`	No	Aspect target: 'scene' or an entity/NPC id (aspect); defaults to 'scene'.
`modifier`	No	Skill rating added to the roll (roll).
`entity_id`	No	Entity or NPC id (aspect/fate_point/stress).
`difficulty`	No	Opposition to beat (roll); defaults to 0.
`consequence`	No	Consequence to record or clear (stress).

Output Schema

TableJSON Schema

Name	Required	Description	Default
`text`	No	Human-readable text envelope mirroring the structured result (REQ-001, REQ-548a).
`status`	Yes	Machine-readable result status: OK, NEED_INPUT, WARNING, PARTIAL, or an error category (REQ-002, REQ-548c).

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.0.3Sep 29, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations (destructiveHint=true, idempotent=false) by disclosing that rolls and state writes persist to the Novel, that a roll with no following write is flagged as uncommitted, that stress without track or consequence clears everything, and that operations are not individually reversible. This is exactly the irreversibility/persistence context a mutating tool needs.

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?

Front-loaded with the core capability and then the when/when-not routing; every sentence carries behavioral or routing information. It is dense and runs long, but there is little waste.

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?

For a 14-parameter mutating tool with an output schema present and full schema coverage, the description supplies the missing behavioral context (persistence, irreversibility, uncommitted-roll flagging) that the structured fields cannot convey. Nothing needed to invoke it correctly is absent.

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 description coverage is 100%, so the baseline is 3, but the description adds semantic grouping beyond the schema by tying the op sub-operations to action types and explaining the stress clearing rule (track/consequence omission). It doesn't detail every parameter's format, so a 4 is fair.

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?

States a specific verb and domain (resolve Fate-style actions with Fudge dice, aspects, Fate points, stress) and enumerates the sub-operations, which cleanly distinguishes it from siblings resolve_ironsworn and resolve_forged. An agent knows exactly which ruleset surface this tool covers.

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?

Explicit 'Use when' list covers rolling 4dF, invoking/compelling aspects, spending/refreshing Fate points, marking stress and consequences. The 'Do NOT use when' clause names the alternative (bound ruleset's roll tools or run_command with action: resolve) for d20 checks, giving a concrete routing decision.

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