Skip to main content
Glama

mission_replay

Replay a previously successful checklist item's recorded steps without re-planning, verifying the world matches first and halting if anything changed.

Instructions

Run again, exactly, what already worked for one checklist item. When an item passed through execute_plan(mission_item_id=N), its steps were kept as that item's recipe together with a fingerprint of the world they worked in (the application, the model tag you gave, and the route of windows the run walked through). This replays that recipe — no re-planning, no screenshot, the same execution path any plan takes. BEFORE IT RUNS it compares the recorded world with the world now. If anything comparable differs it does NOT execute a single step: the reply names each field with both values and stops there. A difference is not evidence that the application was updated — it means a window was resized, a dialog is in the way, a different model is driving, or the app really did change, and only you can tell which. Decide and act: run the steps deliberately with execute_plan(mission_item_id=N), which records the world it succeeds in as the item's new truth, or mark the item by hand. Fields nobody can compare are reported too, so a clean preflight is never read as 'nothing changed'. AFTER a successful replay the route it actually walked is held against the recorded one; a different route is reported as a warning on a success, and the item's stored fingerprint is deliberately left as it was. llm_version_tag labels the model driving this replay and is compared with the one stored on the recipe. The reply is the run's journey, the ledger, the preflight notes and the mission status; a failed replay fails the item with the run's own reason.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
item_idYes
llm_version_tagNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden, and it does: preflight world comparison aborts before any step runs, no re-planning or screenshots, route held against the recorded route after success with a warning on divergence, stored fingerprint deliberately left unchanged, and a failed replay fails the item. This is behavior an agent could not infer from the schema.

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 action and then layered with preflight, post-run and failure semantics in roughly the order the agent needs them. It is long and occasionally editorializes ('only you can tell which'), but nearly every sentence carries real behavioral information.

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?

Complete for a complex, side-effecting replay tool with no annotations and no output schema: it documents preconditions, abort behavior, route verification, fingerprint persistence, failure semantics, and what the reply contains. An agent has everything needed to call it and interpret the outcome.

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 0% and neither property has a description, so the description must compensate — it does for llm_version_tag (the model driving this replay, compared against the one stored on the recipe). item_id is only implied through the surrounding references to mission_item_id=N, leaving a small naming ambiguity between the two calls.

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+resource: replaying the exact recorded recipe that previously succeeded for one checklist item. It explicitly distinguishes itself from re-planning and from execute_plan, which the sibling list confirms is a real alternative. An agent can tell mission_replay apart from execute_plan without opening either schema.

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?

Gives the condition for use (an item that passed through execute_plan(mission_item_id=N)) and names the alternatives explicitly: run deliberately via execute_plan to record a new truth, or mark the item by hand. It also tells the agent what a preflight mismatch means and that the decision is theirs.

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