Skip to main content
Glama
Vision-Stack20

kassi-CLI

Branch this session from a prior step

fork_at
Destructive

Restore a session to a prior history point by sequence ID, allowing re-execution from that state. Rebuilds the application and discards subsequent sub-runs.

Instructions

Rewind the session to the state captured after history[seq=N].

    ``sequence_id`` is the ``seq`` field on a ``theodosia://history`` entry.
    ``seq`` is accepted as an alias so a client can copy the value straight
    from history under either name (``sequence_id`` wins if both are given).
    The session's Application is rebuilt via the factory, then its
    state is overwritten with the snapshot captured at that point,
    and its ``__PRIOR_STEP`` is set to the action name from that
    entry so ``valid_next_actions`` computes correctly. Sub-runs
    recorded after that point are cleared. A ``fork_at`` marker is
    appended to history with the target sequence_id under
    ``inputs``.

    Refuses when:
      - shared-app mode (would affect every connected client);
      - sequence_id is out of range;
      - the target entry was a refusal (state_after is None);
      - the target entry is itself a fork or reset marker (avoid
        walking a hall of mirrors).
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
seqNo
sequence_idNo
Behavior4/5

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

Annotations declare destructiveHint=true and idempotentHint=false, and the description corroborates by detailing what gets overwritten (Application state, __PRIOR_STEP, cleared sub-runs). It adds behavioral context beyond annotations: the Application is rebuilt via factory, sub-runs are cleared, and a fork_at marker is appended to history. Rich disclosure of side effects.

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?

The description is front-loaded with the core purpose, then details mechanics, then refusal conditions in bullet form. The bullet list of refusals is efficiently structured. It's somewhat long but every sentence carries substantive technical content; the docstring format is appropriate for the complexity of the tool.

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 complex, destructive branching tool with 2 optional params, 0% schema coverage, and no output schema, the description is remarkably complete. It covers the full lifecycle: source identification (seq/sequence_id), the rebuild-and-overwrite mechanics, sub-run clearing, marker appending, and all refusal edge cases. The agent can safely decide when to invoke this without needing additional context.

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% (neither parameter is described in the schema), so the description must compensate. It explains that sequence_id is the seq field on a theodosia://history entry, that seq is an alias, and that sequence_id wins if both are given. This adds meaningful semantic value beyond the bare schema, though it doesn't cover the nullability/default semantics in detail.

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 clearly states the tool 'Rewinds the session to the state captured after history[seq=N]', uses the specific verb 'fork'/'rewind' with a resource (session state at a prior step). It distinguishes from siblings like step, reset_session, fork_from_past by focusing on 'branch this session' from a prior step within the current session's history.

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?

The description explicitly lists refusal conditions (shared-app mode, out-of-range seq, refusal target, fork/reset marker targets), giving clear when-not-to-use guidance. It also explains the difference between sequence_id and the seq alias for copy-from-history. This substantially differentiates usage from similar tools.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Vision-Stack20/Kassi-CLI'

If you have feedback or need assistance with the MCP directory API, please join our Discord server