Skip to main content
Glama

session_save_handoff

Persist current session context for the next session to load. Merges concurrent changes via CRDT or enforces optimistic concurrency control to prevent data loss.

Instructions

Upsert the latest project handoff state for the next session to consume on boot. This is the 'live context' that gets loaded when a new session starts. Calling this replaces the previous handoff for the same project (upsert on project).

v5.4 CRDT Merge: On version conflict, a CRDT OR-Map engine automatically merges your changes with concurrent work (Add-Wins OR-Set for arrays, Last-Writer-Wins for scalars). Pass expected_version to enable concurrency control.

v0.4.0 OCC: If you received a version number from session_load_context, /resume_session prompt, or memory resource attachment, you MUST pass it as expected_version to prevent overwriting another session's changes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
roleNoOptional. Agent role for Hivemind scoping (e.g., 'dev', 'qa', 'pm'). Omit to let the server auto-resolve from dashboard settings.
projectYesProject identifier — must match the project used in session_save_ledger.
open_todosNoCurrent open TODO items that need attention in the next session.
key_contextNoFree-form critical context the next session needs to know.
last_summaryNoSummary of the most recent session — used for quick context recovery.
active_branchNoGit branch or context the next session should resume on.
disable_mergeNoSet to true to disable automatic CRDT merging and fail strictly on version conflict (original OCC behavior). Default: false.
conversation_idNoOptional. Session key for this conversation (same id used in session_load_context). When provided, the server verifies that session_load_context was called for this conversation before accepting the write.
expected_versionNov0.4.0: The version number you received when loading context. Pass this to enable optimistic concurrency control. If omitted, version check is skipped (backward compatible).
Behavior5/5

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

With no annotations, the description fully discloses behavior: upsert semantics, CRDT merge, OCC, version control, disable_merge, and conversation_id verification. It clearly explains what happens on version conflict and the concurrency control mechanisms.

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 well-structured with sections for CRDT and OCC, and the main purpose is front-loaded. It is slightly verbose but every sentence adds value, making it appropriately concise for the complexity.

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

Completeness4/5

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

Given 9 parameters and no output schema, the description covers the behavioral and parameter usage thoroughly. However, it does not describe the return value (e.g., success or version number), which slightly limits completeness for an upsert operation.

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 100%, so baseline is 3. The description adds value by explaining the role auto-resolution, the necessity of expected_version when a version number is known, and the effect of disable_merge. This goes beyond the schema's basic descriptions.

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 'Upsert the latest project handoff state for the next session to consume on boot,' specifying the verb, resource, and context. It distinguishes from sibling tools like session_load_context by focusing on saving state.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly mentions when to use (after a session to save context for next boot) and provides conditions for expected_version. However, it does not explicitly mention when not to use or list alternative tools, which would raise it to a 5.

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/dcostenco/prism-coder'

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