Skip to main content
Glama

Restart the game

restart

Resets a Twine story to its start, optionally with a new SugarCube PRNG seed, then returns the first observation.

Instructions

Restart the story from the beginning (optionally with a new PRNG seed). Returns the first observation (text; format:"json" for JSON).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
seedNoNew SugarCube PRNG seed.
formatNoOutput format: "text" (default, human-readable) or "json" (JSON string for programmatic use).
game_idYesSession id returned by open_game.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It helpfully discloses the return value ('Returns the first observation') and the output format choice, but it never states that restarting discards current progress/state or what happens to existing save points - a key behavioral trait for a mutation tool.

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?

One front-loaded sentence with a compact parenthetical; nothing is wasted. The return-value clause is slightly crammed onto the end but still earns its place by covering a missing output schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-parameter tool with no output schema, the description adequately covers the return value and the seed/format options. However, with no annotations it leaves the destructive/state-resetting nature of the operation and its relationship to save_state/load_state unexplained.

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 schema already documents game_id, seed, and format in detail. The description's 'optionally with a new PRNG seed' only confirms seed's optionality and the format note repeats the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Restart the story from the beginning'), which is clear and distinct from siblings like load_state or back by the 'from the beginning' scoping phrase. It stops short of explicitly naming the sibling it contrasts with, so it lands just under a 5.

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?

Usage is only implied: an agent can infer you restart when you want to reset the story, and the 'from the beginning' wording hints at the distinction from load_state. There is no explicit when-to-use, when-not-to-use, or named alternative, so it does not reach a 4.

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