Skip to main content
Glama
Vision-Stack20

kassi-CLI

Resume a different session's past state

fork_from_past
Destructive

Resume a past Burr run by loading persisted state. Restore sessions across restarts or fork from any persisted run using app_id and optional sequence_id.

Instructions

Resume a past Burr run by loading persisted state.

    Three-tier source resolution:

    1. If ``mount(state_loader=...)`` was passed an explicit Burr
       ``BaseStateLoader``, use it. Any persister works:
       ``SQLitePersister``, custom S3/postgres loaders, etc.
    2. Else if the session's current Application has a
       ``LocalTrackingClient`` attached, read its on-disk log.
    3. Else refuse.

    ``partition_key`` defaults to empty string, matching Burr's
    default; pass it explicitly when your persister uses
    partitioned storage.

    Use this for:
      - resuming a session across server restarts (track
        ``app_id`` on the client, restore here after reconnect);
      - forking from any persisted past run, not just the current
        session's in-memory history.

    Refuses when:
      - shared-app mode (no factory to rebuild from);
      - no state_loader configured and no LocalTrackingClient on
        the Application;
      - the requested app_id/sequence_id doesn't exist.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
app_idYes
sequence_idNo
partition_keyNo
Behavior4/5

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

Annotations declare destructiveHint=true and idempotentHint=false, so the mutation profile is already partially disclosed. The description adds substantial value by explaining the three-tier source resolution mechanism, the partition_key default behavior matching Burr's convention, and the explicit refusal conditions. No contradiction with annotations.

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?

Well-structured with clear numbered and bulleted sections (three-tier resolution, use cases, refusal cases). Each section earns its place. Slightly verbose in the state-loader description but organized effectively with front-loaded purpose statement and scannable bullet points.

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 moderately complex fork/resume operation with 3 parameters and no output schema, the description is complete. It covers source resolution, when to use, when it refuses, partition_key nuances, and the app_id/sequence_id tracking workflow. The refusal conditions and use-case guidance make this fully actionable for an agent.

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 0%, so the description carries the full burden for parameters. It explains partition_key semantics ('defaults to empty string, matching Burr's default; pass it explicitly when your persister uses partitioned storage') and references app_id/sequence_id in the refusal conditions. app_id is implied as the target session identifier. This compensates well for the 0% schema coverage.

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 'Resume a past Burr run by loading persisted state' with a specific verb (resume/fork) and resource (a persisted past run/session). It distinguishes from siblings by clarifying it forks from any persisted past run, not just the current session's in-memory history, and lists explicit refusal cases which differentiate it from fork_at.

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?

Provides an explicit 'Use this for' section listing concrete scenarios (resuming across server restarts with app_id tracking, forking from any persisted past run). Also provides a 'Refuses when' section detailing exclusion conditions (shared-app mode, no state_loader/LocalTrackingClient, non-existent app_id/sequence_id), giving clear guidance on when not to use it.

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